GDPR – A Practical Guide for Developers (2017)
techblog.bozho.net
GDPR – A Practical Guide for Developers (2017)
1–10 of 202 posts
Re: GDPR – A Practical Guide for Developers (2017)
#2> Restrict processing – in your admin panel where there’s a list of users, there should be a button “restrict processing”. The user settings page should also have that button. When clicked (after reading the appropriate information), it should mark the profile as restricted. That means it should no longer be visible to the backoffice staff, or publicly. You can implement that with a simple “restricted” flag in the users table and a few if-clasues here and there.
The simple hubris in this statement is jaw-dropping. “Just a flag and a few if clauses! Easy peasy!”
Re: GDPR – A Practical Guide for Developers (2017)
#3GDPR 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't do that." (depending on your moral compass of course)
One thing is for sure: there's a lot of opportunities for consultants as all the big companies need help to resolve the mess of legacy systems storing customer data.
Re: GDPR – A Practical Guide for Developers (2017)
#4"I think all of the above features can be implemented in a few weeks by a small team. "
how to trust the rest of the article after reading this?
Re: GDPR – A Practical Guide for Developers (2017)
#5GDPR 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.
Re: GDPR – A Practical Guide for Developers (2017)
#6> Restrict processing – in your admin panel where there’s a list of users, there should be a button “restrict processing”. The user settings page should also have that button. When clicked (after reading the appropriate information), it should mark the profile as restricted. That means it should no longer be visible to the backoffice staff, or publicly. You can implement that with a simple “restricted” flag in the us…
This article is one of the best I've seen for describing actual features that you need to build.
I agree that the specific language here is poorly chosen ("simple" and "a few if-clauses" are perilously close to the word "just") but I don't think that should detract from the enormous value the article itself provides.
Re: GDPR – A Practical Guide for Developers (2017)
#7GDPR 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.
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)
Re: GDPR – A Practical Guide for Developers (2017)
#8Earlier quoted context omitted.
(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.
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.
Re: GDPR – A Practical Guide for Developers (2017)
#9GDPR 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 need to call for every “right to be forgotten” request worldwide?
Re: GDPR – A Practical Guide for Developers (2017)
#10Earlier 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.
It really depends on what you're doing. If you're doing something where the people you're storing data about don't need to interact with each other, you can actually store each user's events in a separate event log.
This can be fed to more transient event queues which do not have an indefinite retention period where interaction is required.
Not sure about how well-geared Kafka is to this scenario though.