Live data from Hacker News

GDPR – A Practical Guide for Developers (2017)

techblog.bozho.net

141–150 of 202 posts

Re: GDPR – A Practical Guide for Developers (2017)

#141

Earlier quoted context omitted.

The problem is that pretty much everything seems to be considered personally identifiable data. Any web community will at least be storing usernames, passwords, emails and most likely IP addresses. As far as I know, all of that counts. And even if you don't have a login system, your web server is still going to be logging people's IP addresses.

Usernames are not necessarilly personally identifying, and are freely given by the user to be publicly displayed on a forum. Passwords are not personnally indentifying, and you shouldn't be storing them anyway!

> Usernames are not necessarily personally identifying

Literally the only purpose of usernames is identifying people.

I don't know the actual text of the GDPR, so I don't know the definition of "personally identifying", but I find it very strange that people seem to restrict the definition of "personally identifying" to "connects directly to your IRL identity".

Re: GDPR – A Practical Guide for Developers (2017)

#142
post #137
post #54

I just want to point out that a lot of the article is the authors own opinion on how the regulation should be implemented into software and a lot of things are probably not needed normally and would be a burden for businesses. My own take (and the take of most European data protection lawyers I meet) is that consent is not needed, and also possibly is inappropriate in 90% of the cases - instead the “legal basis” call…

The main processing basis for many entities will be straightforward processing to provide service under Art 6.1.b. Legitimate interests like consent should generally be avoided wherever possible due to the additional burden it places on organisations to document the balancing test you've undertaken, and the potential for it to be questioned in future. Although I fully agree in many cases it will be entirely appropria…

I agree w this too. However, it depends if you have a valid contract with the user and the data processing is sufficiently related to the performance of that contract, if you are going to use that basis.

Notwithstanding Article 5.2 on accountability, I do not believe that non-controversial data processing under legitimate interest needs to be well documented in practice, although I may be proven wrong. I believe it is sufficient to mention legitimate interest and what your legitimate interest is in broad terms in the privacy notice.

For controversial use, that is processing which the data subjects may not approve you of doing, I believe you need documentation on the balancing test. However, in controversial cases you probably also need documentation on the necessity both when it comes to performance of contract and legitimate interest.

Re: GDPR – A Practical Guide for Developers (2017)

#143
post #142
post #137

Earlier quoted context omitted.

The main processing basis for many entities will be straightforward processing to provide service under Art 6.1.b. Legitimate interests like consent should generally be avoided wherever possible due to the additional burden it places on organisations to document the balancing test you've undertaken, and the potential for it to be questioned in future. Although I fully agree in many cases it will be entirely appropria…

I agree w this too. However, it depends if you have a valid contract with the user and the data processing is sufficiently related to the performance of that contract, if you are going to use that basis. Notwithstanding Article 5.2 on accountability, I do not believe that non-controversial data processing under legitimate interest needs to be well documented in practice, although I may be proven wrong. I believe it i…

Sure, maybe it probably doesn't need to be but Article 29 guidance is clear that as a matter of good practice, you should look to document the balancing test you have undertaken to determine legitimate interests is appropriate.

Yes, quite right on the contract side. At the lowest level, a contract could be implied, or would arise from terms of use on a site. Absolutely, processing under the service provision ground should be limited solely to that which is necessary to provide a service.

I guess if you wanted to take things further I suppose on the authentication front, you could argue that authentication/login may not strictly be necessary to provide certain of the services as they could be provided in the absence of a login (creation of a to-do list for example). However my view would be you take things on a broad basis so that if a good proportion of the services required authentication (buying content on the basis of a to-do list) then you could put all service provision under service provision pursuant to a contract rather than splitting between legitimate interests and service provision grounds.

Re: GDPR – A Practical Guide for Developers (2017)

#144
post #143
post #142

Earlier quoted context omitted.

I agree w this too. However, it depends if you have a valid contract with the user and the data processing is sufficiently related to the performance of that contract, if you are going to use that basis. Notwithstanding Article 5.2 on accountability, I do not believe that non-controversial data processing under legitimate interest needs to be well documented in practice, although I may be proven wrong. I believe it i…

Sure, maybe it probably doesn't need to be but Article 29 guidance is clear that as a matter of good practice, you should look to document the balancing test you have undertaken to determine legitimate interests is appropriate. Yes, quite right on the contract side. At the lowest level, a contract could be implied, or would arise from terms of use on a site. Absolutely, processing under the service provision ground s…

I agree with everything in your comment.

Regarding necessity I think it should not be interpreted too strictly. Rather, I believe it means something like this in EU law:

“Necessity implies the need for a combined, fact-based assessment of the effectiveness of the measure for the objective pursued and of whether it is less intrusive compared to other options for achieving the same goal.”

(Quote from: https://edps.europa.eu/sites/edp/files/publication/17-06-01_... )

Re: GDPR – A Practical Guide for Developers (2017)

#145

Few questions: "Forget me" - What is personal information? Say I have a table with user_id and username, and an order table with user_id, order_id and other other stuff. If the user request a 'forget me', what do I delete? Blank the username? Delete the user_id row? Delete all orders belonging to the user (how would I report these gaps to tax agencies)? Delete the user from my trained ML model (is that even possible?…

I will try to answer some of your questions based on my findings for far as I am in the process of modifying 3 webapps to be GDPR compliant and I am also starting a side project.

IANAL and please take this as a starting point. I am not sure that what I understood is correct, but I read the GDPR and this is what I will implement.

> What is personal information

The definition for this is here [0].

What I am doing is I am creating some docs where I write very clearly what information I use and for what.

For existing projects I am looking in schema.db and models and extract from there. For the new one (which will be in Rails) I am thinking to make a gem like annotate or something for this specific purpose.

Also I am documenting the information that is in logs and I will treat most of the information the same way I am treating passwords. So far I am looking for SQL statements, params and custom logging messages.

> Say I have a table with user_id and username, and an order table with user_id, order_id and other other stuff. If the user request a 'forget me', what do I delete

Nothing so far if the user_id and username are not related in any ways to anything that can identify a person.

> To what extent can users be forced to give consent or be denied from a service?

Here is the phrasing from the GDPR [1]: “the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language.” So in my opinion this is very different that the Cookie Law as you must make sure the subject understands for what the consent has been given. You should also take a look at Recital 42 and 43 in the beginning of the GDPR where they talk about “consent freely given” and they describe also an imbalance relation between the controller and the user.

> "Export data" / "See all my data" - What is 'all my data'

This is part of Article 15 and I think the situation you are describing is defined by item (3) of that Article. You should correlate it with the definition of personal data. This means that you should provide data you took from the personal data subject but also the personal data you got from anywhere else that is connected to the data subject - see “personal data are collected from the data subject” and “personal data have not been obtained from the data subject” as it is described in the titles of Article 14 and Article 15.

> “I accept the terms and conditions” would no longer be sufficient to claim that the user has given their consent for processing their data."

Consent cannot be included in the Terms and Conditions. Due to the Recital 42 in the beginning “consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment” and also “safeguards should ensure that the data subject is aware of the fact that and the extent to which consent is given”

> My tax agency requires me to keep records of orders/sales/invoices up to 5 years ago. If a user requests deleting their personal information within that time period, what should I do?

You keep them. Article 17, item (3) states that “shall not apply to the extent that processing is necessary” and you should take a look at letter (b) “for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject”

> "Forget me" - Say an employee leaves a company, and they request their personal information to be deleted.

You I think you should delete everything that is not a subject of the law and that it cannot be used “for the establishment, exercise or defence of legal claims”.

Regarding Git or commits for me it is clear that they will not be deleted as there are part of “the purposes for which they were collected or otherwise processed”. If they are part of a project which is part of a legal contract with some users or beneficiary then also it is ok not to delete the GIT commits because you need the info “for the exercise or defence of legal claims” in case anyone will ask in a court who did that feature and when.

To be 100% sure one way will be to anonymise Git user (did not try that so far) by changing the username to something generated like “user0000113” and email associated with that account.

[0] - http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELE... - Article 4, item (1)

[1] - http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELE... - Artile 7, item (2)

edit: formatting

Re: GDPR – A Practical Guide for Developers (2017)

#146
post #130

Earlier quoted context omitted.

> Paragraphs 1 and 2 shall not apply to the extent that processing is necessary: > [...] > (d) for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing ; (emphasis mine) I'd no…

What if the purpose of the archiving is to not only record what was changed but also who changed it?

From the GDPR, recital 45:

> [...] where processing is necessary for the performance of a task carried out in the public interest [...] the processing should have a basis in Union or Member State law.

I don't think that purpose of archiving has a basis in law.

That said, I do remember my law professor calling the 'right to be forgotten' one of the weaker parts of the GDPR, and I'm not an expert, so it's possible I'm missing something.

Re: GDPR – A Practical Guide for Developers (2017)

#147
What about things explicitly designed in a way that there is no option to be forgotten. What about commits in version control sites? What about mailing lists?

From skimming over the spec, it seems that politicians haven't thought about any other sites than social networks or some other profit making sites. Even in that case, if some ML system is trained on the data of the customer, do they have to re-train after anyone invokes right to be forgotten.

Re: GDPR – A Practical Guide for Developers (2017)

#148
post #125
post #83

Earlier quoted context omitted.

This is the biggest problem with GDPR, there's no agreement what it means, but it will go into effect in a few weeks.

What makes you say that there's no agreement as to what it means? It feels like I see this sort of view expressed quite frequently. My guess is that it's primarily because people want a reason not to look to comply in lots of cases, or to dismiss GDPR. "How can we comply if no one knows what it really means to comply". In many cases, the GDPR simply reiterates/builds upon existing data protection law which has a weal…

What makes you say that there's no agreement as to what it means? It feels like I see this sort of view expressed quite frequently.

One fundamental problem is that the GDPR, if interpreted literally and fully enforced to the letter, is absurdly onerous for any small organisation and allows for fines that pose an existential threat without any requirement for proportionality.

Defenders of the GDPR, including some of the official regulators, often argue that concerns are exaggerated and regulators are likely to take a more pragmatic approach, trying to educate those breaching the rules rather than coming in with crippling fines. Maybe that will turn out to be true, but in past instances of overly powerful or broad EU rules, there certainly have been cases of heavy-handedness by regulators and courts, so it is illogical to rely on another result this time.

In any case, pragmatic enforcement would not make the law itself any better. Those responsible for working with personal data still have to err on the side of going too far in their efforts to comply, and thus finding themselves at a disadvantage compared to their competition who do not, or not going far enough, and then risking a regulator dropping the sword of Damocles at any time, with no objective standard for "far enough".

Re: GDPR – A Practical Guide for Developers (2017)

#149

Earlier quoted context omitted.

Like pollution laws, it's nonsense if not enforced worldwide. The web can't be contained to a specific locality anymore, it's against the core idea of the technology. The people in the EU who are responsible for this have no clue about the technology.

The GDPR specifically states that any processing of EU citizens personal / private data essentially two huge things come out of GDPR - personal data about a EU citizen belongs to that citizen, and if you process data about an EU citizen even if you are out of the EU, you are covered by this law (extra-territoriality) These are huge forward thinking political steps. they do get this stuff. I just think the deletion pa…

It just sounds good, but in a more or less open world, small businesses selling digital products will just block EU access, even if they're physically located in the EU. Opening a company in the US is easy.

Re: GDPR – A Practical Guide for Developers (2017)

#150

Earlier quoted context omitted.

a) The problem with this is that this practical guide was released in November 29, 2017. And this is unofficial. EU should have released a practical guide two years ago in my opinion. If the process is gradual the law should reflect that. c) Good to hear :). Apparently it's this: https://ico.org.uk/for-organisations/guide-to-the-general-da... - I hope it's not written from the perspective of the UK legislation. d) Th…

Every country has a slightly different implementation of the directive, so I don't think the EU will have a single example to give.

However, GDPR is a regulation, not a directive. I haven't seen that countries pass their own implementation of it.
Post reply on HN