4 ms·
My favorite approach is encrypting all of a user’s data (everywhere) and just deleting the key from a central store instead of actually erasing.
by ijcd 6y ago
My favorite approach is encrypting all of a user’s data (everywhere) and just deleting the key from a central store instead of actually erasing.
- hangonhn 6y agoI was about to suggest the exact same. It is literally what we do at my company. Of course you now have to them deal with searching and indexing. To mitigate this issue, we use UUIDs to reference users throughout our systems. Any fields that would link that UUID back to a real person or contain personal info is then kept encrypted. That way, we can still gather all the information from our various components but if we needed to, we can essentially make the user data unreabable.
- rrobukef 6y agoDoesn't this still leak information? "A person known by these 5 people was in contact with the suicide hotline."
- noident 6y agoCan you be certain that nobody has retained a copy of this key?
- Polylactic_acid 6y agoDoesn't this leave you with a bunch of junk data taking up space?
- Xorlev 6y agoNot all customers are cool with this approach.
- luckylion 6y agoFor regulatory reasons or because of "you didn't really delete it"? This is similar to deleting a file but not overwriting the space it occupied on the disk, isn't it? The data is still "there", but it's not accessible by normal means.
- FridgeSeal 6y agoWhat's the problem with actually just deleting this data when you're done with it though?
- vmateixeira 6y agoBecause FKs on a relational model.. as an example, deleting a user/account might end up being a task on going through every reference to it, and the references to its references, etc. This is actually the reason some companies do not delete users/accounts [0]. [0] https://news.ycombinator.com/item?id=23005060 https://news.ycombinator.com/item?id=23005060
- chrisacky 6y agoOne of our popular accounts has about 70M worth of rows. I can't imagine how we would go about deleting their data. We rotate out old data each month when it doesn't become needed, but maybe 40M records (4M new each month gets added).
- evbpcapfxy 6y agoIs that okay from a GDPR perspective? What if there's an exploit discovered in the implementation of the encryption? Or what if quantum computers can crack it easily in the future?
- rommel917 6y agoIt is ok for GDPR, it is axon uses it in their commercial GDPR modul (better then our but same principale). Broken encryption, 20 years better machines in future and quantum are solved with same trick. We have event sourcing. Implement best current encryption, delete everything except event store, decrypt events with old encryption publish events and everything in now encrypted with best current encryption events in new store. Delete deprecated old event store. Skip aggregates with deleted old key.