Secure File Transfer Without Cloud Storage: What "No Storage" Really Means
Privacy-first file transfer explained: how relays work, how data is or is not retained, and what the threat model actually looks like.
"Secure" is a word that file-transfer services use a lot without unpacking what they mean. It usually combines three different things: in-transit encryption, at-rest encryption, and operational practices. Each addresses a different threat. If you don't know which threat you care about, you can't evaluate a tool against it. This article walks through what "no storage" relays actually guarantee, what they don't, and how to think about whether that's enough for what you're sending.
The three layers of file-transfer security
In transit
Bytes between the user's browser and the service's servers are wrapped in TLS. Every reputable service has this. It defends against passive network observers, Wi-Fi sniffers, and anyone sitting on the path. If a service is missing TLS, do not use it; full stop.
At rest
When a file is stored on a server's disk, "at rest" encryption means the file is encrypted with a key the provider holds. This protects against attackers who steal disks or backups. It does NOT protect against the provider itself, anyone who compromises the provider, or law enforcement requests.
Operational
Who at the company can read your file in a debugger? What logs exist? What happens when a government asks? How long is the file retained even after "you deleted" it? This is usually the weakest layer, and almost always the one that's least documented.
What "no storage" changes
A real-time relay like File Tunnel collapses these three layers somewhat. There is in-transit encryption (TLS). There is no at-rest encryption because there is no at-rest state — the file is never written to disk. The operational risk surface shrinks accordingly: there is no "debug from yesterday's data", no "produce the file in response to a subpoena", no "forgot to delete after the TTL." The bytes only exist in memory, only while both sides are connected.
That is meaningfully different from cloud upload services and worth understanding precisely.
What no-storage relays do NOT give you
Honest accounting requires admitting the gaps.
The relay sees the bytes (in memory)
While the file is flowing, the relay's process holds chunks in RAM to forward them. A malicious relay operator or someone with kernel access could read those bytes during the transfer. They cannot read them after, because they aren't there. But during, they could. If your threat model includes the relay operator, you need end-to-end encryption that the relay cannot decrypt, which usually means WebRTC peer-to-peer or client-side encryption with a passphrase you share through a different channel.
Metadata is visible
The relay knows the file name, file size, transfer code, when the transfer started, when it ended, and roughly how much data flowed through. This is unavoidable for the relay to function. If file names themselves are sensitive ("final_layoffs_list.xlsx"), rename before sending.
Endpoint compromise
No transfer protocol protects against a compromised sender or receiver device. If either machine has malware, the file is at risk regardless of how the bytes traveled.
Forensics on the wire
TLS protects against passive observation but not against TLS interception by a corporate proxy, a state-level actor with the right certificates, or a compromised root CA. This is true of essentially all web traffic.
Threat-model checklist
For a given transfer, ask yourself:
- Who must NOT see this file? Random passerby on Wi-Fi? Random cloud provider employee? A targeted attacker with state resources? The relay operator?
- For how long does that constraint apply? Just tonight? For ten years (because the file documents a sensitive plan)?
- What's the cost of failure? A mildly embarrassing email leaking, or a regulatory fine, or harm to a person named in the file?
- Can the recipient be trusted with the file? If the answer is no, no transfer protocol can help.
Matrix: pick the right tool
| You care about | Recommended |
|---|---|
| Passive Wi-Fi sniffing | Any HTTPS-based transfer |
| Long-term cloud storage exposure | No-storage relay |
| Provider not seeing bytes at all | WebRTC P2P or client-side encryption |
| Provider not seeing metadata | Self-hosted relay |
| Recipient verifying authenticity | Hash exchange via separate channel |
| Regulatory compliance (HIPAA, etc.) | Audited enterprise-grade tool |
Practical defaults for everyday work
For most professional handoffs — contracts, internal documents, media, personal photos — a no-storage relay with TLS is a stronger guarantee than the alternatives most people are using by default (email, generic cloud links, messaging apps). Pair it with a couple of habits:
- Pick a short expiry (10 minutes when both sides are ready).
- Rename files if their names are themselves sensitive.
- For very sensitive content, exchange a passphrase out of band and encrypt the file before sending (Veracrypt, age, gpg).
- Don't reuse transfer codes; each transfer is one-shot.
A note on compliance
Regulatory frameworks like HIPAA, GDPR, and Korea's Personal Information Protection Act assume durable record-keeping of who sent what to whom and when. A no-storage relay intentionally does not keep durable file records, which is a feature for everyday privacy but a poor fit for workflows that require audit logs. If you're sending regulated data, use the audited tools your organization has approved, not a public relay.
The honest summary
No-storage relays don't magically solve security. They eliminate one large, very common class of risk — files sitting on a server long after they were needed — and they make several smaller classes easier to reason about. For the threats most non-state-target professionals actually face, that is a real improvement. Just be clear about which threats remain.