5 ms·

Since it's impossible to verify, and there's a whole ton of deception by companies, I simply don't trust that any data is ever deleted just because I've been to

Since it's impossible to verify, and there's a whole ton of deception by companies, I simply don't trust that any data is ever deleted just because I've been told it is. Instead, I try to minimize the amount of data that others have.

sidewndr46 1y ago
It's not really any different when a court orders a company to delete data that weren't supposed to have. The judge pretends he understands the plaintiffs arguments and knows what the data is and where it is stored. Later the judge tells the defendant to delete it. The defendant pretends to delete it and the court pretends to verify that something doesn't exist. Afterwards, everyone goes back to business as usual.
Veserv 1y ago
Yep, until they make a legally binding claim supported by a self-imposed liquidated damages clause for failure to abide by their own claims their claims should be ignored.
outworlder 1y ago
If you can, edit the data first, don't delete. Not all systems keep all versions indefinitely.
nemothekid 1y ago
One of the headaches of system design in this area is how do you deal with backups. Lets say you do regular backups to s3, glacier, tape, stone tablets. When you tell your customer "we have deleted all your data", are you loading all your backups and scrubbing their data from there as well? Probably not as it would probably be too expensive, and depending on your size, your backups may cease to be backups as users request for data deletion daily. Ok, then you might say when you restore backups, you reference all the data to a master "deletion" list and before a backup is restored then you reference that deletion list. Still though you are dependent on the company promising to reference the deletion list. When someone "really really" needs data from a week ago and gets a one off backup, it has deleted customer data in it. Next, my idea was you encrypt all user data with a user specific key, and when the customer requests to delete that, you just delete the key. Perfect. Up until it's time to backup the encryption keys database and you are back at square one. I understand this solution is probably 95% of the way there but if anyone knows any designs which, when implemented, are fairly foolproof and don't require your customers to be "smart" (e.g. have them hold the encryption key).
- bestouff 1y ago
  It looks trivial to me. Encrypt your backups.
  - nemothekid 1y ago
    Not sure how encrypting backups solves the problem stated. If I hold the encryption keys, that means I still have access to your data.
- awesomeMilou 1y ago
  This is why the GDPR is so nice. A company needs a strategy in place to make sure your data is actually deleted and that strategy needs to be verified to work. Purging backups of records to be deleted upon reimport is fine, but you better make sure that process works, else the person who's data you accidentally didn't delete has a case against you in court.
  - trinix912 1y ago
    The thing is people generally aren't going to court when they suddenly notice a deleted photo still in their cloud docs. They're going to think it's a glitch or that they hadn't deleted it. Proving something like this in court is tricky - how would you prove to the judge you deleted something and that it randomly reappeared after some years?
quantified 1y ago
Did you ever sign up for 23andMe?
- JohnFen 1y ago
  I did. It was against my better judgement, but I did it anyway as a favor for a family member. I regret making an exception for that, and won't make that mistake again. That family member has since apologized to me for asking me to do it, too.

sidewndr46 1y ago

It's not really any different when a court orders a company to delete data that weren't supposed to have. The judge pretends he understands the plaintiffs arguments and knows what the data is and where it is stored. Later the judge tells the defendant to delete it. The defendant pretends to delete it and the court pretends to verify that something doesn't exist. Afterwards, everyone goes back to business as usual.

Veserv 1y ago

Yep, until they make a legally binding claim supported by a self-imposed liquidated damages clause for failure to abide by their own claims their claims should be ignored.

outworlder 1y ago

If you can, edit the data first, don't delete. Not all systems keep all versions indefinitely.

nemothekid 1y ago

One of the headaches of system design in this area is how do you deal with backups. Lets say you do regular backups to s3, glacier, tape, stone tablets. When you tell your customer "we have deleted all your data", are you loading all your backups and scrubbing their data from there as well? Probably not as it would probably be too expensive, and depending on your size, your backups may cease to be backups as users request for data deletion daily. Ok, then you might say when you restore backups, you reference all the data to a master "deletion" list and before a backup is restored then you reference that deletion list. Still though you are dependent on the company promising to reference the deletion list. When someone "really really" needs data from a week ago and gets a one off backup, it has deleted customer data in it. Next, my idea was you encrypt all user data with a user specific key, and when the customer requests to delete that, you just delete the key. Perfect. Up until it's time to backup the encryption keys database and you are back at square one. I understand this solution is probably 95% of the way there but if anyone knows any designs which, when implemented, are fairly foolproof and don't require your customers to be "smart" (e.g. have them hold the encryption key).

bestouff 1y ago
It looks trivial to me. Encrypt your backups.
- nemothekid 1y ago
  Not sure how encrypting backups solves the problem stated. If I hold the encryption keys, that means I still have access to your data.
awesomeMilou 1y ago
This is why the GDPR is so nice. A company needs a strategy in place to make sure your data is actually deleted and that strategy needs to be verified to work. Purging backups of records to be deleted upon reimport is fine, but you better make sure that process works, else the person who's data you accidentally didn't delete has a case against you in court.
- trinix912 1y ago
  The thing is people generally aren't going to court when they suddenly notice a deleted photo still in their cloud docs. They're going to think it's a glitch or that they hadn't deleted it. Proving something like this in court is tricky - how would you prove to the judge you deleted something and that it randomly reappeared after some years?

quantified 1y ago

Did you ever sign up for 23andMe?

JohnFen 1y ago
I did. It was against my better judgement, but I did it anyway as a favor for a family member. I regret making an exception for that, and won't make that mistake again. That family member has since apologized to me for asking me to do it, too.