Live data from Hacker News

GDPR – A Practical Guide for Developers (2017)

techblog.bozho.net

191–200 of 202 posts

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

#191
post #173

Earlier quoted context omitted.

By first coming to grips with the fact that this isn't your data... The trouble is that you haven't adopted any objective or actionable position here. It's easy to pass the buck with more questions. What small organisations need is simple, verifiable answers. The absence of such answers from authoritative sources is possibly the single greatest criticism being made of the GDPR. Why do you say something is not necessa…

> The trouble is that you haven't adopted any objective or actionable position here. What, that you don't own someone else's personal data? If someone signs up for your service, you do not own their email address and cannot use it in a way they wouldn't want. What part of that is unclear? > You said it was good advice to mask off the bottom bits of the IP address If it wasn't needed. You keep dropping this, so maybe…

What, that you don't own someone else's personal data?

No, sorry, I was referring to your whole opening section, which was a response to my question, "How can anyone possibly make a reasonable, intelligent, a priori assessment of how long that data will be useful for that kind of purpose?"

My point is that even something as "simple" as deciding how long you should retain some data that you originally acquired and have used for some obviously legitimate purpose is not necessarily an easy question. These are the sorts of issues where I'm arguing that small organisations really need simple, concise, clear guidance.

You've linked to a few pages on the ICO's site throughout this discussion. I note in passing that reading and understanding them fully would take many hours, even just looking at the high-level guides and checklists, and having done so, they still leave numerous subjects open to interpretation or judgement where someone would probably need real legal advice to find out where they might stand in practice.

Now, if you're a business with an in-house legal team and an in-house IT team and a turnover well into the millions and a designated management structure and established processes for doing most things, that's probably not a big deal. But if you're three guys running an Internet startup from someone's bedroom, or even a significantly more established online business but not large enough for dedicated IT staff or in-house lawyers (which is still the scale that the vast majority of businesses are working at), no-one has time to read through dozens of pages of "guidance" full of subjective-anyway legalese. You need clear, actionable guidance, and you need a clear, unambiguous legal framework.

I would argue that expecting even a good faith effort at compliance from many of those smaller businesses is unrealistic, given the "support" available today. They're just going to break the law, either of out of ignorance or out of apathy, and either way the law didn't achieve anything useful in all of those cases. That then means that any of us who are concerned with trying to do the right thing and do want to understand our real legal obligations will automatically be at a disadvantage. That's not a good way to encourage compliance or to support smaller businesses growing (and in particular, growing responsibly and legally).

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

#192
post #176

Earlier quoted context omitted.

You keep mentioning how you're consulting on this issue at the moment and claiming that those of us more cautious than you just don't understand how European law works. Would you mind sharing a little more to justify that authority -- what qualifications do you have that we don't, what sorts of business are you consulting with and how much is compliance (including your advice) costing them, and why is your interpreta…

Hi Silhouette, I'm not claiming anyone more cautious than me doesn't understand how European law works. That's just silly. I also don't know what qualifications I have that you don't. What qualifications do you have? The sorts of business I am consulting to are sales and marketing agencies based in the US. As an SME I work with their in-house council to help them understand what the business is doing. I also help def…

First of all, please let me apologise if my previous comment came across as unnecessarily aggressive. Looking over the thread today, it could be read as quite hostile, which wasn't my intent.

My concern here is that in this discussion (and indeed in other recent HN discussions around the GDPR), you have on several occasions relied on your role as a consultant to support statements that various actions weren't necessary because of the GDPR, and to dismiss some of the potential legal arguments/concerns that several of us have raised suggesting otherwise as if they are some sort of legal trickery and EU courts/legal systems would not like them.

I claim no special qualifications in this area. I'm just a guy who is running businesses that might be affected by the new law and wants them to do the right thing, but wants that right thing to be practical and to know that we're on safe legal ground with it. Naturally I also talk to others in a similar position from time to time, and occasionally with consultants or lawyers active in the field, and so I know that many others share similar concerns and are asking the same sorts of questions.

What I'm seeing is that most of the experts are arguing for things like a "risk-based approach", which is the standard CYA consultant/lawyer answer to almost anything where they can't say "We don't actually know either, but you'll probably get away with it if you don't rock the boat". My point is that this is not good enough. The EU and member state authorities have form, as I've written about elsewhere, for introducing overly broad laws with insufficient safeguards and insufficient consideration for small businesses, and for then causing real and sometimes very serious damage to those smaller businesses in practice afterwards.

This is why I'm arguing that the GDPR as it stands is a bad law. This is why I want to see clear, concise, unambiguous answers from authoritative sources on issues around backups, log/journal-based records, and the like. And this is why I'm asking what your own qualifications are and what you know that we don't, given that just a couple of comments up you have casually dismissed concerns that many of us seem to have as being "silly", when those concerns are based on reading what the GDPR actually says and the ambiguity that we're hearing from other experts who don't seem to share your clear view of the subject.

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

#193
post #173

Earlier quoted context omitted.

> The trouble is that you haven't adopted any objective or actionable position here. What, that you don't own someone else's personal data? If someone signs up for your service, you do not own their email address and cannot use it in a way they wouldn't want. What part of that is unclear? > You said it was good advice to mask off the bottom bits of the IP address If it wasn't needed. You keep dropping this, so maybe…

What, that you don't own someone else's personal data? No, sorry, I was referring to your whole opening section, which was a response to my question, "How can anyone possibly make a reasonable, intelligent, a priori assessment of how long that data will be useful for that kind of purpose?" My point is that even something as "simple" as deciding how long you should retain some data that you originally acquired and hav…

> No, sorry, I was referring to your whole opening section, which was a response to my question, "How can anyone possibly make a reasonable, intelligent, a priori assessment of how long that data will be useful for that kind of purpose?"f

Doesn't matter.

It's not your data.

It's their personal data.

You may use it as long as it benefits them; As long as they would want you to.

Why do I want a site to have my email address? To send me notifications I've requested? To facilitate a password recovery process I initiate? To send me marketing material that I am interested in? Surely it's obvious that if I change my mind, that's up to me.

Why do I want a site to have my IP address? To help protect my account? Sure. For blacklisting addresses that try to log into my account with an invalid password? Of course.

See? Specific examples are easy. Enumerating them is hard though, which is why European courts don't do that. They rely on organisations like the ICO to field questions, make a judgement call, and publish guidance for frequently asked questions. But for the most part, it's just common sense.

> My point is that even something as "simple" as deciding how long you should retain some data that you originally acquired and have used for some obviously legitimate purpose is not necessarily an easy question.

You should keep it for as short a period as possible.

The longer you keep personal data, the longer it is at risk. Remember you're also responsible for keeping that data safe. If you get hacked and lose control of that data, you're responsible!

> You've linked to a few pages on the ICO's site throughout this discussion. I note in passing that reading and understanding them fully would take many hours, even just looking at the high-level guides and checklists, and having done so, they still leave numerous subjects open to interpretation or judgement where someone would probably need real legal advice to find out where they might stand in practice.

Understanding how to pay tax in the US correctly takes much more than "many hours", and very often requires professional advice.

However very few people worry about tax on millions when their income is under $100; Very few companies need to worry about how to handle millions of requests for erasure when they don't even have any personal data.

But some prudence helps: Simply "not keeping data you don't need" is the ICO's advice. It's also best practices for IT security.

Take the few hours to understand it. If you've got specific questions, I might try to answer them, but you're unlikely to have more than a few for your specific business case, and you'll find legal advice for those questions cheaper than tax advice.

> I would argue that expecting even a good faith effort at compliance from many of those smaller businesses is unrealistic

Well, good luck with that.

My experience with European regulators like the ICO is that they're not going to be amused by your argument.

Given that most of this has been law for decades is a big part of why I think it's not unrealistic.

> That then means that any of us who are concerned with trying to do the right thing and do want to understand our real legal obligations will automatically be at a disadvantage.

Then do the right thing: Treat the data as the person would want it treated. Make sure you are proactive and do your best. Don't worry so much that someone else is going to treat people a little worse so you need to abuse people as much as is legally permitted.

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

#194
post #176

Earlier quoted context omitted.

Hi Silhouette, I'm not claiming anyone more cautious than me doesn't understand how European law works. That's just silly. I also don't know what qualifications I have that you don't. What qualifications do you have? The sorts of business I am consulting to are sales and marketing agencies based in the US. As an SME I work with their in-house council to help them understand what the business is doing. I also help def…

First of all, please let me apologise if my previous comment came across as unnecessarily aggressive. Looking over the thread today, it could be read as quite hostile, which wasn't my intent. My concern here is that in this discussion (and indeed in other recent HN discussions around the GDPR), you have on several occasions relied on your role as a consultant to support statements that various actions weren't necessa…

> [I'm just a guy that] wants that right thing to be practical and to know that we're on safe legal ground with it.

Then explain clearly and specifically what thing you want to do that you believe isn't practical. Please say exactly what you want to do that you think is reasonable but that the GDPR says isn't.

- You don't need to destroy invoices. [1] [2]

- You don't need to delete web logs (if you block out the bottom octet of the IP addresses) [3]

- You don't need to delete web logs if you're using them to prevent fraud [4]

- You don't need to delete the record of them asking you to stop using their data [5] [6]

- You don't need to reprocess all of your backups [7] [8]

- You don't have to recall any reports you might have sent out [9]

Those are everything that I labelled as silly with a link to the authority and a supporting opinion if I think that the authority isn't clear.

If you see someone with a contrary opinion, my offer remains to try and refute any specific example.

> What I'm seeing is that most of the experts are arguing for things like a "risk-based approach", which is the standard CYA consultant/lawyer answer to almost anything

The ICO recommends something similar, but it's not just about rocking the boat: If you're not putting people at risk, and you're not pissing anyone off, then you're probably not going to have trouble because an honest examination of your processes isn't going to reveal neglect or recklessness of another kind.

> and for then causing real and sometimes very serious damage to those smaller businesses in practice afterwards.

A citation would be helpful.

I suspect there's a balance: Are we harming a smaller business that was being inappropriate? Putting people's data at risk? What exactly are we talking about?

[1]: https://ico.org.uk/for-organisations/guide-to-the-general-da...

[2]: https://www.planetverify.com/impact-of-the-eu-gdpr-on-accoun...

[3]: https://ico.org.uk/media/for-organisations/documents/1591/pe...

[4]: http://www.privacy-regulation.eu/en/recital-47-GDPR.htm

[5]: https://www.twobirds.com/~/media/pdfs/gdpr-pdfs/34--guide-to...

[6]: http://www.privacy-regulation.eu/en/recital-65-GDPR.htm (note especially you keep the data in order to comply)

[7]: https://community.jisc.ac.uk/blogs/regulatory-developments/a...

[8]: https://ico.org.uk/media/for-organisations/documents/1475/de...

[9]: https://ico.org.uk/for-organisations/guide-to-data-protectio...

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

#195

Earlier quoted context omitted.

How is that personal, how is it connected to a person?

On the off-chance that you are not asking this in bad faith… All speculators go through a KYC with their exchange, which identifies them very precisely. All other users paste it publicly, saying “I own this account! Send me money.” And even those users often have to convert it back to fiat, which requires an exchange, which makes them go through a KYC.

Ah, right, Bitcoin exchanges in USA, and elsewhere, harbour personal identifiable information. Bitcoin doesn't impose it, but it's a practical requirement in some jurisdictions.

(KYC = know your customers)

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

#197

Earlier quoted context omitted.

You don't have to delete these logs when someone emails you if they're still useful for those purposes. You do need to delete those logs eventually though, and you need to disclose how often that is. It can be ten years if you want. That sort of argument has worked pretty well for Disney and friends when it comes to extending copyright indefinitely and yet not technically violating the US constitution's "temporary" w…

I'm still grasping GDPR myself, but in terms of deleting users from backups might be solved via uids. Each user should also have a uid that isn't PII by itself. Upon getting a eraser request you remove everything and preserve the uid and flag it. Then, when restoring from backup you can easily see which users need to be erased, and you've not stored PII for any amount of time. As an aside, you also have to understand…

PII isn't a term used by the GDPR, and the association stripping we're used to (from healthcare, for example), isn't necessarily enough... GDPR covers psuedonymized and anonymized personal data too.

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

#198
post #5
post #3

GDPR and Kappa/event sourcing/message queue based/you name it architecture goes together nicely as you get audit logs of everything and it should be quite doable to propagate "delete this person's data" events around the place. It's a huge hassle compared to what many companies are doing with customer data now but I think it's for the best. Most things about GDPR go like "Does it feel a bit shady? It probably is. Don…

(assuming you meant to write Kafka) Being able to notify every internal service to delete a user's data is always nice, but in the case of event sourcing, the events are the data. Yet you can't delete Kafka events (not sure about other platforms). In my eyes, GDPR is the death of Kafka as an event sourcing store.

Scenario specific: with Kafkas log compaction you could use message keys and republish a stripped message to the old key, preserving the history and non-personal information, but keeping the queue and message series intact...

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

#199
post #174

Practical guide to developers - build your product in the US then expand to Indo-Pacific. Don't bother with rolling out to Europe. AI is the future of business & healthcare, which, due to inherent need for data, is incompatible with anti-data sharing laws such as GDPR. Population is rapidly aging in Europe (47.1 year old average in Germany, 42.9 in EU), so might as well set your business up for the long term by pivot…

This is the worst advice in this thread. Not only do you lose the European market for no good reason and on logic you might hear from moon landing conspiracy theorists, but you don't even solve your issue as you will still have European users no matter what. People do travel.

If you don't have physical assets in Europe which can be seized then whether or not traveling Europeans decide to use your service is irrelevant. GDPR is not going to force you to take down your service in the US or India. It's kind of like a Saudi visiting California and requesting that local gay people be stoned as per the law of their land - not going to happen.

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

#200
post #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…

Thank you for the long answer. It clarifies some issues. I wish the EU would put a 'brochure' along with the official law, containing explanations, examples etc. Our government and official bodies provides these for many of our nation's contracts or official documents (not the law, but rather housing contracts). Some follow-up comments:

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

How do I handle this situation when users get to choose their own username? If a user uses their own natural name as a username, then it's identifyable information and I'd have to remove it (then again I'd remove or anonymize it anyway).

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

It also describes that "(red. consent) should not contain unfair terms.". Would forced consent for using information for third party marketing purposes during an order check-out be 'unfair terms'? I guess "Consent should not be regarded as freely given if the data subject has no genuine or free choice" would say it doesn't. It would be nice if such situations/examples with a (legal) answer would be searchable somewhere.

Would you be allowed to get consent for an all-encompassing 'third party marketing purposes'? Sounds like that is the thing this law is meant to avoid.

> "for the establishment, exercise or defence of legal claims"

That's a very broad statement. So many loopholes possible there. Just introduce one law in a foreign, non-EU country that requires you to keep all personal information for 'assisting in criminal investigations', and you get to keep whatever you want.

Post reply on HN