Private, Secure File Sharing: The Checklist Any Service Should Pass

Ask any file-sharing service whether it is private and secure, and it will say yes. Those two words end up covering very different architectures depending on who is using them.

Some services mean the connection uses HTTPS — true of almost the entire internet, and not a meaningful differentiator. Some mean the file is encrypted after it reaches their server, which protects it from someone who steals a hard drive but not from the company itself, since the company holds the key. A minority mean the file is encrypted before it leaves your device, under a key the provider never receives at all. That last one is the only version of "private" that survives the provider itself being asked to hand over your file — by a breach, a subpoena, or a rogue employee.

"Secure" is the broader term. It covers transport, storage, and one thing people forget to ask about: metadata. A service can encrypt file content perfectly and still keep an indefinite log of who sent what, to whom, and when. That log is not the file — but for a lot of what people actually want privacy for, it is the more sensitive record.

Run any file-sharing service — including this one — against these seven questions before trusting it with something sensitive:

A service that fails one or two of these isn't necessarily untrustworthy — plenty of good products trade a checklist item for convenience deliberately. What matters is whether it tells you which ones it fails, or lets the word "secure" paper over the gap.

Send a file with direct mode and check every box yourself — nothing here has to be taken on faith.

"Zero-knowledge" gets used loosely enough that it is worth pinning down. Precisely, it means the provider holds no key capable of decrypting your file: encryption happens on your device, before upload, from a password or key the provider never receives. The system is designed so that our servers never hold a key that could decrypt your files. On a direct peer connection the file data never reaches us at all. When one cannot be established — or the transfer is too small to be worth negotiating one — it passes through our relay, and a peer connection that cannot find a direct route is carried by our TURN server. In every one of those cases what we handle is ciphertext we hold no key for.

That is a real, checkable architectural property — not a marketing adjective. It is also narrower than it sounds. Zero-knowledge describes the file's contents, not the transfer. The server still reads and stores the surrounding record — file size and type, the file name on cloud uploads, who uploaded it and when, and the IP address and browser of each side — and keeps it for the periods published in the privacy policy, not indefinitely.

And it is not the same as "the provider can never possibly see your file," because of one structural limit every browser-delivered zero-knowledge tool shares: That holds as long as the code running in your browser is the code we describe. For the encryption itself you no longer have to take that on trust: it is served as a published build you can reproduce byte for byte and compare against what your browser loaded. What remains is the application around it, which is closed source — it is what hands your file and your password to that code, and nothing here proves it does not read them first.

A service that states only the strong version of the claim — "we can't read your files," full stop — is skipping the half of the answer that actually matters. The algorithm names and key sizes on this page aren't hand-typed marketing copy — the direct-transfer encryption code reads its parameters from the same file this page quotes, and an automated build check fails the build if any page states a crypto claim of its own instead of importing it from there. The honest version of a zero-knowledge claim names both what it structurally prevents and what it still has to ask you to trust.

Applying the checklist to our own two modes, rather than only to competitors, is the point of publishing it:

The metadata row is the one most comparison pages skip. Neither mode is silent: which room or link, when, how many files and their sizes, which transport was used, and the IP address and browser user-agent of each side are logged to run the service, enforce rate limits and investigate abuse. Direct transfers drop the file name before writing that record; a cloud share keeps it, because serving the share needs it. That is disclosed rather than hidden, which is itself one of the checklist items — but it means neither mode is anonymous, only private about file content.

A few patterns are worth noticing when you run this checklist against a service we didn't build:

• "Encrypted" without saying where. If a page doesn't say whether encryption happens on your device or on the server, assume the server — that's the default, and the one worth naming when it isn't true.
• No published retention period, or a privacy policy that discusses file content but never mentions logs, IP addresses, or metadata at all.
• An account required before you can even read the terms of service. You're agreeing to something you can't see until after you've handed over an email address.
• No way to verify the claim. If a network panel shows a large upload despite a "we never see your file" claim, or there's no way to check at all, the claim is unverifiable by design.
• Crediting the wrong layer for the guarantee. A transport protocol securing the connection between your browser and a server is not the same thing as end-to-end encryption of the file itself — conflating the two is either careless or deliberate, and neither is reassuring.

None of this requires taking our word for it instead. The security architecture page and the how end-to-end encryption works guide lay out exactly which parts of our own claim are structural and which parts still ask you to trust the code we serve.