My vague understanding of Europe’s new GDPR legislation is that email addresses and — shockingly — IP addresses are considered “personal information” and thus Europeans will now have a right to insist that their data be removed on demand from any web service that stores these things.
If that understanding is correct, then it applies to anyone setting up a Fossil repo on the public web who accepts users from Europe. It may even apply to “anonymous,” though I struggle to see how “anonymous” could later come back and say, “My IP was 1.2.3.4, please remove all traces of it.” While I doubt anyone is actually going to do this on my public Fossil instances, the chances increase as the number and size of Fossil instances worldwide increase. Some European may soon be demanding their new rights to a Fossil repo admin. I think the easiest way for this to work, from the user’s perspective, would be to have an “airbrush” button on the Edit User screen in Fossil UI which leaves the user’s record in place so as to avoid referential integrity problems, but which locks the password, removes all permissions, puts junk in the Contact Info field, and obliterates or randomizes the user name. This function would then have to correlate the user’s past actions with particular checkins to anonymize IP addresses somehow. I am not proposing a “delete” function. The user’s work would still be present in the repository. History would be preserved in that what happened in the past remains in the repository; only who and where-from are going away here. I am also not suggesting that Fossil try to do things like remove the user’s name from copyright messages in all historical copies of file header comments, ChangeLogs, AUTHORS files, etc. That’s nearly impossible due to the way Fossil works, I know, which shows how deeply these legislators’ advisors thought about the problem they were setting up. Ahem. :) Hopefully it would suffice for the repository owners to scrub mention of that user from the tips of the open branches. I also expect that such a feature might need to be treated like “shun” in that existing clones might not accept the changed information in a sync unless forced. If so, that’s fine: my vague understanding of GDPR is that it would still be up to the user who wishes to be forgotten to go around to all of the other publicly-accessible clones and make *them* airbrush the user out of history separately. _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
