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

41–50 of 202 posts

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

#41

Post by muchbetterguy »

powvans wrote: post #27
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…

It looks like the maximum fine is 4% of annual revenue... seems like the regulation has no teeth if you have no revenue. IANAL and could be totally wrong. To your point about small companies, I agree, it feels onerous. What irks me about the right to be forgotten is that it directly counters my right to remember things. Should a shop keeper be allowed to record their observations about who enters their store each day…

The fine is up to 20M euro or 4% whichever is greater AFAIK.. and will match the seriousness of the offence. ie a small side project who refuses to honour a forget me request is highly unlikely to be fined 20m euro. However, one that deliberately mines the web for huge amounts of PID without consent and profits from it now has a new regulation to watch out for.

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

#42

Post by lucideer »

DangerousPie wrote: post #33
stefan_ wrote: post #23

Earlier quoted context omitted.

Don't store a bunch of personally identifiable data and you don't have to do any of this. We have seen what this laissez faire attitude to "capture everything, delete never" has done. Trust has been supremely squandered so at this point I don't think anyone is particularly inclined to believe when someones cries wolf.

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.

Passwords are not personal data, and even if they were, you aren't storing them anyway (right?).

There's a tricky question around usernames: they're technically not personal data since they aren't necessarily the real name of the user, but the user can choose to use their real name as their username, which is not easy to distinguish in any automated way.

You don't need to store IPs

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

#43

Post by Neuron4ger »

marten-de-vries wrote: post #39

It's interesting to see how the GDPR seems to clash with some popular data models. For example, git. Rewriting history of a shared branch is disastrous, but it's currently the only way to redact, say, an e-mail address someone committed with a couple of years ago. I'm curious how the various code hosting sides plan to handle that. Perhaps we'll see an extension of the data model that links commits to committer UUIDs,…

Apparently Git is ok by GDPR as data subjects do not have the right to erasure if the information is meant for archiving purposes in the public interest [1].

[1] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:320... (Article 17)

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

#44

Post by davnicwil »

lucideer wrote: post #28
boggio wrote: post #26

God damn it EU, all these regulations make it impossible for small companies, indie developers to cope with all the bureaucracy. The VAT for digital products, now the GDPR. 10 more years of regulation and you will spend 90% of the time working on implementing legal requirements and 10% on the actual product.

GDPR—while vastly different to what has become the defacto standard practice in most companies—is largely simple, basic, common decency and common sense. My very tiny startup won't have any problems complying because we've actually given a smidgen of consideration to our users' privacy up until now. In fact, I foresee it being a much greater tax on large corporations: the work in GDPR is not compliance—that's relativ…

From what I have seen and understood about the regulations and the spirit of them this is basically right.

If your system was intentionally designed with both privacy and the ability for users to own their data (i.e. edit & hard delete whatever, whenever for any reason) in mind, then GDPR should be essentially complied with already 'out of the box'.

If this was not the case, either for cynical reasons, simple disregard for the importance of these things, or a decision to not prioritise these things in favour of shipping more features faster, and you just essentially slapped a checkbox with some legal copy over your signup process and thought you were done with all that pesky user data privacy stuff, well, you're in for a pretty bad time now.

Maybe my reading of it the regulations is naive and it won't be so easy in the first case and will be easy to subvert anyway in the second case. But if not, to be perfectly honest it seems just like what good regulation should do - incentivise good behaviour - allowing businesses that behave well by nature to thrive without too much extra hassle introduced, and suppress both the bad behaviour itself and the general productivity of the business behind it where that's not the case.

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

#45

Post by pbhjpbhj »

powvans wrote: post #27
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…

It looks like the maximum fine is 4% of annual revenue... seems like the regulation has no teeth if you have no revenue. IANAL and could be totally wrong. To your point about small companies, I agree, it feels onerous. What irks me about the right to be forgotten is that it directly counters my right to remember things. Should a shop keeper be allowed to record their observations about who enters their store each day…

Re the last question, yes, absolutely. Why would data format matter?

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

#46

Post by tajen »

powvans wrote: post #27
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…

It looks like the maximum fine is 4% of annual revenue... seems like the regulation has no teeth if you have no revenue. IANAL and could be totally wrong. To your point about small companies, I agree, it feels onerous. What irks me about the right to be forgotten is that it directly counters my right to remember things. Should a shop keeper be allowed to record their observations about who enters their store each day…

Yes, for privacy reasons, it’s not appropriate to keep observations on your fellow citizen...

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

#47

Post by kalefranz »

espadrine wrote: post #9
elnygren wrote: 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…

I didn't realize it until reading this post, but certain very popular technologies break GDPR in a deep way. Bitcoin, for instance, contains a wealth of personal information, which by design are both public, persisted forever, and immutable. Are blockchain products all going to need a full rewrite or a complicated hard fork? What about the Wayback Machine? Will they need to have an endpoint that every company will ne…

I think the dependency order here is reversed. GDPR breaks certain very popular technologies in a deep way.

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

#48

Post by crazygringo »

lucideer wrote: post #28
boggio wrote: post #26

God damn it EU, all these regulations make it impossible for small companies, indie developers to cope with all the bureaucracy. The VAT for digital products, now the GDPR. 10 more years of regulation and you will spend 90% of the time working on implementing legal requirements and 10% on the actual product.

GDPR—while vastly different to what has become the defacto standard practice in most companies—is largely simple, basic, common decency and common sense. My very tiny startup won't have any problems complying because we've actually given a smidgen of consideration to our users' privacy up until now. In fact, I foresee it being a much greater tax on large corporations: the work in GDPR is not compliance—that's relativ…

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 this could feel really difficult.

I really wonder if it wouldn't be better to make some of the requirements only for companies above a certain revenue threshold or the types of data collected. (E.g. export data is critical for health or finance-related sites, probably less so for a meme generator startup.)

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

#49

Post by pbhjpbhj »

andygcook wrote: post #13

Does this apply to internal software like Slack and Github provided by an employer to an employee? e.g. An ex-employee requests that all their identifiable data be deleted from all communication and systems of their former employer. That seems like a problem for institutional knowledge transfer. Will the employer have to adhere to that request?

It's "personal identifiable data" that covered. What you did at work doesn't count, your companies record of which days you worked is not personal within the company. If they shared it without anonymising it then it becomes personal.

"andygcook wrote this library" in internal company data isn't personal data.

Post reply on HN