git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Peter Backes" <rtc@helen.PLASMA.Xg8.DE>, "David Lang" <david@lang.hm>
Cc: "Æ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 22:28:47 +0100	[thread overview]
Message-ID: <3EF5AC29192A4D179B6D8689ECB991CC@PhilipOakley> (raw)
In-Reply-To: 20180607063225.GA28343@helen.PLASMA.Xg8.DE

Hi Peter, David,

I thought that the legal notice (aka 'disclaimer') was pretty reaonable.

Some of Peter's fine distinctions may be technically valid, but that does 
not stop there being legal grounds. The proof of copyright is a legal 
grounds.

Unfortunately once one gets into legal nitpicking the wording becomes 
tortuous and helps no-one.

If one starts from an absolute "right to be forgotten" perspective one can 
demand all evidence of wrong doing , or authority to do something, be 
forgotten. The GDPR has the right to retain such evidence.

I'll try and comment where I see the distinctions to be.

From: "Peter Backes" <rtc@helen.PLASMA.Xg8.DE>

> 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 simply an information statement

>       This is inevitable,
>> because it is a main feature git.

The "inevitable" word creates a point of argument within the GDPR. Removing 
the word (and 'because/main') brings the sentance back to be an informative 
statement without a GDPR claim.
>
> 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.

The [key] missing information here is whether rsyslog has a DCO (Developer 
Certificate of Origin) and what that contains.

The git.git DCO is here 
https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L304-L349

This will also help discriminate between the "name" part and the <unique> 
identifier, as both could be separately anonymised (given the right DCO). 
Thus it may be that the name is recored as "anonymous", but with a 
<uid@known.place> that bridges the legal evidence/right to be forgotten 
bridge.
>
> 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).

Within the GDPR, that is correct. It (breaking history validation), of 
itself, should not be the reason.

>      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.

Publishing (the meta data) is *distinct* from having it.

However publishing the content and it's legal copyright is also associated 
with identifying the copyright holder (who has released it). This can be the 
uid if they hide behind a legal entity. This creates the catch 22 scenario. 
You either start off public and stay public, or you start off private and 
stay there.

Whether the rsyslog folk want to accept copyrighted work without appropriate 
legal release (who guards the guards, what's their badge number?) is part of 
the same information requirement.

Malicious intent makes the submission (commit) part of a legal evidence one 
needs to retain, so is supported by GDPR.

>
> 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.

The onward publishing and release should be by refernce to the DCO, and not 
that it's the Git way. As Peter notes, the 'Git way' (solely by itself) is 
no defence.
>
> 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.
>

To me, the key legal document is the DCO (and the law on which it stands). 
It is that which either conveys the rights, or does not. If the DCO is too 
loose then folk will be able to walk away from their malign code, and demand 
that someone else take responsibility for protecting them from it.

Philip 


  reply	other threads:[~2018-06-07 21:56 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
2018-06-07 21:28                     ` Philip Oakley [this message]
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=3EF5AC29192A4D179B6D8689ECB991CC@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=avarab@gmail.com \
    --cc=david@lang.hm \
    --cc=git@vger.kernel.org \
    --cc=rtc@helen.PLASMA.Xg8.DE \
    /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).