The Zero-Knowledge Illusion in Cloud Transfer Tools
· 3 min read · Updated
A transfer tool can only call itself zero-knowledge if it is never in a position to see your files or your credentials, and the only way to guarantee that is to keep the tool out of the path your data travels. For a tool that runs on someone else's servers, "zero-knowledge" describes what the company intends; the architecture does not enforce it.
Most hosted tools say your data is encrypted in transit, and it is. The encryption stops at their servers, where the data is decrypted so it can be read and sent on to the destination, then encrypted again for the second leg. That is hop-by-hop encryption: each leg is protected, but for a moment, on a machine you do not control, your files are in the clear.
Every relay has to work this way, whatever the company intends. So "encrypted in transit" and "we never see your files" are two different promises, and a hosted tool is only making the first.
Files in transit are the obvious worry; the keys are a bigger one. To move data on your behalf, a tool needs your storage credentials, and a storage key can read, write, list and delete across your account, well beyond a single transfer.
A hosted service has to store those keys somewhere so it can use them. That store holds the credentials of many users, which makes it a single valuable target, and a breach of it gives standing access to everyone's storage.
One arrangement delivers it: the tool runs on your own machine, keeps your credentials in local storage, and connects straight to your providers. With nothing in the middle, there is no relay to decrypt your files and no shared vault to breach, and the vendor's service knows nothing because it is not in the transfer path.
Blober works this way. Credentials stay in a local store on your computer, the data streams directly between your providers and your machine, and there is no Blober account or server in the path.
Three questions sort out the architecture, and the last one is the most telling:
- Does it require an account with the tool's own service? A purely local tool may need a licence, but it has no account that holds your data.
- Where are credentials stored? On your machine, or on the tool's servers?
- Can it run when the tool vendor's own servers are unreachable? If the core transfer still runs, those servers are not in your data path, so the tool cannot be sending your files through them. If it cannot run, they are in the path.
The command-line tool rclone is also local, and that is its strength: it runs on your machine and moves data directly between providers. Its credentials live in a configuration file on your disk, which rclone says should be protected because it typically contains login information[1]. Blober works on the same local-only principle without the configuration step: it stores your credentials on your own machine and connects straight to your providers.
Zero-knowledge is about the middleman. No tool can protect you from a provider you have chosen to authorize, since that provider can see what is in its own account by definition. A local-first tool removes the extra party, the one that had no need to see your data and no business holding your keys.
Is "encrypted in transit" enough? It protects data from outsiders on the wire. The service doing the relay still decrypts it to pass it along, so end-to-end privacy requires that no middle service ever holds the unencrypted data.
Why are credentials a bigger deal than the files? A single transfer exposes one set of files. A leaked storage key exposes the whole account, for as long as the key stays valid.
How do I know a desktop tool is not phoning home? Run it with the vendor's own servers unreachable. If the transfer between your clouds still works, your data is not passing through them.