Hacker News new | past | comments | ask | show | jobs | submit login

This is not an unsolvable problem.

Does your data not have a lifetime anyways? Do you really need to store everything forever? If you have system that just tracks changes and one that occasionally records full state, after you delete someone from prod you could simply overwrite old full-state backups with your new, post-deletion backup and update your change-only backups to replace data about that user with `deleted`.




There is also a pretty easy cryptographic solution for your offline backups:

In your backup, encrypt each user's data using a per-user key (AES or something). The keys will be tiny, so you can store the keys in a hot database. When a user deletes their account, simply purge the user's key.

Tada - like magic all of that user's data on your tape backups has turned into unreadable noise.


I think you're assuming that most companies roll their own backup systems. You're underestimating the number of companies for which their backup system is something like Windows Server Backup or Veeam which isn't doesn't have that kind of granularity.


In true HN fashion, I'm sure this is a great chance for some plucky startup to 'disrupt' the market.


This makes me very nervous about data loss. If I accidentally wipe the hot database then I've effectively deleted all my backups. It also makes corporate ramsomware attacks much easier.


So keep a backup of your hot database in S3 or something, and make a workflow by which you can periodically update it. Or make a write-only backup of your encryption keys every day and only keep the backups for a week (or a month, or whatever the legal requirement is).

Complying with this requirement will require us as an industry to make some changes to how we store user data. But the amount of work each company needs to do is proportional to the complexity of our existing backup system. If you're a tiny startup and don't keep offline backups at all, you can just delete the user from your database. The more complex & rigorous your backup system is, the more complex your user deletion system will need to be.

Its a hassle, but no moreso than any other requirements we deal with on a daily basis.


I don't mean this to come across as disparaging, but for people saying things along the lines of "Its a hassle, but no moreso than any other requirements we deal with on a daily basis.", I can't believe you have any experience with data recovery at a large company.

A fundamental axiom of data recovery is that you don't really ever "delete" anything, because accidentally losing data is considered such a horrible problem. So virtually all backup systems consider backups fundamentally immutable, because everyone knows how just one small bug in something designed to modify a backup could fuck the whole thing.

I don't really disagree with the spirit of the law, but I think the backups problem to honestly be pretty much a technical impossibility for large companies, it will basically just get ignored (the backups part at least).


> make a write-only backup of your encryption keys every day and only keep the backups for a week (or a month, or whatever the legal requirement is).

A month would be better than a week, but it still allows a situation where the wrong user account is accidentally deleted and the mistake is not noticed for a more than month.

I think the best approach is for the EU regulation to give the company 90 days to delete the user's data. The company can then just have a cron job to delete older backups. Simple.


There's been a wave of targeted ransomware attacks recently that spend time surveilling and infiltrating their targets before holding their data for ransom. If companies take your proposed approach, some of them will find their backups have been compromised and be forced to pay up by ransomware attackers. It's simply inevitable.


Now you have to apply the same solution recursively to the keys database.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: