On Mon, Oct 1, 2018 at 4:31 AM Morgan (GitHub Staff) <[hidden email]> wrote:
Furthermore CVE has a policy that when requesting a CVE you MUST use a working email address so that
2) CVE users can contact the original requestor for clarification/details/etc
CC'ing the CVE board as I've brought this issue up (how do we handle GDPR related issues) as this provides a good example. Also CC'ing Robert/Marko as they had asked in a previous email how github can help the DWF (a major part would be ensuring trolls don't get people booted off of github). Thanks!
Also to be clear if you look at the artifact it explicitly states that replying with "I accept" means it gets posted publicly (I even provide the URL):
On Mon, Oct 1, 2018 at 9:48 AM Kurt Seifried <[hidden email]> wrote:
On Wed, Oct 10, 2018 at 9:50 AM Morgan (GitHub Support) <[hidden email]> wrote:
This isn't entirely true. You can't for example call your local tax authority and tell them you're withdrawing consent from being processed. For a variety of business process and technology and legal reasons it is possible for this "right to be forgotten" to not universally apply.
I already did, I thought it was at an end and then they made this complaint. I think an appropriate solution is "you consented, TWICE, to publishing your email address publicly, you could have chosen NOT to give consent and used an alternate email address specifically for this purpose, as such we are not removing your data".
To the board: it looks like the CVE community will need to stop using GitHub until this is resolved as their current interpretation of GDPR essentially makes it impossible for the DWF to use the CVE data people submit (as they can revoke it, even after agreeing in a positive manner). I will be transitioning the DWF off of GitHub when I have time. I also suspect this means MITRE and others cannot use GitHub safely as well.
They were explicitly notified in the email, that they then had to reply to with "I accept" typed in. By removing the artifact I'd also have to revoke the CVE and REJECT it. I would also note that their email data is in a variety of other places like the cvelist git repo (in a branch), and in MITRE's backend database.
As I said before GDPR has a variety of aspects, one of which is often referred to as "the right to be forgotten", but this is not absolute (my favourite example being the tax avoidance strategy =). If we acquiesce to this demand then the DWF cannot exist in GitHub.
What happens if I withdraw my consent for [hidden email]?
This is a major problem that we need to actually solve in some way. Part of it will be finding providers that are "Safe".
On Wed, Oct 10, 2018 at 11:52 AM Lisa Olson <[hidden email]> wrote:
My intepretation of their request differs to yours -- if they are invoking
GDPR to have that entry removed then remove that entry[*], there doesn't
seem to be any reason why their acceptance of terms email needs to be
public as long as DWF have a copy. Them asking for removal of their
personal data from the public doesn't mean they've revoked their
acceptance of those terms or you should alter any CVE they've filed.
This wouldn't in my mind trigger any of the clauses for why you'd be able
to reject the "right to forget".
> What happens if I withdraw my consent for
> [hidden email]?
Well, that wouldn't be defined as personal information under GDPR (and
you're not an EU citizen).
> This is a major problem that we need to actually solve in some way. Part of
> it will be finding providers that are "Safe".
Dealing with GDPR requests will be the same no matter where you store DWF.
Some providers might just not have figured out their process for handling
[* "remove" has some interesting side effects in Git, depending on if
Github want you to rewrite history so it never happened (bleh!) or just
commit a removal (so it's actually still in the history)]
On Thu, Oct 11, 2018 at 1:28 AM Mark J Cox <[hidden email]> wrote:
So how do we know this protonmail email address is PII? How do we know that person is in Europe?
The problem is GitHub appears to have an overly broad interpretation of GDPR which puts our data and project at risk.
|Free forum by Nabble||Edit this page|