Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GDPR – A Practical Guide for Developers (2017)

techblog.bozho.net

Post reply on HN
Print view View original

151–160 of 202 posts

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

#151

Post by smarx007 »

YetAnotherNick wrote: post #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 anyo…

Well, if you model can tell guess my name from 100 browser history entries, then yes, I want the law to require you to retrain your model once I invoke that right.

An interesting matter is a use of blockchain-like scheme. I guess the law would mean you can't put GDPR protected information in a public distributed blockchain, but instead use identifiers to decouple GDPR info from that ID. And the invocation of that right to be forgotten would require us to permanently delete an entry linking that identifier to a user.

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

#152

Post by Silhouette »

geocar wrote: post #66
DangerousPie wrote: post #33

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.

You're allowed to log people's IP addresses for diagnostic reasons, to prevent fraud and abuse. 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. If you're not using IP addresses for those reasons, you shouldn't collect it. It is good ad…

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" wording. I wonder how well it will work in this case. How can anyone possibly make a reasonable, intelligent, a priori assessment of how long that data will be useful for that kind of purpose?

It is good advice to mask off the bottom bits of the IP address since it will still likely be unique enough for you, without being useful to someone who has an unrelated list of IP addresses.

That isn't necessarily true if, for example, you're using IP addresses to detect a pattern of abusive access within a general pool of acceptable access. And if a full IP address isn't enough to potentially identify a specific threat, it surely also isn't enough to constitute personal data. Either way, your advice seems excessively broad here.

You should be able to delete usernames, passwords and email addresses on request. You should be able to remember that request if you restore from backups.

Doing this effectively without immediately becoming self-contradictory probably requires something like storing a hash of every user name or email address that has had deletion requested, and querying a database of such hashes during the restoration process in order to exclude affected data. While this may well be in the spirit of the GDPR, there is no denying that it is extremely onerous, particularly for anyone working with personal data who rarely if ever receives such a request yet would have to redesign a large part of their IT infrastructure around the ability to do it.

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

#153

Post by Silhouette »

scrollaway wrote: post #101
sovietmudkipz wrote: post #25

Earlier quoted context omitted.

One man shop here... Cloudfront forwards country information to your origin servers in AWS. My plan was to not do business or display content in European countries until an easy solution to GDPR enables me to quickly meet it's criteria. Certainly libraries will crop up helping to ease the burden of the regulation for smaller operations. Though... I'm not quite sure what happens when a European citizen uses VPN to spo…

The GDPR applies to european citizens living outside Europe. You have a fire in your kitchen, and instead of addressing it, you're closing the door. From the inside. [Edit: And to be clear, if I ever heard about a site pulling this sort of shit, I would be extremely compelled to issue GDPR requests towards it. This mindset amuses exactly nobody except you.] Edit 2: I'm being a little snarky here, so here's a bit of a…

The GDPR applies to european citizens living outside Europe.

The EU would like to think so. Whether it actually can enforce its law extra-territorially is an entirely different question, the answer to which most likely depends on the nature of any formal agreements it has with other relevant jurisdictions and/or the local law in those jurisdictions.

And to be clear, if I ever heard about a site pulling this sort of shit, I would be extremely compelled to issue GDPR requests towards it.

And that is exactly why the GDPR is too absolute and one-sided. It imposes significant burdens on those working with personal data and provides data subjects with rights that can be abused in a form of barratry.

Instead of trying to be a smartass with the law, which never works, do what every other one-man shop your size will do and ignore it until it becomes an issue.

Isn't that also being a smartass with the law?

Moreover, if compliance with the law is so onerous that small organisations can't reasonably be expected to do it anyway, that's a pretty clear case that the law is too strong.

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

#154

Post by Fej »

pkaye wrote: post #131
DangerousPie wrote: post #16

I really don't understand how this is going to work in practice for small side projects with a single part-time developer. How are they supposed to afford implementing all these changes, none of which seem trivial or even practical for your standard little PHP site? So if I run a forum as a side project, what are my options? 1) Spend all free time over the next few months adding these features and neglect any other w…

4) If you are not living in the EU you are not obligated to implement any of the changes. Being a small time developer, what is the worst that can happen?

Banned from the majority of the world's developed countries.

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

#155

Post by bkanber »

pkaye wrote: post #131
DangerousPie wrote: post #16

I really don't understand how this is going to work in practice for small side projects with a single part-time developer. How are they supposed to afford implementing all these changes, none of which seem trivial or even practical for your standard little PHP site? So if I run a forum as a side project, what are my options? 1) Spend all free time over the next few months adding these features and neglect any other w…

4) If you are not living in the EU you are not obligated to implement any of the changes. Being a small time developer, what is the worst that can happen?

If you service any users in the EU or process any personal information of EU citizens, you must comply with GDPR.

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

#156

Post by JakeTheAndroid »

Silhouette wrote: post #152
geocar wrote: post #66

Earlier quoted context omitted.

You're allowed to log people's IP addresses for diagnostic reasons, to prevent fraud and abuse. 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. If you're not using IP addresses for those reasons, you shouldn't collect it. It is good ad…

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 that some data is only PII when you have other data joined with it. Extended PII can easily be ingested into a system and stripped of its association with the user. That value independent of other identity data means its no longer PII, extended or otherwise. But, again I'm still grasping this myself. Please correct me if I am wrong.

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

#157

Post by Silhouette »

geocar wrote: post #64
crazygringo wrote: post #48

Earlier quoted context omitted.

I'd hardly say that. "Forget me" can take a lot of design work (can introduce a ton of edge cases). "Export data" requires building an entire information processing pipeline. Larger corporations have the resources to dedicate to this. But for a small startup deciding between spending 4 dev-months on "forget me" and "export data" versus on enabling the top 3 new primary use cases users are asking for, I understand how…

I would. I'm doing some GDPR consulting at the moment and most of my conversations are "I don't think it's as complicated as you do". Americans tend to read law very pathologically unless they are familiar with how European legislation works, and every programmer out there thinks they are an armchair lawyer since there are "obvious" skillset similarities between decoding software and decoding law. "Forget me" is very…

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 interpretation of the GDPR reliable in cases where a literal reading either clearly contradicts you or contains significant ambiguity that you imply doesn't matter?

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

#158

Post by pbhjpbhj »

espadrine wrote: post #95
pbhjpbhj wrote: post #53

Earlier quoted context omitted.

What personal information does bitcoin contain?

All payment orders and credit transfers to and from all accounts. For any Bitcoin address you find on the Web.

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

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

#159

Post by Silhouette »

JakeTheAndroid wrote: post #156
Silhouette wrote: post #152

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…

I think your approach with UUIDs is practically equivalent to my suggestion involving hashing: you replace something that is the actual personal data with an irreversible proxy.

My concern remains the same either way. It's not that such measures can't technically be implemented, it's that the effort required to do so in practice is disproportionate, particularly for smaller organisations using limited personal data for legitimate purposes where there is little risk to privacy from otherwise properly handled data not being fully deleted on demand.

For example, instead of a small transport business buying a standard backup service and using backup and restore tools that just save all their important data to a secure, reliable location in case of disaster, it appears that they might now have to implement data crunching logic customised to their specific circumstances, despite possibly having no knowledge about how databases or programming work at all.

I fail to see how such a requirement would be constructive in terms of safeguarding anyone's privacy in a meaningful way, but I also fail to see how it isn't required according to the letter of the GDPR.

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

#160

Post by geocar »

Silhouette wrote: post #152
geocar wrote: post #66

Earlier quoted context omitted.

You're allowed to log people's IP addresses for diagnostic reasons, to prevent fraud and abuse. 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. If you're not using IP addresses for those reasons, you shouldn't collect it. It is good ad…

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…

> How can anyone possibly make a reasonable, intelligent, a priori assessment of how long that data will be useful for that kind of purpose?

By first coming to grips with the fact that this isn't your data.

Keeping data is always a risk. You risk being hacked and jeopardising losing control of people's personal data. The longer you keep it, the longer you are putting that data at risk.

How long can you be expected to go without being hacked? A year? Five years? Ten years? At which point do you think you can be compliant?

> > If you're not using IP addresses for those reasons [fraud detection], you shouldn't collect it. It is good advice to mask off the bottom bits of the IP address since it will still likely be unique enough for you, without being useful to someone who has an unrelated list of IP addresses.

> That isn't necessarily true if, for example, you're using IP addresses to detect a pattern of abusive access within a general pool of acceptable access

Why do you say something is not necessarily true when I have already given this exact reason?

> Doing this effectively without immediately becoming self-contradictory

No, it requires keeping the two or three requests for data or erasure posted to you, or emailed to you.

This isn't complicated. I have email from over twenty years ago.

Post reply on HN