Improve documentation of privacy controls

[hartenthaler]

In my tree there are several records of still living persons. In the user interface they are marked using a open lock, after mouse over it is indicated "record is public". But in reality I think this record is private.

[DavidMStraub]

Hi, interesting, that's surprising. Does the record show as private in Gramps Desktop?

You could use the browser developer console (F12) and network analysis tab to look at the raw data coming back from the API call to /api/people/<some-handle>, it should have a key privacy which is true or false.

[hartenthaler]

As an example: the record of my mother (still living). That record is indicated "public" in Gramps (desktop) and in Gramps Web as well, but because she is still living this record should be private. But maybe I do not understand the privacy concept of Gramps. In my desktop application, it does not matter, because I'm the only user. But in a web application, this should be handled differently.

I tried to find the API call answer in my browser developer console (Edge and Chrome), but could not find it.

[DavidMStraub]

Ok, indeed that is intended behaviour. We need to check where to make the documentation clearer.

[Nick-Hall]

The Gedcom 7.0 RESN tag allows the options Confidential, Locked and Privacy. In some implementations the Privacy option is assigned by an algorithm, possibly to identify living individuals.

This is something to consider for a future release. It seems to be more useful for a web application than the desktop version.

[hartenthaler]

RESN is a GEDCOM tag in 5.5.1, too.

Privacy should not depend on RESN only. The idea behind RESN is to indicate special situations. For example to hide a already dead person in some situations. Living persons should be always private to public visitors. They can be shown to family members only.

It should be possible to mark photos or sources as private.

It is very strange to me to find data about a living person indicated in an Internet application marked as "public".

[DavidMStraub]

Ok, let me elaborate because there are a couple of misunderstandings here.

First of all, Gramps Web is never "public" - it's intentionally not meant to be shared with the public internet, but only with a selected group of users. When Gramps says a record is "public", what is really meant is that it's not "private". In the context of Gramps Web, it means that all logged-in users can see the record. The options a tree owner has for access permissions are:

• Editor: can view private records and edit all records
• Contributor: can view private records and add new records
• Member: can view private records
• Guest: cannot view private records

One of the great benefits of Gramps' architecture from a security point of view is that these permissions are imposed at the database level, i.e. a "Guest" user does not "see" the full database, but only a view with private records removed. That makes it very unlikely that bugs in some view functions accidentally expose private data.

Now, regarding data of living people being private, that's obviously a very common choice, but we do not impose this choice but leave it up to the tree owner to decide. It's also actually quite hard to implement rigorously. Gramps has a built-in feature to estimate whether a given person is probably alive, and this is used e.g. for filtering living people out in reports, but what about media files, notes, sources, repositories? It's possible to define an algorithm where secondary objects that have links (or links of links) to people who are probably alive are hidden, but it is difficult to make foolproof and is also necessarily slow (because you have to check several levels of links between objects).

But in the end, whether a person can access something or not is always a binary decision: yes or no. So the "private" property in Gramps is perfectly suited for it. It's also not limited to objects themselves, but also to references or secondary objects. E.g. you can have a public person with a private name, or a private reference to a public source. So it's very powerful.

Now, your case is special because you imported a large amount of data via Gedcom (which is not recommended) and expected something particular (namely, that data from living people is automatically marked as "private"). This is not the case.

The "Gramps" way to handle such a case would be to import the Gedcom in Gramps desktop and use filters (Gramps has very powerful filters!) to identify all the data you want to hide. When you are done building your filter (e.g. a living people filter, which is built into Gramps as metioned above), you simply apply use the "set privacy" menu option to apply the "private" property to the filter.

For instance, in my case, I hide all data from living people except the name, but I am considering making the birth dates public because I only have relatives as users and they are complaining they can't see the birthdays. Another example in favour of giving control to the tree owner is that I wouldn't want all the data, notes etc. I have collected about a person to become accessible the moment they die.

This is an example where the combination of desktop & web app is really powerful. Gramps Web is not meant as a replacement of Gramps, so there is no strong motivation to add features like batch database manipulation that is only relevant for the tree owner when prepaing a new tree and that is already supported by Gramps.

I think we need to add a dedicated page in the documentation explaining all that.

[hartenthaler]

Ok, I understood already that the webtrees user role "guest" (not logged in user) does not exist in Gramps Web. So "public" has another meaning (can be viewed by a Gramps Web Guest).

Interestingly, the privacy concept is implemented in the database itself. This is secure and performant. Ok, the Gramps concept is that the user is responsible for adding the "private" property to objects (in webtrees there are automated functions to decide "privacy"; for example, if a person is assumed to be still alive, the sources and notes related to that person became automatically private, too).

After importing a GEDCOM file setting "private" properties is a very important and time-consuming activity with the possibility to make many errors. It requires Gramps desktop, which is no problem for an experienced Gramps user. For me as a new Gramps user, only interested in using Gramps Web, it makes it much more complex by installing Gramps desktop, learning a new user interface and new complex functions. Setting the "private" property or not depends on who are the Guests and who are the Members in Gramps Web.

The reason behind this is that a multi-user application like Gramps Web needs more security features than a desktop application. Leaving the user alone with that problem is challenging, you should document the steps at least very carefully.

What happens if a Guest user of my tree installed Gramps desktop and synchronizes the database? Can she/he then see the "private" property of objects and can remove them? What happens if a Guest exports a tree? Are the "private" data records written to the XML or GEDCOM file?

[DavidMStraub]

After importing a GEDCOM file setting "private" properties is a very important and time-consuming activity with the possibility to make many errors.

I think you're right, but since this is such a critical part of sharing the own genealogical research, I don't see a good way to skip it. I feel like offering simple default options that hide the actual complexity (e.g. making living people's events private, but potentially not all relevant sources and media objects if not linked/dated correctly) is also dangerous. But I am more than open for any suggestions.

What happens if a Guest user of my tree installed Gramps desktop and synchronizes the database? Can she/he then see the "private" property of objects and can remove them? What happens if a Guest exports a tree? Are the "private" data records written to the XML or GEDCOM file?

Good question, in fact the permissions are encoded in the token that is exchanged on every request with the server and the database connection that is opened at the beginning of the request (before any data is read) selects the right "view". So everything, including exports (Gedcom, XML) and reports (PDF, ...) takes the permissions into account.

A user with "guest" permissions using the sync addon would be able to sync a public-only (non-private) version of the database, but when they have local changes, the sync would fail with a permissions error.