5 ms·

> First of all, it should be common sense that no one has the right to force legitimate news articles to disappear because they don't like the content, but that

> First of all, it should be common sense that no one has the right to force legitimate news articles to disappear because they don't like the content, but that is what the EU has ruled should happen. No, it is about deleting personal data attached to your user account, not "news articles". This thing intends to make the "delete my account" button to actually, you know, "delete my account", instead of fake-deleting it by setting a "deleted" flag and telling me that everything is gone now while still keeping gigabytes of data associated with me in your database. > [...] meaning you need a way to ensure that "forgotten" users never get restored. If this is considered to be a hard problem, then I assume storing some list of deleted users in a separate place and immediately purge those users from the backup after restore must be some kind of rocket science. > There is a good chance your little startup that isn't cash flow positive will have to spend $1 million of its VC money on becoming GDPR compliant. I wouldn't call it "to become GDPR compliant", I would call it "to build a sound database structure". Because if you are unable to purge all data associated to one of your users' accounts from your system without destroying the integrity of the rest of your data, then you obviously have a half-baked system at your hands that lacks a core feature - to actually delete accounts. And you surely should spend some of your money to refactor this crap into a long-term viable solution while you are still small and agile enough to do that. Because it's only going to be way more expensive later on...

spydum 9y ago
You missed the point: if I take an image backup of a disk and store it, even in encrypted format, and it contains John Doe's account, and he comes along and asks for his account deleted, I would have to purge not just my database record, but the backups images from the past as well. That invalidates ALL of my backups. It's not often practical to backup INDIVIDUAL users..
- FridgeSeal 9y ago
  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`.
  - josephg 9y ago
    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.
    - Spivak 9y ago
      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.
      - FridgeSeal 9y ago
        In true HN fashion, I'm sure this is a great chance for some plucky startup to 'disrupt' the market.
    - MarkMc 9y ago
      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.
      - josephg 9y ago
        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.
- solomatov 9y ago
  This is very easy to work around. Associate each user with an encryption key and store in a separate database which backed up with some retention time. It shouldn't be huge so that's not a big problem. Encrypt all data related to the user with this key. When you make a backup, this data is stored in the same encrypted form. When you delete user, just delete his record together with this key. After this the user's data is virtually irretrievable and for all practical purposes is deleted.
  - will_hughes 9y ago
    Unless I'm misreading you, you've just created a more complicated version of things. How do you delete the immutably backed up keys? You've gone from: backup.bak to backup-encrypted.bak and backup-keys.bak
    - yorwba 9y ago
      Obviously, you can't keep insisting on immutable backups. Instead, you'll have to modify a single key in the backup file to become invalid. This does make your backups slightly less reliable, because it's one more thing that touches them, but if you do a sane implementation and exhaustively test it, the risk is manageable. I'm also not sure you really need to keep that many backups of this file. Replicate it and make sure you can roll back when your replication is borked, but if you really need to restore your database from months ago, using a newer list of encryption keys shouldn't be a problem.
- Spivak 9y ago
  As long as you have clearly defined retention policies I don't think saying, "your account has been deleted. It will take 90 days for the deletion to filter though our backups. After that point all of your data will be gone forever" would go against the spirit of the law.
  - MarkMc 9y ago
    I really hope this approach is acceptable to the EU authorities.
isoprophlex 9y ago
If you mind answering me this, I'm having a hard time figuring it out myself: Will the GDPR mean I'll finally be able to completely delete myself from Facebook?
- nthcolumn 9y ago
  ...and all those contacts that you shared without your contacts consent? (not you :) - my friends never asked me though)
nthcolumn 9y ago
>No, it is about deleting personal data attached to your user account, not "news articles". No it is exactly that! The test case was from a man specifically Mario Costeja González wishing for his past financial embarrassments to be erased. https://en.wikipedia.org/wiki/Google_Spain_v_AEPD_and_Mario_Costeja_Gonz%C3%A1lez https://en.wikipedia.org/wiki/Google_Spain_v_AEPD_and_Mario_...

spydum 9y ago

You missed the point: if I take an image backup of a disk and store it, even in encrypted format, and it contains John Doe's account, and he comes along and asks for his account deleted, I would have to purge not just my database record, but the backups images from the past as well. That invalidates ALL of my backups. It's not often practical to backup INDIVIDUAL users..

FridgeSeal 9y ago
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`.
- josephg 9y ago
  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.
  - Spivak 9y ago
    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.
    - FridgeSeal 9y ago
      In true HN fashion, I'm sure this is a great chance for some plucky startup to 'disrupt' the market.
  - MarkMc 9y ago
    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.
    - josephg 9y ago
      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.
solomatov 9y ago
This is very easy to work around. Associate each user with an encryption key and store in a separate database which backed up with some retention time. It shouldn't be huge so that's not a big problem. Encrypt all data related to the user with this key. When you make a backup, this data is stored in the same encrypted form. When you delete user, just delete his record together with this key. After this the user's data is virtually irretrievable and for all practical purposes is deleted.
- will_hughes 9y ago
  Unless I'm misreading you, you've just created a more complicated version of things. How do you delete the immutably backed up keys? You've gone from: backup.bak to backup-encrypted.bak and backup-keys.bak
  - yorwba 9y ago
    Obviously, you can't keep insisting on immutable backups. Instead, you'll have to modify a single key in the backup file to become invalid. This does make your backups slightly less reliable, because it's one more thing that touches them, but if you do a sane implementation and exhaustively test it, the risk is manageable. I'm also not sure you really need to keep that many backups of this file. Replicate it and make sure you can roll back when your replication is borked, but if you really need to restore your database from months ago, using a newer list of encryption keys shouldn't be a problem.
Spivak 9y ago
As long as you have clearly defined retention policies I don't think saying, "your account has been deleted. It will take 90 days for the deletion to filter though our backups. After that point all of your data will be gone forever" would go against the spirit of the law.
- MarkMc 9y ago
  I really hope this approach is acceptable to the EU authorities.

isoprophlex 9y ago

If you mind answering me this, I'm having a hard time figuring it out myself: Will the GDPR mean I'll finally be able to completely delete myself from Facebook?

nthcolumn 9y ago
...and all those contacts that you shared without your contacts consent? (not you :) - my friends never asked me though)

nthcolumn 9y ago

>No, it is about deleting personal data attached to your user account, not "news articles". No it is exactly that! The test case was from a man specifically Mario Costeja González wishing for his past financial embarrassments to be erased. https://en.wikipedia.org/wiki/Google_Spain_v_AEPD_and_Mario_Costeja_Gonz%C3%A1lez https://en.wikipedia.org/wiki/Google_Spain_v_AEPD_and_Mario_...