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

31–40 of 202 posts

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

#31

Post by TobbenTM »

dominotw wrote: post #11
TobbenTM wrote: post #8

Earlier quoted context omitted.

Heh, I think we're talking about different scenarios. In the case of event sourcing, we often set the retention period to 'forever', because the events in Kafka are our source of truth. Then we just build a materialising layer on top of Kafka, with the possibility to rehydrate based on _every_ event in the Kafka topics. In this case we would have to do some really weird compaction to delete singular events.

I think that scenario is adressed on this confulent blog post > Deleting a message from a compacted topic is as simple as writing a new message to the topic with the key you want to delete and a null value. When compaction runs the message will be deleted forever. Handling GDPR with Apache Kafka: How does a log forget? https://www.confluent.io/blog/handling-gdpr-log-forget/

Oh, wow, must have missed that post, thanks!

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

#32

Post by powvans »

sovietmudkipz wrote: post #25
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…

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…

I don't think you can escape it by simply throwing up a firewall to try to block EU users. It seems that you're just inextricably pulled into this as soon as you record any data about an EU citizen. Unfortunately you can't know with good certainty whether or not that has happened.

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

#33

Post by DangerousPie »

stefan_ wrote: post #23
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…

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.

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

#34

Post by DangerousPie »

kyriakos wrote: post #24
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…

Small side project means small data too, easy to manually sort out gdpr requests as need arises. No need to automate everything.

True for some parts of it, but what about things like asking for explicit consent, logging each read access to the database or implementing a "restricted" feature? None of these things are supported by most standard software.

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

#35

Post by dagmx »

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.

I'm not sure I've read anything in there that is hard to implement, other than retroactively.

I'm sure as time passes there will be frameworks and best practices developed for conforming to these regulations, but I honestly don't see anything egregious or complex to develop in there.

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

#36

Post by davejamesmiller »

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…

> It looks like the maximum fine is 4% of annual revenue... seems like the regulation has no teeth if you have no revenue.

Up to €20 million, or 4% annual global turnover – whichever is higher.

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

#37

Post by lucideer »

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…

Smaller summarised guide for very small side projects:

1. ideally, don't store personal data

2. if you absolutely need to, store the bare minimum

3. if you're doing 2, don't give any of it to 3rd parties

The article splits its bullet points into three sections. The second section is basic security best practice: you should have this covered anyway regardless of the size of your project.

If you stick to my points above, the author's remaining bullets should either be null, or much much easier to implement.

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

#38

Post by tobr »

I wonder how to deal with data that is accidentally identifiable. For example, imagine that you are running an anonymous poll or survey. In the general case that would not identify an individual person, but in some circumstances a particular collected answer will be unique and could theoretically be connected to an individual.

In such cases it's not really possible to give individuals control over their data, because except for the special case the whole point is that it's not connected to an individual...

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

#39

Post by marten-de-vries »

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, with the actual information being linked to that, making removal easier.

Post reply on HN