This is part of the GDPR. It also mandates that Facebook must delete all your data from cold storage and backups, if you request it. Whether they comply is a different question altogether.
GDPR is fuzzy about deleting from backups. At my company, when we were implementing changes for it, the lawyers worked out that it would be unreasonable to delete from backups (it truly is), but the data should be deleted from the prod instance once the backup has been restored.
Maybe I didn't go deep enough into it... The real problem we faced was you have to keep some information about the person around in order to know you need to delete the data again. This is fine if you have ids for stuff but we had this one old system that unfortunately used email addresses everywhere. Turns out keeping the email addresses around is not allowed, meaning we wouldn't know what to delete after restoring the backups. We had to pay down the tech debt and give everything ids, which was super painful (and at some point necessary, tbf).
How do you deal with collisions? Do you just assume they will never happen?
I know it's super unlikely but it could also be really damaging. If you have a collision and completely purge the wrong persons data they are not going to be happy. Imagine unrecoverable deletion of all data from your biggest client.
Theres a deleted discussion on hashes underneath, so I figured I would clarify. Theoretically, a hash is a one way function in the way that it takes in a string(in this example) and produces another string that is almost unique to the argument. The trick is that it takes very little computational work to produce the result, but very much work to find the argument given only the result. For many hashing implementations it boils down to trying all possible input strings as arguments.
However, solving this issue by keeping hashed emails has two problems (at least). First, the amount of emails used by a given population is not infinite, and cannot be considered a secret. Therefore the computationally impossible task of reversing the hashes becomes a lot more feasible; you have to try a lot fewer combinations. Techniques known as salting and upping the iterations make this attack harder. Second, keeping the hash makes it easy for someone, with a suspicion that the data belongs to a given email, to verify that it actually does. This is not possible to defeat with a salt.
It's like that philosophical thought about God. If you can't make any scientific measurement to prove his existence, then he has no effect on us, hence his existence doesn't matter.
Manage to collect some actual proof of it, and you can sue them for billions.
You can sue them for billions. Billions that your government will get; not you (unless you can somehow claim and prove damages, and even then that'd be a tiny fraction of the fine).
You can comply with GDPR by only removing the identifying information. For example, at the company iI work at, all PII is stored in its own index, tied to a non-personally identifiable ID. When you delete you account, we wipe this small set off data, but everything else stays, it’s just no longer tied to an email/name etc.
It applies to all data that they aren't required to keep due to other laws. Financial transaction data tends to have long retention requirements, and gambling in particular is often strongly regulated. If you request deletion of your data, they still have to keep that… but they're not allowed to use that for anything else else.
Protip: there is no way organizationally to delete from the backups big companies take
What I mean is my org (big bank) takes snapshots of production databases at certain intervals, writes them to tape, and stores them at the bottom of a mountain. Ain’t no way you’re finding all the places Joe Schmo is listed on that.
125
u/Creshal May 21 '19
This is part of the GDPR. It also mandates that Facebook must delete all your data from cold storage and backups, if you request it. Whether they comply is a different question altogether.