Information has been permanently deleted, for small values of permanently
devblogs.microsoft.com
devblogs.microsoft.com
Instead, I try to minimize the amount of data that others have.
Not all systems keep all versions indefinitely.
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).
That family member has since apologized to me for asking me to do it, too.
This is not only possible, I designed and open sourced a lot of tooling to do it and a few companies are doing this today. Shameless plug: My company (https://distrust.co) provides consulting for orgs that want to be ahead of the pack to retrofit their existing infrastructure to support these types of assurances.
Now we just need to require verifiable deletion techniques like this in order to get a standardized privacy certification browsers can verify and alert users to along the lines of the TLS green lock.
I give it 20 years.
software attestable enclaves are one thing. hardware attestable ones are quite another.
One of our projects at Distrust is to handle all of the above in a universal library/spec we are working on called Bootproof, which will ship with EnclaveOS for broad hardware/software attestation support out of the box via a tiny rust daemon and client.
Also there is the issue that the debian and ubuntu packages you rely on can change from one day to the next etc.
I went down that road for over a year, building a whole package.json style hash locking system on top of apt only to abandon it realizing no existing Linux distribution was up to the task from a trust and security perspective. Even a lot of the packages Debian claims are reproducible, like rust, are actually just built from unverifiable binary blobs from the internet. It was a sad realization that the reproducibility of all existing distros has some huge asterisks.
So my team and I at Distrust started StageX to be the first container native Linux distribution and the first that trusts no single human or system, now at the heart of enclaves at Mysten Labs, Turnkey, etc. Totally FOSS though donations or support contracts are always welcome.
Took a look at your image generation setup and it could certainly be ported to stagex to have a completely verifiable, deterministic, and tamper evident supply chain.
By all means reach out if you want help! Not many of us working on this sort of thing.
By the same logic, wasn't this first email self-contradicting? If your data is gone, how are they emailing you to tell you that your data is gone?
But really, aren't companies legally required to retain a lot of information anyway? Such as invoices needed for tax purposes?
It was still in-memory for the deletion request after they finished the deletion query. It probably stayed in memory after the request finished, too, until the page was re-used. The horror.
It really is sad how much data has been captured and monetized of the average person. It seems like we're only continuing to turn up the heat as we continue to 'boil the frog'.
There is a somewhat accepted pattern here where backup processes are updated to retain a list of users who have requested deletion, and when a restore from backup is performed, before the restored system is brought back online, the data of users who have requested deletion is removed.
As with many other compliance and governance controls, this is a known pattern, but is subject to review by auditors, and the overall pattern, or the specific implementation of the pattern may not survive a legal test via a complaint by a consumer or regulator.
After all, how would they even email you back to tell you they deleted your data, if they deleted all records that include your email address?
(Of course, sufficiently advanced incompetence is indistinguishably from malice. Hard to say if that's applicable here.)
For example, you can store a record that an erased user requested erasure so you can prove it later on if needed in a legal situation (article 17.3.e). Updating such users about legal policies that apply to such retained data may still be subject to would seem rather inane but I could easily believe it existing as a policy at companies adopting a very eager interpretation of the regulations.
For example "Your personal information has been deleted" versus the potentially much messier truth, which might involve citing the GDPR, mentioning that for accounting reasons you have to maintain their details on invoices, areas of your financial auditing process, that you're maintaining a record of their request to delete the account, and so on and so forth.
They could tell the truth without going into the specific messy detail.