[anyfoo]

What they should do (I have no idea what they do) is to encrypt every record belonging to a user with an individual key. Live records, backups, everything. If a user wishes to be deleted, that live key is simply obliterated, making any data the user owns unrecoverable.

Since the key is not used for end to end encryption, and backends still have access to the data (as long as the key lives), it has different requirements on how it needs to be protected. The biggest challenge is backing up the key itself, as losing it means losing access to all the user’s data by design. But backing up and obliterating a single key is much, much easier than doing so for a whole set of loosely associated data across many databases.

[ygjb]

Practically speaking, it also makes using and querying that data and doing any kind of analytics much, much more expensive. It is done that way in some cases, but in the absence of a technical requirement to do so, there are cheaper approaches.

[anyfoo]

Those are solvable problems. I could also argue how address space separation and more generally MMU protections make things so, so much more complex (they do!), yet we don’t question that one very much.

There is no end to end encryption involved here, so you don’t need to resort to such voodoo as homomorphic encryption.

[yreg]

Yes, I also expect that this is the way, but I think it makes the problem only partially smaller, since you still need to sync and back up the keys.

Also, is an encrypted piece of data with a lost key truly deleted? What if the encryption gets cracked?

I would say it is more deleted than toggling a `deleted` flag in the db and less deleted than burning the tapes in fire.

[anyfoo]

> the problem only partially smaller, since you still need to sync and back up the keys.

I mentioned that: It makes the problem much smaller, as you only have one single, small piece of data to backup and and erase, instead of an ever-changing many-faceted blob of distributed data.

> Also, is an encrypted piece of data with a lost key truly deleted? What if the encryption gets cracked?

Oh boy. If simple symmetric encryption gets “cracked”, then you have much larger problems.

> I would say it is more deleted than toggling a `deleted` flag in the db and less deleted than burning the tapes in fire.

For all practical purposes symmetrically encrypted data that lost its keys is considered “random” data. If you “erase” data on a device before you sell it, most often it will just throw away the key to the disk contents nowadays.

[sfjailbird]

They already do this (the encryption-at-rest part). Deleting the data is still a hard requirement. Also, the keys are never seen outside of the centralized encryption service. Deletion is still a must.

[anyfoo]

Encrypt with an individual key for each user. Throwing away the key is indistinguishable from deletion.