[article] GDPR: Biggest pain points, now and later
On 16-05-18 19:36, VM Brasseur wrote:
https://enterprisersproject.com/article/2018/5/gdpr-biggest-pain-points-now-... _______________________________________________
None of them would hit my top five, as a GDPR practitioner. Regards, Walter
On 05/16/2018 11:16 PM, Walter van Holst wrote: Hi,
https://enterprisersproject.com/article/2018/5/gdpr-biggest-pain-points-now-... _______________________________________________
None of them would hit my top five, as a GDPR practitioner.
Maybe it is better to elaborate what issues you do see. To be honest, I don't think the GDPR is such a burden, certainly not for OS projects. Yes, professional users of your software inside the EU have to make a list of the data they are processing, yes they have to think about why they are processing it, yes they need to think what legal base the processing has, yes they have to inform their users, yes the users have rights like viewing their data and the right to request deletion. But almost all of these were already mandatory under the previous EU directive, all of these are part of showing respect to your users, all of these are already in line with the spirit of open source software. So, what GDPR-pain do you have? To answer that question myself: while working at the GDPR project for the XMPP Standards Foundation, if feels to me like doing a due check-up of data policies and a due reviewing of policies about adapting or not adapting to local laws. The only pain may be the pressure everybody feels. But that is IMHO a necessity to get moving. Winfried -- privacy consultant e-health +31.6.23303960 https://www.tilanus.com/
On 17-05-18 01:34, Winfried Tilanus wrote:
On 05/16/2018 11:16 PM, Walter van Holst wrote:
Hi,
https://enterprisersproject.com/article/2018/5/gdpr-biggest-pain-points-now-...
_______________________________________________
None of them would hit my top five, as a GDPR practitioner.
Maybe it is better to elaborate what issues you do see.
I don't see many issues with the GDPR (it is imperfect, of course)
To be honest, I don't think the GDPR is such a burden, certainly not for OS projects.
Neither do I, that's why I find that article so poor. Your own mail was a better description of the issues organisations have to look into for GDPR compliance than the article itself. Regards, Walter
Hi Winfried, On 17 May 2018 at 00:34, Winfried Tilanus <winfried@tilanus.com> wrote:
Maybe it is better to elaborate what issues you do see.
To be honest, I don't think the GDPR is such a burden, certainly not for OS projects.
I disagree. You're right below, that the GDPR encodes good principles, and those who have been conscientiously following best practice for privacy will not have an issue. However, it's well documented on this list what the issues are. Many of the tools used in open-source development have distributed PII far and wide, and do not have good mechanisms to deal with it. Scrubbing Bugzilla is difficult. Mailman requires a massive amount of text parsing, as it distributes PII through the headers as well as mail bodies: stripping information from there involves scraping through files in three formats, decoding MIME, and even then basic tools like grep are insufficient, because the PII might be split across line breaks with quote marks in between. No-one has yet come up with a solution for GIt, which is fundamentally intractable. Many of these platforms (including mine - freedesktop.org) have historically been understaffed on the admin and tooling side. So yes, if we had all been doing a much better job then there would be no problem. But that's plainly not the case today; if there was no problem, then there would be no need for this list. Sweeping 'there is no burden' statements do not help those of us tasked with the burden of picking up the pieces (many of us doing so in our own spare time). I joined the list in the hope of practical advice and solutions to the very real problems myself and others face; if it's just to be lectured at by people in a far less bad position, then the list is of no value to me. Cheers, Daniel
On 2018-05-17 10:39, Daniel Stone wrote:
However, it's well documented on this list what the issues are.
I am new to the list, Moritz asked me to join, so bear with me. Should I trawl the archives or is it worth your time to write down a sort of to-do list of issues that worth looking into by people with GDPR expertise? Mailman especially is of interest to me. I don't think distribution of personal data through headers is a problem per se, but only to the extent necessary for mailman to function. A thing I would be willing to contribute to would be a list of good practices for mailman operators. Plus a wish-list for mailman maintainers of features to make it more privacy-by-default, or more easy for operators to be GDPR-compliant. Other tools that would have my interesst are SugarCRM and WordPress since both are used by a lot of people in the NGO space. Lastly: I am not saying there is no burden, I am mostly pointing out that a lot of claims in the (non-EU) press about the GDPR are beside the point (and often simply untrue). Regards, Walter
On 05/17/2018 10:39 AM, Daniel Stone wrote: Hi Daniel, First of all: my excuses for the delay in my answer, it is a quite busy time for me right now (ahem).
However, it's well documented on this list what the issues are.
My reaction may have been a bit grumpy: right now I spent quite a lot of my time debunking all kind of more or less silly myths about the GDPR. A post on this list with only a link to a blog that is totally irrelevant is the last thing we need and a waste of my time. But if there are problems, I love to spend some of my time to help OS projects where I can.
Many of the tools used in open-source development have distributed PII far and wide, and do not have good mechanisms to deal with it.
Yes, I recognize that pattern: many OS projects use different tools/services to do their work. Each of them has to be considered on its own. But also in many cases those tools reside under the responsibility of somebody else. GitHub for example is a data controller on its own. As OS project you don't have to deal with the (potential) GDPR issues GitHub may have.
Scrubbing Bugzilla is difficult. Mailman requires a massive amount of text parsing, as it distributes PII through the headers as well as mail bodies: stripping information from there involves scraping through files in three formats, decoding MIME, and even then basic tools like grep are insufficient, because the PII might be split across line breaks with quote marks in between.
No-one has yet come up with a solution for GIt, which is fundamentally intractable.
My first question is: is the GDPR applicable? For OS projects the rule will be (roughly) if the data processing is done within the EU OR if you explicitly offer services to EU citizens it is. Otherwise: not. Other questions are: is there a pressing need that is countering the GDPR. With mailman for example freedom of speech (to right engage in a discussion to be precise) easily interferes with the right to be forgotten. Freedom of speech prevails. Git has the pressing need of maintaining code integrity and traceability. The final decision will be up to a judge, but my bets are on the need of maintaining the code. Something similar will be the case with Bugzilla. Also when people obviously publish themselves some information about themselves, the bar is much lower then when you for example observe (browsing)behaviour. All these things need to be judged from case to case, but in the examples you name, many of the exceptions in the GDPR pop up.
Many of these platforms (including mine - freedesktop.org) have historically been understaffed on the admin and tooling side.
I took a quick glance at your activities on freedesktop.org and my first impression is that you are not even under the jurisdiction of the GDPR: The legal entity behind freedesktop.org (SPI) is US based AND nowhere on you site I see signs of explicitly offering services to EU citizens. That EU citizens make use of your services is not relevant, you are not explicitly targeting them. So you appear to be outside the GDPR jurisdiction. If you (or somebody else) have activities you are in doubt about, please post to this list, so we can have a look at it.
So yes, if we had all been doing a much better job then there would be no problem. But that's plainly not the case today; if there was no problem, then there would be no need for this list.
There certainly are problems (dealing with some of them in the context of XMPP at the XSF right now), but IMHO a big part of the problem is the panic. So one of the tasks of a list like this (and there are other tasks too) will be to reduce the problem to its real size and avoid panic.
Sweeping 'there is no burden' statements do not help those of us tasked with the burden of picking up the pieces (many of us doing so in our own spare time). I joined the list in the hope of practical advice and solutions to the very real problems myself and others face; if it's just to be lectured at by people in a far less bad position, then the list is of no value to me.
Would it have value to you if it becomes clear on this list that you are of the hook? Don't get me wrong: the GDPR does pose problems in a number of cases and I am willing to help people who feel the burden of it. But lets not panic and avoid that we invest our valuable time in solving issues that are not there. CU! Winfried -- privacy consultant e-health +31.6.23303960 https://www.tilanus.com/
On Tue, May 22, 2018 at 3:57 AM, Winfried Tilanus <winfried@tilanus.com> wrote:
On 05/17/2018 10:39 AM, Daniel Stone wrote:
Hi Daniel,
Hi Winfried,
First of all: my excuses for the delay in my answer, it is a quite busy time for me right now (ahem).
However, it's well documented on this list what the issues are.
My reaction may have been a bit grumpy: right now I spent quite a lot of my time debunking all kind of more or less silly myths about the GDPR. A post on this list with only a link to a blog that is totally irrelevant is the last thing we need and a waste of my time. But if there are problems, I love to spend some of my time to help OS projects where I can.
Many of the tools used in open-source development have distributed PII far and wide, and do not have good mechanisms to deal with it.
Yes, I recognize that pattern: many OS projects use different tools/services to do their work. Each of them has to be considered on its own. But also in many cases those tools reside under the responsibility of somebody else. GitHub for example is a data controller on its own. As OS project you don't have to deal with the (potential) GDPR issues GitHub may have.
Scrubbing Bugzilla is difficult. Mailman requires a massive amount of text parsing, as it distributes PII through the headers as well as mail bodies: stripping information from there involves scraping through files in three formats, decoding MIME, and even then basic tools like grep are insufficient, because the PII might be split across line breaks with quote marks in between.
No-one has yet come up with a solution for GIt, which is fundamentally intractable.
My first question is: is the GDPR applicable? For OS projects the rule will be (roughly) if the data processing is done within the EU OR if you explicitly offer services to EU citizens it is. Otherwise: not.
Other questions are: is there a pressing need that is countering the GDPR. With mailman for example freedom of speech (to right engage in a discussion to be precise) easily interferes with the right to be forgotten. Freedom of speech prevails. Git has the pressing need of maintaining code integrity and traceability. The final decision will be up to a judge, but my bets are on the need of maintaining the code. Something similar will be the case with Bugzilla.
Is there anywhere where the order of priority for this is written? (preferably on the EU Commission or a national regulators website)
From what I've understood thus far, if you get a request for removal you basically have to remove it (and given the costs of defending your position and the penalties if the court finds against you, the standing action is probably going to be to do a removal regardless of what the GDPR actually says)
Also when people obviously publish themselves some information about themselves, the bar is much lower then when you for example observe (browsing)behaviour.
All these things need to be judged from case to case, but in the examples you name, many of the exceptions in the GDPR pop up.
Many of these platforms (including mine - freedesktop.org) have historically been understaffed on the admin and tooling side.
I took a quick glance at your activities on freedesktop.org and my first impression is that you are not even under the jurisdiction of the GDPR: The legal entity behind freedesktop.org (SPI) is US based AND nowhere on you site I see signs of explicitly offering services to EU citizens. That EU citizens make use of your services is not relevant, you are not explicitly targeting them. So you appear to be outside the GDPR jurisdiction.
If you (or somebody else) have activities you are in doubt about, please post to this list, so we can have a look at it.
So yes, if we had all been doing a much better job then there would be no problem. But that's plainly not the case today; if there was no problem, then there would be no need for this list.
There certainly are problems (dealing with some of them in the context of XMPP at the XSF right now), but IMHO a big part of the problem is the panic. So one of the tasks of a list like this (and there are other tasks too) will be to reduce the problem to its real size and avoid panic.
Sweeping 'there is no burden' statements do not help those of us tasked with the burden of picking up the pieces (many of us doing so in our own spare time). I joined the list in the hope of practical advice and solutions to the very real problems myself and others face; if it's just to be lectured at by people in a far less bad position, then the list is of no value to me.
Would it have value to you if it becomes clear on this list that you are of the hook?
Don't get me wrong: the GDPR does pose problems in a number of cases and I am willing to help people who feel the burden of it. But lets not panic and avoid that we invest our valuable time in solving issues that are not there.
KDE unfortunately is well and truly on the hook (being a European organisation) so there is no easy out for us. Website registrations can be dealt with easily enough, and while inconvenient, mailing list archives can be expunged (which will break historical links, but if we leave the gap then people can just use the wayback machine to grab the pages) so i'm not too concerned with those. The big problem I truly see is Git and Subversion (usernames, along with the accounts mapping file in it which has names and email addresses in it - changing those requires a full repository rewrite as well - which would probably take a long time with our repository).
CU!
Winfried
Cheers, Ben Cooksley KDE Sysadmin
-- privacy consultant e-health +31.6.23303960 https://www.tilanus.com/
_______________________________________________ gdpr-discuss mailing list gdpr-discuss@earth.li https://www.earth.li/mailman/listinfo/gdpr-discuss
On 2018-05-22 13:21, Ben Cooksley wrote:
From what I've understood thus far, if you get a request for removal you basically have to remove it (and given the costs of defending your position and the penalties if the court finds against you, the standing action is probably going to be to do a removal regardless of what the GDPR actually says)
I would give an empathical no. Do (re)read art. 17 GDPR and you will notice that there are plenty of circumstances in which there is room to refuse to remove. One of the cases there is an unqualified obligation to remove is if the processing is solely based on consent. In a lot of cases this is not the case. For example in a source code repository. Or a mailinglist archive. Regards, Walter
On 22-05-18 13:21, Ben Cooksley wrote:
On Tue, May 22, 2018 at 3:57 AM, Winfried Tilanus <winfried@tilanus.com> wrote:
Hi Ben,
Other questions are: is there a pressing need that is countering the GDPR. With mailman for example freedom of speech (to right engage in a discussion to be precise) easily interferes with the right to be forgotten. Freedom of speech prevails. Git has the pressing need of maintaining code integrity and traceability. The final decision will be up to a judge, but my bets are on the need of maintaining the code. Something similar will be the case with Bugzilla.
Is there anywhere where the order of priority for this is written? (preferably on the EU Commission or a national regulators website)
From what I've understood thus far, if you get a request for removal you basically have to remove it (and given the costs of defending your position and the penalties if the court finds against you, the standing action is probably going to be to do a removal regardless of what the GDPR actually says)
I wish I could answer your question with a short link that ends al discussion. Unfortunately these 'pressing needs' are a hairy problem: it is one principle against an other (data protection against freedom of speech and data protection against the need of code integrity). There is no absolute order, it is always a JUDGEment from case to case. So yes, unfortunately the ultimate verdict will be costly. The only light I see there, is that the national data protection authorities act as a buffer between you and the court. Complaints have to go to them and not directly to court. And on the freedom of speech: that is one of areas where the national governments have some room to set their own rules, not making this easier. Having said that, there is some case law about how far freedom of speech extends, and that is quite far. One of the most notable is (and thanks to Arnoud Engelfriet for pointing me to this one) item 61 of this http://curia.europa.eu/juris/document/document.jsf?docid=76075&doclang=EN verdict by the European Court of Justice: "It follows from all of the above that activities such as those involved in the main proceedings, relating to data from documents which are in the public domain under national legislation, may be classified as ‘journalistic activities’ if their object is the disclosure to the public of information, opinions or ideas, irrespective of the medium which is used to transmit them. They are not limited to media undertakings and may be undertaken for profit-making purposes." Does a mailing list meet this definition? I don't know for sure but "if their object is the disclosure to the public of information, opinions or ideas" seems to be valid for a mailing list. The Dutch law accompanying the GDPR puts all of chapter III out of order when the activities meet the definition above. I see KDE(.org) is German, so you should check the German laws that accompany the GDPR, but I expect there to be a similar clause in Germany too.
KDE unfortunately is well and truly on the hook (being a European organisation) so there is no easy out for us.
Website registrations can be dealt with easily enough, and while inconvenient, mailing list archives can be expunged (which will break historical links, but if we leave the gap then people can just use the wayback machine to grab the pages) so i'm not too concerned with those.
Without expunging, you have to have good story about the need to keep the history available. But beside the freedom of speech (see above) in OS projects the need to document choices made in the past is quite big. I am pretty sure these will prevail in most cases when it is brought to court. The right to be forgotten was introduced in a case of a Spanish man who was bankrupted several years ago but who had paid of his debts and was financial healthy for several years. But on Google his past was still hunting him and hindering his current business. So Google was ordered to remove references to the bankruptcy of this man. But when an Italian criminal tried to use the same mechanism to hide past crimes and convictions, the need of warning the public for this criminal was regarded more important then his right to be forgotten. So when you Google this mans name, you still see his (long) criminal history. So I would only honour requests to remove postings from your mailinglist if the postings are obviously not relevant for the discussion but harmful for the person who posted them, for example postings made in a intoxicated state or during a psychological crisis.
The big problem I truly see is Git and Subversion (usernames, along with the accounts mapping file in it which has names and email addresses in it - changing those requires a full repository rewrite as well - which would probably take a long time with our repository).
Did you read the other postings this week about git? I am pretty sure they can be helpful here. Summary: "Git should not be seen as a changeable medium and therefore the rights of 'data subjects' (us) should be met in other ways. Fortunately git has some possibilities for that." Winfried -- privacy consultant e-health +31.6.23303960 https://www.tilanus.com/
On Wed, May 23, 2018 at 10:09 AM, Winfried Tilanus <winfried@tilanus.com> wrote:
On 22-05-18 13:21, Ben Cooksley wrote:
On Tue, May 22, 2018 at 3:57 AM, Winfried Tilanus <winfried@tilanus.com> wrote:
Hi Ben,
Hi Winfried,
Other questions are: is there a pressing need that is countering the GDPR. With mailman for example freedom of speech (to right engage in a discussion to be precise) easily interferes with the right to be forgotten. Freedom of speech prevails. Git has the pressing need of maintaining code integrity and traceability. The final decision will be up to a judge, but my bets are on the need of maintaining the code. Something similar will be the case with Bugzilla.
Is there anywhere where the order of priority for this is written? (preferably on the EU Commission or a national regulators website)
From what I've understood thus far, if you get a request for removal you basically have to remove it (and given the costs of defending your position and the penalties if the court finds against you, the standing action is probably going to be to do a removal regardless of what the GDPR actually says)
I wish I could answer your question with a short link that ends al discussion. Unfortunately these 'pressing needs' are a hairy problem: it is one principle against an other (data protection against freedom of speech and data protection against the need of code integrity). There is no absolute order, it is always a JUDGEment from case to case. So yes, unfortunately the ultimate verdict will be costly. The only light I see there, is that the national data protection authorities act as a buffer between you and the court. Complaints have to go to them and not directly to court. And on the freedom of speech: that is one of areas where the national governments have some room to set their own rules, not making this easier.
That's what I was expecting unfortunately :(
Having said that, there is some case law about how far freedom of speech extends, and that is quite far. One of the most notable is (and thanks to Arnoud Engelfriet for pointing me to this one) item 61 of this http://curia.europa.eu/juris/document/document.jsf?docid=76075&doclang=EN verdict by the European Court of Justice:
"It follows from all of the above that activities such as those involved in the main proceedings, relating to data from documents which are in the public domain under national legislation, may be classified as ‘journalistic activities’ if their object is the disclosure to the public of information, opinions or ideas, irrespective of the medium which is used to transmit them. They are not limited to media undertakings and may be undertaken for profit-making purposes."
Does a mailing list meet this definition? I don't know for sure but "if their object is the disclosure to the public of information, opinions or ideas" seems to be valid for a mailing list.
The Dutch law accompanying the GDPR puts all of chapter III out of order when the activities meet the definition above. I see KDE(.org) is German, so you should check the German laws that accompany the GDPR, but I expect there to be a similar clause in Germany too.
Unfortunately German law is all in German, so i'll have to find someone to do that for me (language barriers really help...)
KDE unfortunately is well and truly on the hook (being a European organisation) so there is no easy out for us.
Website registrations can be dealt with easily enough, and while inconvenient, mailing list archives can be expunged (which will break historical links, but if we leave the gap then people can just use the wayback machine to grab the pages) so i'm not too concerned with those.
Without expunging, you have to have good story about the need to keep the history available. But beside the freedom of speech (see above) in OS projects the need to document choices made in the past is quite big. I am pretty sure these will prevail in most cases when it is brought to court.
The right to be forgotten was introduced in a case of a Spanish man who was bankrupted several years ago but who had paid of his debts and was financial healthy for several years. But on Google his past was still hunting him and hindering his current business. So Google was ordered to remove references to the bankruptcy of this man.
But when an Italian criminal tried to use the same mechanism to hide past crimes and convictions, the need of warning the public for this criminal was regarded more important then his right to be forgotten. So when you Google this mans name, you still see his (long) criminal history.
So I would only honour requests to remove postings from your mailinglist if the postings are obviously not relevant for the discussion but harmful for the person who posted them, for example postings made in a intoxicated state or during a psychological crisis.
Historically most of the requests we have had in the case of our mailing lists are when people have submitted nonsense bugs. The response from developers has usually left these people quite embarrassed, and we've historically complied with these requests (as there is no value in retaining them)
The big problem I truly see is Git and Subversion (usernames, along with the accounts mapping file in it which has names and email addresses in it - changing those requires a full repository rewrite as well - which would probably take a long time with our repository).
Did you read the other postings this week about git? I am pretty sure they can be helpful here. Summary: "Git should not be seen as a changeable medium and therefore the rights of 'data subjects' (us) should be met in other ways. Fortunately git has some possibilities for that."
Just seen that thread yes. The position that Git is an unchangable medium (subject to mailmaps for amendments) is one i'm quite happy to see.
Winfried
Regards, Ben
-- privacy consultant e-health +31.6.23303960 https://www.tilanus.com/
On 26-05-18 02:12, Ben Cooksley wrote: Hi Ben,
Unfortunately German law is all in German, so i'll have to find someone to do that for me (language barriers really help...)
Take a look at: https://iapp.org/resources/article/eu-member-state-gdpr-implementation-laws-... It is the best source I know for the status of the local laws, some of them even have summaries in English. I did a quick scan of the German law, I didn't see an extension for freedom of speech there.
Historically most of the requests we have had in the case of our mailing lists are when people have submitted nonsense bugs. The response from developers has usually left these people quite embarrassed, and we've historically complied with these requests (as there is no value in retaining them)
Well that are the bugs I look at most before submitting mine! :-D But on a more serious note: one of the reasons for existence of the GDPR is to avoid social exclusion based on data (the other one is to avoid manipulation). I have no idea how the balance would tip in such a case. When weighing the need for a historical archive against the interest of the 'data subject', then a big issue is how harmful the historical data is, does it lead to social exclusion? The only, totally unhelpful, answer I can give here is: I love to see case law on this. Winfried -- privacy consultant e-health +31.6.23303960 https://www.tilanus.com/
On 2018-05-26 10:56, Winfried Tilanus wrote:
On 26-05-18 02:12, Ben Cooksley wrote:
Hi Ben,
Unfortunately German law is all in German, so i'll have to find someone to do that for me (language barriers really help...)
Take a look at:
https://iapp.org/resources/article/eu-member-state-gdpr-implementation-laws-...
It is the best source I know for the status of the local laws, some of them even have summaries in English. I did a quick scan of the German law, I didn't see an extension for freedom of speech there.
For the purpose of source repositories and online mailinglist archives, section 28 may be of interest. Regards, Walter
On 05/26/2018 01:34 PM, Walter van Holst wrote: Hi, [On the German implementation law to the GDPR:]
It is the best source I know for the status of the local laws, some of them even have summaries in English. I did a quick scan of the German law, I didn't see an extension for freedom of speech there.
For the purpose of source repositories and online mailinglist archives, section 28 may be of interest.
[Thanks to Walter for an off-list clarication & pointer] I was confused for a moment, thinking you pointed to the GDPR itself, but you mean the German implementation law, translated here: https://iapp.org/media/pdf/resource_center/Eng-trans-Germany-DPL.pdf Section 28 seems indeed applicable to versioning control of OS source code and OS mailing lists. Winfried -- privacy consultant e-health +31.6.23303960 https://www.tilanus.com/
participants (5)
-
Ben Cooksley -
Daniel Stone -
VM Brasseur -
Walter van Holst -
Winfried Tilanus