Martin Kleppmann: "What’s current best practice for GDPR compliance (in particular, right to deletion) in systems with append-only logs/event sourcing/blockchains, which are supposed to keep history forever?"

Proposed solution: complementing Datomic with an erasure-aware key/value store.
In cases where Excision is not a viable solution, the solution I've come up with is store to privacy-sensitive values in a complementary, mutable KV store, and referencing the corresponding keys from Datomic.

This seems to be turning into a common pattern for GDPR compliant storage.

You could think, as a developer, that the lawyers worry about this kind of fine-grained issue. They don’t. This is one of those situations where they say, well, here’s the risk, you have to make a decision, document it, and be ready to back that up in front of a judge should the soup hit the fan.

In this particular case it’s straightforward enough. Are you in control of the presence of data in your database? Yes. It’s up to you to delete it when requested. Are you in control of the data on your harddrive? Yes. It’s up to you to delete it when requested. Are you in control of the operating system implementation or database implementation of deletion? No. Could you get the data back if you wanted to? Yes – but that’s not part of your usual run of business, so why would you explicitly do that? What if some bad dude steals your harddrive and then rummages through it? Ok we are getting a little far-fetched here for most businesses that are not keeping special category data, but if this does happen, then you have failed in your security controls.

I guess my overall point here is that GDPR Compliance is a continuum, not a tickbox. You want to be doing the best you can with it and document why you can go so far and not further. The companies that will be getting the big legislative fines are the guys that are willy-nilly exporting special category data out of the EEA en masse without the knowledge of the people associated with that data. The rest of us just need to muddle along as best we can.

Without adtech, the EU’s GDPR (General Data Protection Regulation) would never have happened. But the GDPR did happen, and as a result websites all over the world are suddenly posting notices about their changed privacy policies, use of cookies, and opt-in choices for “relevant” or “interest-based” (translation: tracking-based) advertising. Email lists are doing the same kinds of things.

“Sunrise day” for the GDPR is 25 May. That’s when the EU can start smacking fines on violators.

Simply put, your site or service is a violator if it extracts or processes personal data without personal permission. Real permission, that is. You know, where you specifically say “Hell yeah, I wanna be tracked everywhere.”

Of course what I just said greatly simplifies what the GDPR actually utters, in bureaucratic legalese. The GDPR is also full of loopholes only snakes can thread; but the spirit of the law is clear, and the snakes will be easy to shame, even if they don’t get fined. (And legitimate interest—an actual loophole in the GDPR, may prove hard to claim.)

Toward the aftermath, the main question is What will be left of advertising—and what it supports—after the adtech bubble pops?

So was it European law experts Hamilton that wrongly advised ICANN that it could request for a "moratorium" over the new law until it came up with a new solution?

It seems unlikely given their expertise and the fact it was them that first warned ICANN that it had wrongly persuaded itself that it was not affected by the new law. What seems more probable is that ICANN's staff and management board simply persuaded themselves that they could stall for time for no reason other than the fact that it would be convenient for them.

Sometimes you get ads on Facebook and you are just not interested in what they’re selling. This is a way to find out who has uploaded your email address into facebook to target ads at you, and then- if you’re in the EU- how to use the new General Data Protection Regulation to get those advertisers to delete you from their system.

Overall, it seems like Facebook is complying with the letter of GDPR law, but with questionable spirit. Sure, privacy is boring to a lot of people. Too little info and they feel confused and scared. Too many choices and screens and they feel overwhelmed and annoyed. Facebook struck the right balance in some places here. But the subtly pushy designs seem intended to steer people away from changing their defaults in ways that could hamper Facebook’s mission and business.

How do you delete (or redact) data from Kafka? The simplest way to remove messages from Kafka is to simply let them expire. By default Kafka will keep data for two weeks and you can tune this as required. There is also an Admin API that lets you delete messages explicitly if they are older than some specified time or offset. But what if we are keeping data in the log for a longer period of time, say for Event Sourcing use cases or as a source of truth? For this you can make use of Compacted Topics, which allow messages to be explicitly deleted or replaced by key.

We summarize the potential impact that the European Union's new General Data Protection Regulation will have on the routine use of machine learning algorithms. Slated to take effect as law across the EU in 2018, it will restrict automated individual decision-making (that is, algorithms that make decisions based on user-level predictors) which "significantly affect" users. The law will also effectively create a "right to explanation," whereby a user can ask for an explanation of an algorithmic decision that was made about them. We argue that while this law will pose large challenges for industry, it highlights opportunities for computer scientists to take the lead in designing algorithms and evaluation frameworks which avoid discrimination and enable explanation.