Please do NOT expect all Feature Requests to be actioned automatically. Describing your proposal here will ensure the development team are aware of it, and they will give it careful consideration.

TOPIC: Improved privacy managment

Improved privacy managment 1 week 6 days ago #1

  • avdl
  • avdl's Avatar
  • Offline
  • Junior
  • Posts: 146
Hello,
i've been using webtrees for years and i globally appreciate the way privacy is managed.
The system has one major problem: members who want to had living people further than a the path length chosen by the admin in their profile, can add children they wont be able to see once accepted.
Those members think their adds were not added so they try again and again creating duplicates children and/or partner.

I usually end up giving them access to the whole database but that's not a good idea.

My proposal is: could any member/editor have access to all living people within their path length AND to any individual/family/record they added (or modified ?) by themselves ?

Regards,
andré

ps: any idea welcome to solve or get around this problem
Last Edit: 1 week 6 days ago by avdl.
The administrator has disabled public write access.

Improved privacy managment 1 week 5 days ago #2

  • bertkoor
  • bertkoor's Avatar
  • Offline
  • Gold
  • Greetings from Utrecht, Holland
  • Posts: 1675
avdl wrote:
members who want to had living people further than a the path length chosen by the admin in their profile, can add children they wont be able to see once accepted.
Those members think their adds were not added so they try again and again creating duplicates children and/or partner.

I usually end up giving them access to the whole database but that's not a good idea.

To me it sounds like it could be solved rather easily by extending their restriction path length by two or three. Because they have factual knowledge about private information of people beyond the numbers of steps you had assumed.

On the other hand, then there is a concern about leaking otherwise private information in other branches of the tree. So if you want to keep that under control, the current system doesn't suffice.

One solution could be to make a link between the editor and a remote individual, say it's Jane Doe: the wife of the brother of their mother: 3 steps. And suppose you have the privacy path length restricted to 3 as well. If the editor adds a sibling to Jane Doe, that's 4 steps and out of reach.
Now the solution: add an association between the editor and Jane Doe. The most suitable could be "friend". In raw GEDCOM, where I1234 is the xref of Jane Doe:
1 ASSO @[email protected]
2 RELA friend

Now the privacy route from the editor to Jane Doe is only one step! So the editor now has further access to the family around Jane Doe.
stamboom.BertKoor.nl runs on webtrees v1.7.13
The administrator has disabled public write access.

Improved privacy managment 1 week 3 days ago #3

  • avdl
  • avdl's Avatar
  • Offline
  • Junior
  • Posts: 146
avdl wrote:
One solution could be to make a link between the editor and a remote individual, say it's Jane Doe: the wife of the brother of their mother: 3 steps. And suppose you have the privacy path length restricted to 3 as well. If the editor adds a sibling to Jane Doe, that's 4 steps and out of reach.
Now the solution: add an association between the editor and Jane Doe. The most suitable could be "friend". In raw GEDCOM, where I1234 is the xref of Jane Doe:
1 ASSO @[email protected]
2 RELA friend

Now the privacy route from the editor to Jane Doe is only one step! So the editor now has further access to the family around Jane Doe.

I tried this both ways (adding a relation from the member to a far related cousin versus adding a relation from the far related cousin to to the member, both ways won't change anything, privacy's circle does not change (i'm rather gald about that because stating a relationship does not change family privacy matters, as far as i'm thinking about privacy.

I'm stuck into a real problem: editors of my database had far ancestors of their own tree (branches not related to me / other members) and them try to fill all descending branches of their ancestors ...
Example: Editor Daniel (my eleventh cousin) is filling his tree.
He just added his fourth cousin Arnold (10 steps from him in their relationship) and is unable to add Arnold's descendants.

That was possible with PGV which had two indi records assigned to editors
one for their own record in the tree
another for the indi the relationship restriction was applied on. This made it possible to give the ability to an editors to edit about all the descendants of a given ancestor. This function disappeared in the early versions of webtrees.

Could someone please advice me about how to solve this recurrent problem ?
Last Edit: 1 week 3 days ago by avdl.
The administrator has disabled public write access.

Improved privacy managment 1 week 3 days ago #4

  • fisharebest
  • fisharebest's Avatar
  • Offline
  • Administrator
  • Posts: 11741
A difficult question.

We can change the logic, but there will always be a limit - the most distant relative - and people will always want to view/edit "just one more step".

I guess that here, it is working as intended. It is restricting to "close relatives".
Your user is adding a 4th cousin (10 steps). This is a "distant relative".

Another strategy might be to restrict to cousins (and spouses?).

Any other suggestions?
Greg Roach - This email address is being protected from spambots. You need JavaScript enabled to view it. - fisharebest.webtrees.net
The administrator has disabled public write access.

Improved privacy managment 1 week 3 days ago #5

  • norwegian_sardines
  • norwegian_sardines's Avatar
  • Offline
  • Gold
  • Posts: 1545
Greg, as you said this is a difficult question!
The system has one major problem: members who want to had living people further than a the path length chosen by the admin in their profile, can add children they wont be able to see once accepted.
AND to any individual/family/record they added (or modified ?) by themselves ?

Maybe we should prevent adding people that are not in their path length, therefore they are not “authorized” to see.

One reason to prevent people from seeing individuals not in their path is to protect living individual’s data from getting into the wrong hands, but one could argue that creating information that is potentially wrong or worse damaging, could also violate that individual’s privacy.

My answer to the problem kind of come from a different angle.

In a collaborative environment you must invite collaborators, and with this understand a collaborator is only collaborating to add their immediate family information, not to add large amounts of family, UNLESS you grant them full access so they can fully participate in the collection of information. Also living individuals should have some rights to their data and therefore should input and maintain their own information.
Ken
The administrator has disabled public write access.

Improved privacy managment 1 week 3 days ago #6

  • avdl
  • avdl's Avatar
  • Offline
  • Junior
  • Posts: 146
the current privacy system is indeed good and i do not imagine a way to think it better !!

But couldn't we apply it differently:
- currently, Individual record, using "Restrict to immediate family", steps are computed on the individual a user is linked to. (is this obviously a good choice ?)
- if we could restrict the relationships based on another indi (one of the user's ancestor), things could be far better (in my case i guess it would solve all of the limits i'm experiencing with my users)

We agree encountered problems occur for users adding or editing living indis to families inside their restricted zone.
Example: Editor Daniel (my eleventh cousin) is filling his tree.
He just added his fourth cousin Arnold (10 steps from him in their relationship) and is unable to add Arnold's descendants.
The distance currently calculated is most often twice what it should be: in case mentioned above, 4th cousin (10 steps far), we count first steps to go up to the common ancestor and then steps go down to the cousin. If i could say my user Daniel restrictions is 6 steps down from his ancestor (referred in his profile as root for restriction calculating), i would not have any problem and i guess server would have far less to compute ?
Yet i still want Daniel to be linked to his own record for his diagrams and reports.

is my speech clear, understandable (English is not my native language); i hope so ?
Last Edit: 1 week 1 day ago by avdl.
The administrator has disabled public write access.
Powered by Kunena Forum