From: Peter Backes <rtc@helen.PLASMA.Xg8.DE>
To: David Lang <david@lang.hm>
Cc: "Philip Oakley" <philipoakley@iee.org>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: GDPR compliance best practices?
Date: Thu, 7 Jun 2018 08:32:25 +0200 [thread overview]
Message-ID: <20180607063225.GA28343@helen.PLASMA.Xg8.DE> (raw)
In-Reply-To: <alpine.DEB.2.02.1806061831340.7659@nftneq.ynat.uz>
Hi David,
thanks for your input on the issue.
> LEGAL GDPR NOTICE:
> According to the European data protection laws (GDPR), we would like to make you
> aware that contributing to rsyslog via git will permanently store the
> name and email address you provide as well as the actual commit and the
> time and date you made it inside git's version history. This is inevitable,
> because it is a main feature git.
As we can, see, rsyslog tries to solve the issue by the already
discussed legal "technology" of disclaimers (which is certainly not
accepted as state of the art technology by the GDPR). In essence, they
are giving excuses for why they are not honoring the right to be
forgotten.
Disclaimers do not work. They have no legal effect, they are placebos.
The GDPR does not accept such excuses. If it would, companies could
arbitrarily design their data storage such as to make it "the main
feature" to not honor the right to be forgotten and/or other GDPR
rights. It is obvious that this cannot work, as it would completely
undermine those rights.
The GDPR honors technology as a means to protect the individual's
rights, not as a means to subvert them.
> If you are concerned about your
> privacy, we strongly recommend to use
>
> --author "anonymous <gdpr@example.com>"
>
> together with your commit.
This can only be a solution if the project rejects any commits which
are not anonymous.
> However, we have valid reasons why we cannot remove that information
> later on. The reasons are:
>
> * this would break git history and make future merges unworkable
This is not a valid excuse (see above). The technology has to be
designed or applied in such a way that the individuals rights are
honored, not the other way around.
In absence of other means, the project has to rewrite history if it
gets a valid request by someone exercising his right to be forgotten,
even if that causes a lot of hazzle for everyone.
> * the rsyslog projects has legitimate interest to keep a permanent record of the
> contributor identity, once given, for
> - copyright verification
> - being able to provide proof should a malicious commit be made
True, but that doesn't justify publishing that information and keeping
it published even when someone exercises his right to be forgotten.
In that case, "legitimate interest" is not enough. There need to be
"overriding legitimate grounds". I don't see them here.
> Please also note that your commit is public and as such will potentially be
> processed by many third-parties. Git's distributed nature makes it impossible
> to track where exactly your commit, and thus your personal data, will be stored
> and be processed. If you would not like to accept this risk, please do either
> commit anonymously or refrain from contributing to the rsyslog project.
This is one of those statements that ultimately say "we do not honor
the GDPR; either accept that or don't submit". That's the old, arguably
ignorant mentality, and won't stand.
The project has to have a legal basis for publishing the personal
metadata contained in the repository. In doubt, it needs to be consent
based, as that is practically the only basis that allows putting the
data on the internet for everyone to download. And consent can be
withdrawn at any time.
The GDPR's transitional period started over two years ago. There was
enough time to get everything GDPR compliant.
It might be possible to implement my solution without changing git,
btw. Simply use the anonymous hash as author name, and store the random
number and the author as a git-notes. git-notes can be rewritten or
deleted at any time without changing the commit ID. I am currently
looking into this solution. One just needs to add something that can
verify and resolve those anonymous hashes.
Best wishes
Peter
--
Peter Backes, rtc@helen.PLASMA.Xg8.DE
next prev parent reply other threads:[~2018-06-07 6:32 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 19:15 GDPR compliance best practices? Peter Backes
2018-04-17 21:38 ` Ævar Arnfjörð Bjarmason
2018-04-17 23:25 ` Peter Backes
2018-06-03 9:27 ` Peter Backes
2018-06-03 10:45 ` Ævar Arnfjörð Bjarmason
2018-06-03 11:25 ` Peter Backes
2018-06-03 12:59 ` Ævar Arnfjörð Bjarmason
2018-06-03 14:18 ` Peter Backes
2018-06-03 15:28 ` Philip Oakley
2018-06-03 17:46 ` Peter Backes
2018-06-03 18:18 ` Theodore Y. Ts'o
2018-06-03 19:11 ` Peter Backes
2018-06-03 19:24 ` Peter Backes
2018-06-03 20:07 ` Theodore Y. Ts'o
2018-06-03 20:52 ` Peter Backes
2018-06-03 21:03 ` Theodore Y. Ts'o
2018-06-03 22:16 ` Peter Backes
2018-06-04 13:47 ` Theodore Y. Ts'o
2018-06-04 18:22 ` Peter Backes
2018-06-03 22:28 ` Philip Oakley
2018-06-03 23:01 ` Peter Backes
2018-06-04 12:24 ` Philip Oakley
2018-06-07 1:38 ` David Lang
2018-06-07 6:32 ` Peter Backes [this message]
2018-06-07 21:28 ` Philip Oakley
2018-06-07 22:34 ` Peter Backes
2018-06-07 22:38 ` David Lang
2018-06-07 23:21 ` Peter Backes
2018-06-07 23:53 ` David Lang
2018-06-08 6:16 ` Peter Backes
2018-06-08 7:42 ` David Lang
2018-06-08 11:58 ` Peter Backes
2018-06-08 18:51 ` David Lang
2018-06-12 18:56 ` David Lang
2018-06-12 19:12 ` Peter Backes
2018-06-12 19:16 ` Martin Fick
2018-06-13 14:12 ` Theodore Y. Ts'o
2018-06-13 14:48 ` Peter Backes
2018-06-08 2:53 ` Theodore Y. Ts'o
2018-06-08 6:26 ` Peter Backes
2018-06-08 8:13 ` Ævar Arnfjörð Bjarmason
2018-06-08 12:03 ` Peter Backes
2018-06-08 22:53 ` Ævar Arnfjörð Bjarmason
2018-06-08 14:45 ` Theodore Y. Ts'o
2018-06-08 16:02 ` Peter Backes
2018-06-08 22:09 ` Johannes Sixt
2018-06-09 22:50 ` Philip Oakley
2018-06-10 1:41 ` Theodore Y. Ts'o
2018-06-03 17:54 ` Philip Oakley
2018-06-03 19:48 ` Ævar Arnfjörð Bjarmason
2018-06-03 20:24 ` Peter Backes
2018-06-08 22:42 ` Jonathan Nieder
2018-06-08 23:00 ` Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180607063225.GA28343@helen.PLASMA.Xg8.DE \
--to=rtc@helen.plasma.xg8.de \
--cc=avarab@gmail.com \
--cc=david@lang.hm \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).