The Illusion of Delete

A few years ago I permanently deleted my Facebook account, which Facebook treats as a separate and more final step than deactivating it. Facebook walked me through the process, warned me repeatedly that this was permanent and showed me what I would lose, and once I had clicked through all the confirmations, the account vanished with my profile, my posts and my photos.

Except they were not gone. Facebook’s terms say deleted data might persist in backups for up to 90 days. Every message I sent still sits in someone else’s inbox for context. Every third-party app I logged into still has whatever data it pulled, and they likely never knew I sent in a deletion request. Every advertiser I interacted with still has the profile they built from my behaviour.

At the same time, I wanted Facebook to keep these backups so my account would not disappear if their servers failed, and I wanted their app to be fast and reliable, which would require replication of data across multiple data centres in different regions. And all of those reasonable expectations made true deletion nearly impossible.

The Impossible Ask

When you press delete, you are asking a system to do something that contradicts every other expectation you have of it. You want the data gone immediately and completely, but you also want the service to be fast, reliable and fully compliant with the law. These goals are incompatible.

Think about what we expect from modern systems. If a service is slow, we close the tab and go to their competitor. If we lose data because a server crashed, we demand accountability and make a great deal of it. If a company cannot produce records for an audit or legal inquiry, we call it negligent. We have built an entire technological civilisation around the assumption that data is always available, always correct, and never lost.

Deletion breaks all of those guarantees. True deletion means accepting that data might vanish when you do not want it to. It means slower systems because caches cannot be trusted. It means accepting the risk that backups will not save you or your data. We say we want deletion, but what we really want is selective, perfect, retroactive control over data. That does not exist.

Why Systems Remember

Systems are designed to persist data because that is what we asked them to do, and every feature we demanded has a cost: permanence.

Performance Requires Caching

When you load a website, your browser does not download every image, stylesheet and script each time, but caches them locally. Content Delivery Networks (CDNs) also store copies around the world so pages load in milliseconds instead of seconds. Databases keep frequently accessed data in memory. There may even be several replicas of the database in different regions for redundancy and load balancing. If you delete something, those caches do not evaporate instantly, but slowly over time. Purging a cache across a distributed system takes time, and even then, copies may persist in browser caches, proxy servers or network infrastructure managed by third parties.

We abandon a page that takes more than two seconds to load, so speed is not optional, and speed requires copying data everywhere. Deletion is the opposite of speed in this case.

Reliability Requires Backups

Servers fail all the time for various reasons. Disks wear out, SSDs after a finite number of writes, and entire data centres go offline because of power outages or connectivity issues. If a company loses your data because they did not keep backups, you would rightly call it negligent, so platforms snapshot their databases hourly or daily. When you delete something, it vanishes from the live system, but it sits frozen in those backups for weeks, months or even years in rare cases.

Backups are designed to restore everything to a previous state. They are not designed to honour individual deletion requests. Cleaning deleted items from backups is technically possible, but expensive and risky, and most platforms do not bother. You wanted your data to survive disasters, which means it also survives you pressing delete.

One technique does reach into the backups without touching them, and it is called cryptographic erasure. Each user’s data is encrypted under its own key, and deleting the user means destroying that key, so nobody has to hunt down every copy of the data. The copies remain, in the live system, the caches and every backup, but none of them can be decrypted any more. NIST’s guidance on media sanitisation treats it as a recognised way to purge data, and notes that for cloud storage, where the owner never touches the physical disks, it may be the only one available. It has to be designed in from the start, though, and it moves the problem to the key, which becomes the one thing that must never be lost by accident.

Compliance Requires Retention

Laws require companies to keep records. Financial transactions must be retained for years for tax audits. Communications with customers may need to be preserved in case of disputes. Employment records, medical data and legal filings all have mandatory retention periods.

Even when you delete something, the law might require the platform to keep it, and GDPR allows companies to refuse deletion requests if retention is legally required. You cannot audit a company that has deleted all its records, so compliance creates a legal obligation to remember, even when users want to forget.

Undo Requires History

We expect every action to be reversible. Accidentally deleted a file? There is a trash folder, and cloud storage keeps version history so you can recover earlier drafts.

All of this is implemented through soft deletes: marking data as gone without actually removing it. The system tracks what was deleted and when, so it can restore it if you change your mind. This is useful and expected. It is also incompatible with true erasure. You cannot have both perfect undo and perfect deletion.

None of this is a conspiracy, and not all of it is intentional or malicious, although some may be. It is just what happens when you build systems that are fast, reliable, compliant, and forgiving. Every one of those goals requires keeping data longer than users expect.

When Deletion Actually Works, and What It Costs

ProtonMail is one of the few services that takes deletion and data protection seriously. Emails are end-to-end encrypted, which means that neither Proton nor any third parties can read them. Behind this guarantee is a simple architecture: one password serving as the key to your account and as the password to the underlying encryption key. Only you hold what unlocks that key, so losing it has the same effect as cryptographic erasure: the data is still stored, and nobody can read it. Proton does not have the ability to recover your keys, so there is no backdoor and no “answer these security questions” workflow.

This is exactly what privacy advocates like me have been asking for: a system where the provider genuinely cannot access your data, even if they wanted to. True deletion by design.

And people lose years of emails because of it.

People forget their passwords, and a passphrase set once and typed rarely is exactly the sort of thing a memory lets go of. Unless you set up a recovery phrase or file beforehand, months or years of emails vanish with it, and there is no “reset password” link to save you. Proton support cannot help either, because it never holds anything that could unlock the data.

The trade-off is that if you want a system that cannot be compelled by governments, breached by hackers, or exploited by advertisers, you get a system that also cannot save you from yourself. The same encryption that protects your data from everyone else also means no one can recover it for you.

Most of us want something else. We want a system that is secure against everyone else and forgiving towards us. We want deletion to be real when we click delete, and reversible when we realise we have made a mistake. We want encryption that keeps governments out, and a way back in when we forget the password. Every one of those is a fair thing to want. No single system can hold them all at once.

Security trades against convenience, and deletion against recovery; a system that leans hard into one gives up the other.

ProtonMail made a choice: security and deletion over convenience and recovery. And that choice makes the service unforgiving for many people. Not because Proton is incompetent or malicious, but because they built one half of what we asked for and there was no way to build the other. I have seen countless stories of people who lost access to their data because they forgot a password. They were not careless. Nobody had told them that this was the deal.

The Limits of the Right to Be Forgotten

GDPR’s Article 17 gives EU residents the “right to erasure,” commonly called the right to be forgotten. In theory, you can request that organisations and companies delete your personal data, but in practice, this right forgets the technical realities of how data is stored and how compliance laws work.

The right to be forgotten sounds powerful until you hit the exemptions. Companies can refuse deletion requests for legitimate purposes, including legal compliance, security, fraud prevention, research, public interest and freedom of expression. These are reasonable reasons in theory. The problem is you have no idea which exemption applies to your data, why or for how long.

Submit a deletion request to a platform and you might get a confirmation that your data has been deleted. But what does that actually mean? Was it purged from backups, or just marked as deleted? Was it removed from third-party systems, or just from the main database? If it was kept for a legitimate purpose, which purpose? For how long? The platform is not required to tell you, and most do not.

You are left trusting that the company deleted what it said it would delete, kept only what it was required to keep, and will purge the rest when the exemption expires. But you have no way to verify any of this. The right to be forgotten is not backed by a right to audit, so deletion happens behind closed doors with no accountability. And even if we had the right to audit, it would be a nightmare to verify. You would have to understand the company’s data architecture, track every copy of your data across all systems, and confirm that each one was deleted or retained according to the law. This is beyond impractical; for an individual it is simply impossible.

However, the right to be forgotten is not worthless. It has forced companies to build deletion workflows and take privacy more seriously. But it is a legal overlay on systems that were never designed for erasure. Deletion is often incomplete, delayed, or impossible to verify, and you have no way to know which.

The Distributed Problem

Even if a single platform could implement perfect deletion, the internet is not a single platform. Data gets copied to places you do not control, and those copies follow their own rules.

Email is the oldest example. Once you send an email, copies exist on your mail server, the recipient’s mail server, any servers the email was forwarded through, and the recipient’s local mail client. There is no central delete button. You can ask the recipient to delete their copy. You cannot enforce it.

Federated social networks like Mastodon work the same way. When you post something, it is copied to multiple servers operated by different people and organisations. If you later delete the post, your server sends deletion requests to other servers, but there is no guarantee they will honour them. A malicious or malfunctioning server can ignore the request entirely, and even well-intentioned servers might have already backed up your post before the deletion request arrived.

Blockchain-based systems take this to an extreme, because data written to a blockchain is permanent and cannot be altered or removed. There is a long technical explanation to this, but in essence any newly added piece of data cryptographically depends on the data that came before it, creating a chain where each piece depends on the previous one. This immutability is the biggest selling-point for certain applications (cryptocurrency transactions, smart contracts), but it is fundamentally incompatible with deletion. You cannot unsay something on a blockchain, and yet people want both the immutability and the ability to undo.

The more distributed a system, the less feasible deletion becomes. This is a trade-off. Decentralisation offers resilience, censorship resistance and reduced reliance on single authorities. It also sacrifices the ability to erase information.

Living with the Trade-Off

So where does that leave us? We have built a digital infrastructure that remembers everything because of what we demanded: systems that never fail, never lose data, load instantly, and comply with every law. Deletion contradicts all of those goals.

Yes, some companies profit from retention. Yes, surveillance capitalism creates incentives to keep more data than necessary. But even if every platform were a nonprofit run by privacy advocates, backups would still exist, caches would still persist, and compliance would still require retention. The ProtonMail example shows this; even when a company genuinely prioritises deletion, the result frustrates users.

The question is not “why do systems not delete data?” but “what are we willing to give up to make deletion possible?”

Slower load times because caches cannot be trusted? Riskier data storage because backups are incomplete? A key that takes everything with it the day it is lost? Legal liability because you cannot produce records for audit? The inability to recover from mistakes because undo is impossible?

I do not think most of us are willing to accept those trade-offs. We want two things at once: an internet that is fast, reliable, recoverable and compliant, and perfect control over our data, including the ability to erase it completely. Those expectations are in direct conflict. Some companies are careless with what you asked them to delete, and a few keep it on purpose, but the delete button would fail even for the honest ones, because we asked for all of it at once.