What a subpoena gets from eight file transfer services

This piece skips the policy and goes straight to the question that matters: if someone served a valid legal order to your file transfer provider tomorrow, what would they actually hand over? A production order in England and Wales, a subpoena in US proceedings — the mechanism varies by jurisdiction; the question is the same.

The identity question

Two things can be handed to a court: what you sent, and who sent it. Most privacy discussions focus on the first. The second is just as consequential.

An account is a persistent identity anchor — every file, every access event, every IP address hangs off it and can be correlated. A court order that cannot read your files can still prove you sent them. WeTransfer logs your email address. Smash logs your email or your IP. SwissTransfer logs your IP. Even Proton, whose encryption is genuinely strong, ties your files to an account identity. Content protection and identity protection are not the same property.

For services without accounts, the legal order has no identity to request — because none was collected. OnionShare achieves this via Tor, which also masks IP addresses at the network layer. For users who want equivalent network-layer anonymity without requiring recipients to run Tor Browser, a VPN closes most of the gap.

Mullvad requires no account email at signup, accepts Bitcoin and Monero, and covers five devices.

Refueler Share requires no account either. That is a design choice, not an accident. It has costs: no account means no recovery, no persistent history. Paid tiers add transfer controls — expiry, revocation, storage — without attaching an identity to them.

The three services above are the simple case — the operator holds the encryption keys, so a valid legal order produces your files in plaintext. The picture below is more varied: content is protected, but the trade-offs on identity and metadata differ considerably.

What "encrypted" actually means

All of them are, technically speaking, correct. The question is: encrypted with whose key?

WeTransfer, Smash, and SwissTransfer encrypt your file in transit (TLS) and at rest on their servers. They hold the keys. A valid court order, a motivated employee, or a sufficiently thorough breach can produce your file in plaintext. This is not a flaw in their implementation — it is their architecture. They built a system where they can read your files, and they did so deliberately, because useful features like link previews, virus scanning, and thumbnail generation require it.

Tresorit and Proton Drive are different. Both encrypt client-side — your device does the encryption before anything leaves it, and the key never reaches their servers. A court order against Proton's infrastructure yields account metadata and IP addresses (as Swiss courts demonstrated in 2021) but not file content. The architecture earns the claim.

Wormhole states a similar property via PAKE — Password Authenticated Key Exchange, where the decryption key derives from a code shared out-of-band and never transmitted to the server. The claim is architecturally sound. The problem is that Wormhole is closed source and unaudited, so you cannot verify it. The gap between "they say so" and "we can check" is where legal risk lives.

The metadata problem

Client-side encryption solves one problem and leaves another standing.

Even when a provider cannot read your files, they know you have files. They know how large they are, when you uploaded them, when they were downloaded, and — increasingly, under legal pressure — who was at the keyboard when both events happened. IP address logs are metadata. Account identity is metadata. The graph of who sent what to whom, without a single readable byte of content, can be legally and journalistically significant.

Proton published a transparency report after their 2021 case. It confirmed what their architecture already implied: the content of a ProtonMail user's emails was never produced. The user's IP address was. Content protection and identity protection are not the same property, and privacy-focused providers vary considerably in which one they offer.

The honest position is to be specific about each: this is protected by mathematics, that is visible to the operator and therefore reachable by legal process.

What jurisdiction actually buys you

SwissTransfer's homepage prominently features Switzerland. The implication is that Swiss privacy law protects your files. This is partially true and mostly irrelevant.

Swiss law does require a valid Swiss court order to compel disclosure — a higher bar than a production order under the Police and Criminal Evidence Act in England and Wales, or a federal subpoena in US proceedings. But if the company holds your encryption keys, jurisdiction determines the process for getting your files, not whether they're gettable. A sufficiently motivated court in any jurisdiction that can reach the company will eventually produce a valid order. The flag on the website describes the legal process surface, not the cryptographic one.

Architecture protects your content. Jurisdiction shapes the paperwork required to ask for it.

What a court order gets from Refueler Share

Encrypted ciphertext the operator cannot decrypt. File sizes and chunk counts. Upload and download timestamps. Cloudflare edge IP addresses — the IP addresses of connections to Cloudflare's network, logged at the infrastructure level. No account. No identity. No payment record for the free tier; a Lightning payment hash (pseudonymous) or a Stripe record (identified) for paid tiers.

We publish this list voluntarily because the alternative — making you guess — is the pattern that produces the surprises in other providers' terms updates.

The encryption key for every file lives in the URL fragment. Fragments are not transmitted in HTTP requests and are not logged by servers. Whoever has the link has the key. Whoever doesn't, doesn't.

If you sent a file yesterday and deleted the link, the file is still in our storage until its expiry date — but it is, practically speaking, unreadable by anyone without the fragment. Including us.

What no service can do

None of these services protect against endpoint compromise. If the device you're using is already compromised, the file was readable before encryption touched it. Client-side encryption protects against server-side failure — a breach, a court order, a motivated employee. It is not a substitute for device security, and no provider in this space claims otherwise.

Understanding the boundary is part of understanding the tool.