Jump to content


Photo

Error in 'My Heritage' lightbulb


  • Please log in to reply
48 replies to this topic

#41 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3569 posts

Posted 20 December 2014 - 10:28 PM

Ok, a little more testing.

 

  • Made a copy of my production database (File->Copy from within RM). The hash string for the matches for John H. Peters in the copy was the same as the hash string in the production database.
  • Changed the RM Unique ID for John H. Peters in the test database. The same WebHints were there, and the hash string did not change.
  • Changed the name from John H. Peters to John Henry Peters without changing anything else. (His name probably actually was John Henry Peters - I just don't have adequate proof). The hash string changed, but the WebHints were the same. MyHeritage did show my RM data as John Henry Peters rather than John H. Peters with the new hash string.
  • Changed the name from John Henry Peters back to John H. Peters. The hash string changed again, but not back to the original hash string. And of course the same WebHints were still there. This is most puzzling. I'm going to sleep on it for now. Maybe Tom can figure it out.

Jerry



#42 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6252 posts

Posted 20 December 2014 - 10:37 PM

Unless your reference person has confirmed or rejected matches, I don't think you can distinguish the effect of the RM UID with your test. Pending matches depend on all the data other than the UID and are approximate. Confirmed and rejected matches must relate to the specific person in a specific database because entering exactly the same data for a person and immediate family in another database does not see the confirmed or rejected matches of the first. Drag'n'drop the person and immediate family copies the UID and the confirmed/rejected matches are identical to the original. Change or delete the UID and the confirmed/rejected matches return to pending.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#43 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3569 posts

Posted 21 December 2014 - 08:29 AM

So I confirmed the 1850 census WebHint at MyHeritage for my John H. Peters. Then once again I created a new, empty database and hand entered John H. Peters, born 1843, father John W. Peters (no other data) and mother Ruby (no other data). One WebHint appeared for John H. Peters in the new database, the WebHint for the 1850 census. The WebHint was Pending, not Confirmed. MyHeritage did not recognize that my "new" John H. Peters was the same as the John H. Peters whose WebHint I had confirmed.

 

Next I dragged and dropped John W. Peters and Ruby M. Smith and descendants for two generations from my production database into my test database. I wanted to get the data as much the same as possible. At this point, the newly dragged and dropped John H. Peters had two WebHints in the test database, the same two as were in the production database. The one for the tree was pending, just like in the production database. The one for the 1850 census was confirmed, just like in the production database.

 

Finally, I used the "create a new dummy person and merge them with John H. Peters" trick to change the Unique ID for John H. Peters in the test database. Subsequent to doing so, both WebHints reappeared in the test database, but both of them were pending. The linkage to the confirmed WebHint for the 1850 census was lost by changing RM's Unique ID for John H. Peters.

 

Back in my production database, both WebHints for John H. Peters are still there, one confirmed and one pending. The messing around I did in the test database did not confuse MyHeritage with respect to the confirmed WebHint in my production database.

 

Jerry

 

 

P.S. I'm still bothered in this analysis by the fact that the documentation for the API on the MyHeritage web site does not appear to show that the RM Unique ID has anything to do with anything. But if so, why does changing the RM Unique ID cause a WebHint to go from Confirmed to Pending?



#44 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3569 posts

Posted 21 December 2014 - 08:50 AM

My provisional conclusion is that it's probably safe to use MyHeritage's WebHints, including to confirm and reject them - at least for record matches. I'm not going to confirm or reject tree matches, and I probably won't use tree matches except rarely, and then only as a way to contact a fellow researcher who is researching the same ancestors as me. I certainly won't confirm or reject tree matches.

 

Which is to say, I think that unless I share GEDCOM with other users which includes my RM Unique ID's, or unless I share MyHeritage hash strings with other users, there is no reasonable way for other users to see any of my information that MyHeritage is storing on its servers nor to see my WebHint confirmations and rejections. But for MyHeritage to say it is not storing such data for WebHints clearly is technically incorrect and ethically seems a little disingenuous to me. It obviously really is storing the data. And it can't simply cache the data for a while and then get rid of it without destroying the record of my WebHint confirmations and rejections.

 

Jerry



#45 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6252 posts

Posted 21 December 2014 - 02:39 PM

The MyHeritage Privacy Policy for RootsMagic says (emphasis added)

When Smart Matching™ and Record Matching are enabled within RootsMagic, information from small parts of your family tree is periodically passed, 'behind the scenes' and without you having to do anything, to a matching service on the MyHeritage website. This information includes names, dates and places associated with individuals and their close relatives. MyHeritage uses this data to find extremely accurate Smart Matches™ and Record Matches for the relevant individuals. This information is not collected by MyHeritage and is deleted automatically after matches are calculated and displayed to you. Smart Matches™ are not bi-directional: RootsMagic users receive them with trees of MyHeritage users, but MyHeritage users do not receive them with trees of RootsMagic users.

This is even more explicit than the media release. The natural inference is that the automatic deletion is immediate; that it could be months or years after is beyond belief.

 

That said, I disagree that the deletion of the info used for matching should also destroy the record of confirmed and rejected matches. A match is made on the basis of the info now destroyed and a hash that is dependent in part on the RM UID is returned to RM's WebHints. When confirmed or rejected, that information is no longer needed by those "matches" because they need only be tied to the hash or some decrypted part of it (e.g. the RM UID). After the info is deleted, the next time you use WebHints on that person from the same database or a copy thereof, the info transmitted includes the RM UID or part thereof which MyHeritage uses to look up records that were confirmed or rejected. It uses the other info to search again through its databases to find matches that have not been confirmed or rejected.

 

We know that the URLs to the MyHeritage pages for matches are NOT https; they are http so the information that WebHints has sent to MyHeritage is being returned insecurely. I don't know what protocol is used for transmitting from RootsMagic to MyHeritage; Jerry, I think you said it was https -how do you know?


Edited by TomH, 21 December 2014 - 02:39 PM.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#46 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3569 posts

Posted 21 December 2014 - 04:38 PM

Jerry, I think you said it was https -how do you know?

 

My bad. They clearly are http rather than https.

 

As far as the MyHeritage Privacy Policy, they have to be keeping something about matches. Otherwise, they couldn't distinguish confirmed or rejected matches from pending matches in the future. It is certainly the case that they can find the matches themselves again without saving any data. It's the pending vs. confirmed vs. rejected status that requires that something be saved. So you are suggesting that they are only saving the hash (or some part of it) permanently, and that they are deleting the other data from my RM database within some unknown short or long period of time.

 

From a technical point of view, that would certainly work. In fact, it's quite clever. Indeed, there would be no reason (performance or otherwise) that I could think of not to delete everything but the hash (or some part of it) more or less immediately. If that's what's happening,I would be very content. I wonder if it could be confirmed that they are really deleting everything but the hash, and how long they are keeping the rest of the information cached.

 

Jerry



#47 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6252 posts

Posted 21 December 2014 - 05:15 PM

 I wonder if it could be confirmed that they are really deleting everything but the hash, and how long they are keeping the rest of the information cached.

I was thinking about creating a database with a test group of people, all with RM UIDs unique to that database. Do WebHints on a couple of them, confirm some matches, reject some matches. Click on the links to Confirmed (I can concoct Rejected), snapshot and Bookmark them in the browser. Destroy the database so there is no chance of refreshing anything via WebHints. Revisit the bookmarks periodically and see what, if anything, changes over time.

 

Edit: I'm still seeing the RootsMagic tree info beside these Confirmed matches and that was posted 5 days ago but I suspect I have been back into that database since and WebHints could have done its thing.


Edited by TomH, 21 December 2014 - 05:19 PM.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#48 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6252 posts

Posted 13 January 2015 - 10:01 PM

I was thinking about creating a database with a test group of people, all with RM UIDs unique to that database. Do WebHints on a couple of them, confirm some matches, reject some matches. Click on the links to Confirmed (I can concoct Rejected), snapshot and Bookmark them in the browser. Destroy the database so there is no chance of refreshing anything via WebHints. Revisit the bookmarks periodically and see what, if anything, changes over time.
 
Edit: I'm still seeing the RootsMagic tree info beside these Confirmed matches and that was posted 5 days ago but I suspect I have been back into that database since and WebHints could have done its thing.

Three weeks later and MyHeritage still has not thrown away the data it got from my database via RootsMagic's WebHints process.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#49 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6252 posts

Posted 26 February 2015 - 12:10 PM

Now it has been over two months since I confirmed these WebHints on MyHeritage and the "In my RootsMagic Tree" data is still being returned from their server...


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.