Live data from Hacker News

GDPR – A Practical Guide for Developers (2017)

techblog.bozho.net

11–20 of 202 posts

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

#11
post #8
post #7

Earlier quoted context omitted.

Kafka doesn't persist things forever. AFAIK it's totally OK if you have say 14d retention and then the data is deleted from Kafka too (it was deleted from everywhere else already because there was an event/request to do so)

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/

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

#12
I think the right to be forgotten is a serious flaw in what otherwise is a major step forward in Data handling law.

Data today has been compared by Schneier to pollution in the industrial revolution. The GDPR is probably the first anti-pollution law with real bite and with a real grasp of just how far this all goes (the extra-territoriality etc)

This does not make this perfect solution. I honestly don't think that "being forgotten" actually makes sense as a right - it seems to have sprung from some unusual case law in ECJ and could much more easily be dealt with by a "do not further process".

But we genuinely can always find ways to implement new laws - the most obvious is to encrypt user data, and then lose the key, but beyond that i think the best outcome of all this is to stop moving data around so much. moving data from system to system is a smell in my view - and one that a eu law is going to help architects the world over realise they are doing wrong

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

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

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

#14
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?).

"Consent checkboxes" - To what extent can users be forced to give consent or be denied from a service? Like the Cookie law, almost every website requires you to accept the fact that cookies are used, otherwise your experience is degraded (eg. you cannot watch news videos). Or say I want to order something from a webshop, and in order to place an order, I must consent with sharing my personal information with third parties for marketing purposes, else I cannot place the order. Do I have to call them out later? How is this law going to solve things if it prevents me from using things?

"Export data" / "See all my data" - What is 'all my data' here? Is in information I entered when I signed up for a service? Is it information derived from this data (eg. my google search suggestions/ads profile)?

"Don’t assume 3rd parties are compliant" - if I, the data collector, gets fined because a 3rd party, data processor, is not compliant, can I retrieve part of the losses from the data processor? I mean, OpenID allows sharing a lot of personal information from data collectors like Facebook and Google with almost any random site. What can I expect here?

"Consent checkboxes – “I accept the terms and conditions” would no longer be sufficient to claim that the user has given their consent for processing their data." - So if I, as a user, don't give any explicit consent to any personal information sharing, and in May I receive a marketing email from a party I don't have an account with (because they sold my personal information prior to this), I could say they broke the GDPR law?

"Keeping data for no longer than necessary" - 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?

"Forget me" - Say an employee leaves a company, and they request their personal information to be deleted. What information do I have to delete? Their Active Directory account? Their salary statements (I need those for tax agencies)? Their name in the git history? Their name from all minutes of all meetings they attended? Their name from documentation they wrote?

Some things might be doable to implement in just 8 weeks, if I had clear guidelines on how to do this, but as of now, I have so many situations where it is unclear what I should do, and no clear way to get answers, that I don't know how I can comply with this law within 8 weeks, as a small software company.

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

#15
Lets say I have a bookmark file which contain list of urls. It is associated with one user account. Its likely associated with one person but I cannot identify that person. There is no other information associated with the user account. Is the bookmark file personal data ?

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

#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 work on the project.

2) Ignore the GDPR and hope nobody complains.

3) Shut down the side project.

Of course if you're Facebook or Twitter you just assign a few developers to this and you'll be fine. But I don't understand how this will not end up killing small-time web companies, or at least make them a lot less feasible to create.

I suspect many people will go for (2) and hope this fizzles out the same way the cookie law did.

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

#17

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?

How is identifiable data important for institutional knowledge transfer?

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

#18
One of the clearest things I’ve read on The subject.

It is a lot of common sense. Questions over the right to be forgotten vs tax / legal issues come under the “legitimate interest” clause I think. You should delete their data except where you are required to keep it. And that may mean deleting preferences and browsing history, but not their name and address if you are required to keep it.

I intend to implement a “forget me” feature by anonymising any PID and potentially redacting things like messages between users on our system. That way we keep info for stats purposes but don’t have any way to id a person from the data we hold.

The restoring backups / storing preferences about deletion request etc in a separate DB solution is also a good idea. It shows willing to comply with the regulation as well even if it may not strictly be compliant (e.g. until the backup has synced up with the preferences DB, you still have the PID) I think so long as you show a lot of willing and progress towards being compliant and take all practical and reasonable steps to do so, then it shouldn’t be too much of a burden.

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

#20

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…

Until Stripe, that seemed to be true of PCI compliance as well. Just keep saying your project is too small form tone to spend any time trying to hack it.
Post reply on HN