Crypto-shredding, as it is known, it is already well established as a valid process and covers the requirements.
The point is to make the data unusable. Obviously when you delete a file from your recycle bin, the data is all still there, but it's acceptable under EU data protection reqs.
>but it's acceptable under EU data protection reqs
No it isn't. This is what got Facebook in hot waters awhile back. Marking a picture as deleted isn't the same as deleting it. Some other mechanism could easily point to where the data is actually located and not just its descriptor.
Yes, it is. The legal definition of deletion under EU data protection laws is to make the data unusable and inaccessible. Marking for deletion (as deleting from a recycling bin does) is sufficient under those rules.
Deleting the image ID and leaving the content on a CDN is not acceptable - but that's not what I said.
It’s pretty straightforward: you don’t encrypt the data necessary for a join.
Data for a join, ie foreign keys, are used to inform your structure. They aren’t really data a person owns... they just describe how that data (theirs) fits into your database (yours).
You'd still need to decrypt the whole table to do e.g. aggregation.
For example, a customer's address is private information; statistics about how many customers come from each town/region is not, but calculating a simple "select town, count(*) from x group by town" requires decrypting every address.
> you can store whatever you want unencrypted on the read model.
So to recap correct me if I’m wrong:
You store everything encrypted.
You have an api on it which hides the encryption and shows everything unencrypted.
On the unencrypted api you do joins/aggregations.
RightToBeForgotten then means delete its decryption key and remove it from the in-memory api.
The point is to make the data unusable. Obviously when you delete a file from your recycle bin, the data is all still there, but it's acceptable under EU data protection reqs.