Zero backups, and the things we can't promise

"Zero backups" is one line in our privacy policy, and one line is easy to read as a slogan. It isn't one. It's a handful of decisions in the code that runs tmp0.cc, and each of them has a price you pay along with us. This post spells out what the phrase means in practice, what still outlives your file, and where our promises stop.

What "zero backups" actually means

One copy, on one disk

An uploaded file is encrypted with AES-256-GCM and written to a single disk. There's no nightly backup job, no off-site replica, no cloud bucket on the side and no snapshot to roll back to.

The consequence is simple: if that disk fails, the file is gone. We can't restore it, because there's nothing to restore it from.

Every restart starts empty

This is the part that surprises people. Each time the server starts, whether after an update, a crash or a reboot, it deletes every file and paste record from the database and empties the upload directories before it serves the first request.

So a file can end before its expiry date. If you chose 30 days and we deploy an update on day three, your link stops working on day three. We'd rather lose a file early than keep one we can no longer account for.

Expiry is enforced on the spot

You choose how long a file lives, from 1 hour to 30 days. The moment that time passes, the link is refused, whether or not cleanup has run yet. A cleanup job then runs every five minutes and removes expired files, along with files that reached their download limit. Once an hour, a second sweep compares the disk with the database and removes anything left without a record, in case a delete failed along the way.

Deleting means overwriting, where it helps

Files up to 50 MB are overwritten three times with random data before they're removed. Larger files are removed without the overwrite passes: they're encrypted at rest, and rewriting gigabytes three times would slow the server down for everyone with little to gain. At the same time, the cached metadata (name, size, hash) is dropped from memory.

What outlives your file

Zero backups is about your files. Two kinds of records outlive them, and neither contains file content, file names or IP addresses:

The transparency log is what lets anyone check that we haven't quietly altered or swapped files. It can only do that if entries can't be removed, so this is the one place where "deleted" doesn't mean "no trace".

Things we can't promise

Every service has limits. These are ours.

That your file lasts until its expiry date

The expiry date is the longest a file can live, not a guarantee. A restart, a failed disk, a download limit or burn-after-reading can end it sooner. So can someone else: a file with a server-side password is deleted after five wrong guesses. That protects it from brute force, but it also means a stranger with the link can delete it by guessing badly.

If you need a file later, keep your own copy. tmp0.cc is for getting a file from A to B, not for storing it.

That we can recover anything

Forgot the password? Deleted the wrong file? No support ticket brings it back. We don't have a second copy, and for E2EE files we never had the key.

That the bits are physically gone

Overwriting works on classic hard drives. On SSDs, the controller decides where data physically lands, and wear-leveling can leave old blocks in spare areas that no software can reach or erase. We can't promise those blocks are wiped.

What we can say is that those leftovers are ciphertext. For regular and password-protected uploads, though, the key that encrypted them lives on the same server. For E2EE uploads, the key was derived in your browser and never reached us. If a file must not be readable after deletion, even in theory, use E2EE.

That E2EE hides everything

E2EE hides what's inside your file. It doesn't hide that a file exists, when it was uploaded, its approximate size, or its file name, which we need in order to offer the download. If the name gives something away, rename the file before you upload it.

That the code in your browser is honest

E2EE in a web app has one weakness no cryptography can remove: the encryption runs in JavaScript that we serve. If our server were compromised, it could serve altered code that leaks your password. Our security headers and published crypto specification make tampering harder and easier to spot, but they can't rule it out. If that matters to you, use the CLI: it encrypts on your machine with code you can read once and keep, instead of fresh code on every page load.

That a file is only seen once

Burn-after-reading and download limits control how often our server hands out a file. They don't control what happens after that. Whoever downloads it has a copy, and so might their browser cache, their downloads folder and their own backups. Once a file leaves us, our rules no longer apply to it.

That the transparency log forgets

Because the log stores the SHA-256 of each file, anyone who already has the same file can compute its hash and see when a copy passed through tmp0.cc. The log doesn't reveal the file or who sent it, but it does confirm a match. For E2EE uploads the hash is taken over the ciphertext, which is different every time, so there's nothing to match against.

That we control the layers below ours

We control our code and our configuration: no backup jobs, no replicas, no snapshots. We don't control the firmware on a disk, or what a data center does with a drive it swaps out. We can tell you what we run. We can't certify what happens beneath it.

Why we're telling you this

A privacy page that only lists strengths isn't much use, because you can't tell where it stops being true. These limits are where it stops. Once you know them, you can decide what tmp0.cc is the right tool for, and what it isn't.

Questions or corrections: privacy@tmp0.cc