Personal data in RefPerSys
Like git the RefPerSys system will keep a small amount of personal data. FWIW,
git has a
git config command where you would configure a limited amount of personal data: every one knows that he/she should
git config --global user.name "John Doe" git config --global user.email email@example.com
what kind of personal data?
In RefPerSys, it will be the same, as documented in our
refpersys-design.pdf draft document (figure 4, page 23, section §3.4.2 concrete examples of objects, commit 34794f43) -which you can build with LaTeX utilities using
doc/design-ideas followed by
The amount of data is similar and close to what
git processes: your first and last name, your email.
By social convention, only a given human contributor is allowed to add more personal data about himself/herself (e.g. a phone number, an age, etc...). However, we are not naïve: we do know that, in principle, the RefPerSys could make HTTP requests (e.g. using QNetworkRequest or libcurl, etc...) to access e.g. Google. For a detailed analysis, read for example Shoshana Zuboff's paper Big other: surveillance capitalism and the prospects of an information civilization
why RefPerSys would use personal data?
Exactly like in a wiki system or in a LibreOffice document , it is useful to record what human being has contributed some particular piece of data or of knowledge to RefPerSys. Concretely, some expert system rule in RefPerSys might be represented by an object with an hypothetical attribute
authors associated to a set of persons reification (i.e. to a set of RefPerSys objects representing or reifying human beings).
How could RefPerSys know about the person using it?
Technically, a running
./refpersys process might be informed of the identity of the current user through perhaps some
REFPERSYS_USER_OID environment variable (see environ(7) and getenv(3), etc...), or later with getuid(2) combined with getpwuid(3)
future examples of personal data uses.
We could easily imagine that specific components of the knowledge base of RefPerSys would carry the identities of the human contributors to RefPerSys. This will facilitate communication between humans: e.g. if person A knows that rule R has been recently edited by persons B and C, then person A could send an email to persons B and C asking for clarification.
user specific preference
Each user could have his/her preference. Not only graphical ones (which font should be used, what background color is preferable) but also more semantic ones: "to what depth a given complex data structure would be displayed", or about the frequency of garbage collections, etc....
It is highly probable that we could simply use
git facilities to find out what person has contributed to what. It is however more convenient to also keep that information inside RefPerSys. Using just
git would require us to parse the output of
git diff on JSON data, which is not convenient.
Since we are not lawyers, it is not known to us why using
gitlab) is legally conforming with General Data Protection Regulation. Some lawyers told verbally us that they don't know why
git is GDPR compliant, but presume it is (by some common sense argument) until some court decided otherwise.
It is also not known -since we are not lawyers- to us why RefPerSys is GDPR compliant, but by socially requiring that each contributor commits (using a signed git commit, so with a
git commit -s his own personal data himself, we believe acting in good faith.
Once a human being has registered himself/herself in RefPerSys, it is technically difficult (and perhaps practically impossible) to remove such personal data. By analogy, it would be difficult to remove every contribution to GCC made by Basile Starynkevitch.
Beware that we are not lawyers, and are not qualified to give any legal advice
Caveats relating to disseminating the notice
RpsQCreateContributorDialog class, a cogent notice is being displayed, warning the potential contributor of the ramifications of adding herself as a contributor with respect to her personal data. As of now, this notice is hard coded in the
However, there are a few points to consider with this approach.
- From a legal point of view, the user has no way of reading this notice, until (s)he explicitly clicks the Create | create Contributor menu option. This is analogous to a purchaser of proprietary software not being able to read the EULA (End User License Agreement) until (s)he explicitly starts the installation process. In both cases, there are grounds for the malicious contributor and end user to wrongfully claim that owing to an unforeseen bug, the notice / EULA was not displayed. However, if the notice/EULA file is provided as a separate file which can be read by the contributor / user, in addition to being displayed at the appropriate context, then one important grounds for malicious intent are mitigate.
- If the notice is hard coded, the contributor does not have an easy way to share the notice with her lawyer if (s)he chooses to do so before registering as a contributor. However, if there is a separate notice file, that file could be easily shared with contributor's lawyer if (s)he wished to do so. So, we are facilitating the chance for the contributor to take legal advice before registering as a contributor. Again, this prevents any malicious person from taking advantage of this loophole
- Since RefPerSys is GPL licensed, any contributor could potentially change the wording of the personal data notice. If the notice is hard coded, changes to the notice could be git committed along with other changes to the
window_qrps.ccfile, and a quick glance at the git diff might result in the reviewer missing out on a change to the notice. However, if the personal data notice is in a separate file, even a quick glance at the git log and diff will make it immediately apparent that the notice has changed.
- If the personal data notice is in a separate file, we could have the option of creating a Git pre-commit hook that computes the MD5 digest of that file and thereby either emits a warning or aborts the commit if there is a change to the notice.
The considerations above could apply after our primordial bootstrap milestone has been reached. Before that, nobody cares, since nobody is using RefPerSys except some team members.