Privacy Model

ggpauly
2010-07-17
2013-05-30
  • ggpauly
    ggpauly
    2010-07-17

    It seems to me that a good privacy policy would be to block public access to any individual who is alive or is a member of a family group that has a living member.

    Although PGV has a wealth of privacy settings, I haven't found a way to set this automatically.  It could be painstakingly implemented on an individual-by-individual case, but would have to be manually updated when a change is needed.

    Is this privacy model sensible?  Am I missing an easier way to implement it?  It seems to address concerns about identity theft while being less restrictive than the "Limit Privacy By Age of Event" policy on the wiki page (http://wiki.phpgedview.net/en/index.php?title=Privacy_File).  That policy leads to hiding individuals who are long dead and have no living immediate family members.

    George

     
  • Stephen Arnold
    Stephen Arnold
    2010-07-17

    George
    Not sure what would be wrong with the current privacy model? Personally, I think hiding anyone who is deceased, but a member of a family group who has remaining living persons is overkill. The model already privatizes all the living persons data and you can easily set the system to not even show boxes, instead of private. If we did as you ask, then you simply would fail to show siblings who die young, or my parents until I and all my siblings are dead.  If that's what you wanted to accomplish, then you can use the Privacy by Age of Event feature you describe and set it to something higher than the sum of two generations (150 years). This too seems to me to be overkill, but effectively what you describe as the action you wish if you don't want anyone from a family group with living persons to be displayed.  The chief problem with this feature comes from a poorly documented or researched GEDCOM, where many dates of death or births are not recorded. On a large GEDCOM, the calculations necessary to create the privacy rules would strain even a faster server.
    -Stephen

     
  • ggpauly
    ggpauly
    2010-07-17

    George Not sure what would be wrong with the current privacy model?

    I should have said "Privacy Policy".  PGV permits many policies, but the one I'm proposing is not easily available.  If you're referring to a "hide living individuals" policy, the problem is that public disclosure of information such a maiden names, former residences, and details of deceased family members' lives may provide fodder for identity thieves and other evil doers, and seems to me generally imprudent.  PGV supports many privacy policies, and your preference may be different, but there is no single "right" or "wrong" policy.  Tho OP began

    … a good privacy policy ..

    , and I meant no implication that there might not be other good or even better policies.

    you can easily set the system to not even show boxes, instead of private

    I did not know this. How is this done?   I've perused the wiki several times and don't recall this.  Is it there?

    If we did as you ask, then you simply would fail to show siblings who die young, or my parents until I and all my siblings are dead

    First, I do not want to force my privacy policy preference on you.  PGV allows many privacy policies and while I have my preferences, my proposal is only to add an additional choice, not remove any existing possible policies.  For my own website the answer is yes for publicly displayed information.  I have discussed this with my family and there is general agreement.   When logged in as an approved user of my PGV site there is more information about publicly hidden available.  In part, this is a genealogy/family history divide.  Family Historians gather more information on living and recently deceased people and require greater privacy.

    If that's what you wanted to accomplish, then you can use the Privacy by Age of Event feature you describe and set it to something higher than the sum of two generations (150 years). This too seems to me to be overkill, but effectively what you describe as the action you wish if you don't want anyone from a family group with living persons to be displayed.

    As I tried to express in the OP, this is indeed over-aggressive.  In practice, I have found that using "Privacy by Age of Event"  is _not_ effectively the same as hiding individuals with living family members.  I had hoped it would be.  As I stated, "That policy leads to hiding individuals who are long dead and have no living immediate family members."  You can see this in the trees displayed on the Welcome page of paulyfamily.org.  All the hidden individuals should be displayed.

    The chief problem with this feature comes from a poorly documented or researched GEDCOM, where many dates of death or births are not recorded.

    The proposed "hiding individuals with living family members" policy requires that the fact of death be recorded for all deceased persons.  However, it solves the problem of missing dates.   Using the  "Privacy by Age of Event" policy requires dates and gives unwanted results if dates are missing.  Dates for some individuals will be missing from even the best-documented and researched genealogy.  On the other hand, the proposed "hiding individuals with living family members" policy does not require dates - only that the fact of death be recorded by adding a death event and minimally checking "yes".  For individuals with birth dates death could be inferred using PGV settings, but this is optional. 

    On a large GEDCOM, the calculations necessary to create the privacy rules would strain even a faster server.

    There is a precomputed "i_isdead" flag in the individuals table.  Relating this to the familes table should be no more resource intensive than other privacy operations on a large Gedcom.   With more work, adding a precomputed  "i_showpublicly" flag to the individuals table would make this as fast or faster than any existing policy.

    To close up, writing this response to a mostly negative reply to my proposal took substantial time from a Saturday morning.  I welcome the opportunity to further flesh out this idea, but unwarranted criticisms are not constructive.    I know I have made some too-negative posts here as well.  So in a spirit of repentance I would like to publicly state that I intend to keep my responses to fellow PGV users considerate in tone and constructive in content.   I believe that excessive negativity reduces forum participation and ultimately may reduce acceptance and use of PGV.  I encourage all forum participants to keep their posts considerate and constructive.

    George

     
  • Stephen Arnold
    Stephen Arnold
    2010-07-17

    George
    Sorry, I hardly found our previous response a personal attack on you or your proposal, only that to do as you suggested was perhaps both resource computationally expansive (regardless of what you consider easy to set a new flag, in that each time there were any change in any data, the flags would have to be recalculated, and hide deceased souls for about 150 years or so (assuming a 75-yr aveerage lifetime) and impractical for displaying gedcom facts.

    Nor did I infer that you tried to propose a system which would be imposed upon anyone as mandatory. I did interpret your suggestion as just that, a suggestion for an additional model. However, I was trying to point out the problems with that particular model - a extraordinarily long 'do-not-show' period averaging 150-years plus and possible resource demands. PGV already commands exceptional computational time for many functions and this poses a problem for those that have their sites hosted on many ISP's.

    Again, there is no right or wrong way, but how facts are recorded affect PGV's displays. As to many facts that might expose information if one party is deceased - yes, although we record RESIDENCE as a family fact when appropriate (whenever a union has been created) and therefore those which follow the date of the union (or where no date is specified, always) are not displayed unless logged in. Other facts are similar, as are most photos which display still-living persons.

    As most obituaries include extremely detailed information on still-living persons, and most facts on partners and issue of deceased souls in recent years (since 1950-ish) are pretty easily discerned from any number of means, I don't get excited about the few facts that show on my father and that might lead to assumptions of who and where and what we are. Someone wishing to go to that extreme can just as easily determine the same information from other sources. We don't use passwords based on family facts or tie accounts to our mothers' maiden names for any security purposes just for these reasons.

    Hope this helps. Personally, I always welcome new ideas like yours for discussion, which I thought was exactly what we were doing. My mistake, I guess.  Just that I don't think hiding deceased souls for an additional 50-100 years following their death would add much to the opportunity to expand our family tree with possible cousins of which we may not currently have any records. By the time they might locate a relative through an Internet search, they too might be dead and obviously couldn't contribute. Then again, that might not be someone's objective - to create as complete a family tree as may be possible.
    -Stephen

     
  • ggpauly
    ggpauly
    2010-07-17

    Many people are very concerned with personal privacy on the internet.   If even one family member has such concerns it may be best to honor their wishes.  Hiding individuals with living family members is one way to address these concerns.  I believe that PGV should take those concerns into consideration.

    The calculations and time spans in Stephen's post above are all in error.  Hiding individuals with living family members would hide individuals for a time span from their birth to the death of their last child or spouse, or their last sibling if they never marry or have children.   In the first case, this span would be about 110 years if an individual's last living child dies at age 80 and was born when the individual was 30.  In the second case it might average about the same or a little more than an individual's life span of about 72 years with a larger variance.  Averaging these cases yields something like 90 to 95 years, not 150 years.  A more sophisticated statistical treatment might give a better average, but probably this is not far off.  To get to 150 years you would need, for example, a person who had a child at the age of 50 and that child lived to the age of 100.  This is an unlikely extreme, not an average.

    But the main point is that this time span is much less than that of Stephen's alternative suggestion to use a "Limit Privacy By Age of Event" policy.  I have been using  the "Limit Privacy By Age of Event" policy and it gives wacky results.  Stephen, who recommends the policy to those who want something more protective than hide living individuals, has evidently never used it.  Just look at paulyfamily.org - all six hidden persons on the four short pedigrees on that page are hidden because of Stephen's recommended "Limit Privacy By Age of Event" policy.  If this site used the proposed "hiding individuals with living family members" policy instead then all 6 hidden individuals would be shown.   Yet Stephen argues that his method is better when it is provably much worse.

    My analysis of resource demands was stated in my second post:

    There is a precomputed "i_isdead" flag in the individuals table. Relating this to the familes table should be no more resource intensive than other privacy operations on a large Gedcom. With more work, adding a precomputed "i_showpublicly" flag to the individuals table would make this as fast or faster than any existing policy.

    So to recap, with a cursory analysis it looks feasible to implement a "hiding individuals with living family members" policy that would give performance on par with other policies for large Gedcoms.  I never stated that it would be easy, only that the second method would be more difficult with better results.  There are likely some puzzles to work out in doing this - I  would not place a bet on it being easy.  However, the second method is really a replacement for the i_isdead flag.  So maybe it wouldn't be much more difficult (on second thought).

    Stephen, if you have something to add to my resource demands analysis then do so.  I haven't looked at the relevant code, only the db structure, so there's likely to plenty to discuss if you want to drill down. But don't misquote it and contradict it without stating a reason.

    George