What a File Transfer Reveals — and to Whom
“Encrypted” answers one question (can someone read the file?) and leaves several others open. Who can tell that a transfer happened at all? Who learns the file name, the size, the time, the two parties? This article maps those questions across the common ways of sending a file, observer by observer, so the trade-offs are visible instead of implied.
The observers
Five parties can be in a position to learn something about a transfer:
- The local network: whoever runs the Wi-Fi you are on: home router, office IT, hotel, café.
- Your ISP and, on mobile, your carrier.
- The service: the company whose app or website you use.
- A relay: a server that forwards packets when a direct path is impossible.
- The recipient: who, of course, gets the file, but also gets metadata about you.
What each one can see
| Observer | Cloud link / upload service | Chat app | P2P, direct | P2P, via encrypted relay |
|---|---|---|---|---|
| Local network | That you talked to the service; volume and timing | Same | The other device's IP, volume and timing; on the same LAN, that two local devices exchanged traffic | That you talked to the relay; volume and timing |
| ISP / carrier | Service's domain (via DNS/SNI), volume, timing | Same | The peer's IP address, volume, timing | The relay's IP, volume, timing |
| The service | The file itself, its name, size, your IP, account, the recipient's access | Usually the file (unless end-to-end encrypted), plus who sent what to whom, when | Only the session setup: a room ID, both IPs during setup, connection state. Not the file, not its name | Same as direct |
| Relay operator | — | — | — | Both IPs, packet sizes and timing. Not the contents: DTLS keys are negotiated end-to-end and the relay holds none |
| Recipient | File, and often your account identity | File, your profile | File, plus your IP address (WebRTC exposes it to the peer) | File; sees the relay's IP rather than yours |
Reading the table honestly
Three things stand out. First, an upload service is the only design where a third party holds the file. Everything else leaks metadata; only that model leaks content. Second, peer-to-peer trades one exposure for another: the service learns almost nothing, but the recipient learns your IP address, because that is how a direct connection works. For most transfers between people who know each other, that is a non-issue; for a whistleblower it is disqualifying, and a relay (or a VPN) is the mitigation. Third, the relay is not a privacy hole in the way people fear (it cannot read anything), but it is a vantage point on who, when and how much, which is exactly what traffic analysis needs. An honest tool tells you when you are on one (why that matters).
What the service keeps: ShareDrop.org's own numbers
As a concrete case, here is what ShareDrop.org actually retains, as stated in the privacy policy and enforced in the code:
- Session data: a random room identifier, connection state and short-lived credentials — lives in memory with a time-to-live of minutes and is gone when the session ends.
- Connection negotiation messages (SDP/ICE) are relayed between the two browsers and not persisted.
- IP addresses appear in security logs used for rate limiting and abuse defence, retained for at most 24 hours.
- File names, contents, checksums and safety codes never reach a server. There is no upload endpoint; the relay forwards ciphertext it cannot open.
That last line is architecture, not policy: the data channel keys are negotiated between the two browsers during the DTLS handshake (how), so there is nothing a server could decrypt even under compulsion.
A worked example: what someone in the café logs
Suppose a person at the next table is capturing every packet on the open Wi-Fi while you send an 800 MB video to a friend across town. In order, they record:
- A DNS lookup for
app.sharedrop.org, unless your device uses encrypted DNS, in which case they see only that a DNS query happened. - A TLS connection to the signaling server, with the hostname visible in the handshake (the SNI field) and everything after it encrypted.
- A few small packets to a STUN/TURN address: the “what is my public address?” exchange.
- Six minutes of DTLS packets, about 64 KiB apart in bursts, to a single address that is not a known server: your friend's router.
From that they can say: this device used ShareDrop.org, sent roughly 800 MB to 203.0.113.7 between 14:32 and 14:38, and received almost nothing back. They cannot say what the file was called, what it contained, or whether it was a video or a spreadsheet: the chunk sizes are the same either way. Had the transfer gone through a relay, item 4 would point at the relay's address instead of your friend's, and the observer would not learn who you sent to.
DNS, SNI, and the encryption that is still arriving
Two of the leaks above are being closed at the protocol level. Encrypted DNS (DNS-over-HTTPS or DNS-over-TLS, now a switch in every major operating system) hides the lookup from the local network, though the DNS provider then sees it instead. Encrypted Client Hello hides the hostname in the TLS handshake and is rolling out across browsers and hosting providers. Neither changes the peer-to-peer part: a direct connection is to an address, and the address is visible to anyone on the path — that is what the relay option is for when it matters.
What about Tor?
Tor Browser disables WebRTC entirely, because a peer-to-peer connection would bypass the Tor circuit and reveal the real address — the same reason it matters here. A browser-based transfer therefore does not run over Tor at all, and it is better to say so than to let someone believe it does. For a transfer that must hide the endpoint from the peer, the relay and a VPN are the tools available.
How long each party keeps what it saw
| Method | Content retained by a third party | Metadata retained |
|---|---|---|
| Cloud drive | Until deleted, plus trash and backups | Access logs, sharing history — typically for years |
| Upload-and-link | For the retention period, plus backups | Uploader and downloader addresses and times, often longer than the file |
| Chat app | Until deleted, unless end-to-end encrypted; backups may hold copies indefinitely | Who messaged whom and when — frequently kept far longer than content |
| Indefinitely, in two mailboxes and their backups | Headers and logs, indefinitely | |
| P2P (ShareDrop.org) | Nothing — no content ever reaches a server | Session data for minutes; addresses in security logs for at most 24 hours |
The row that surprises people is chat: the content may be well protected while the record of who talked to whom is kept for years, because that record is what the provider uses to run the service. Metadata retention is the question to ask of any service, and the one privacy policies answer least clearly.
Reducing your footprint: a short checklist
- Turn on encrypted DNS in the operating system; it removes the lookup from the local network's view.
- If the peer must not learn your address, use a VPN (the peer sees the VPN exit) or accept a relay (the peer sees the relay).
- For content, avoid any method that stores the file on a server; for metadata, prefer methods that keep it for minutes rather than years.
- Clear the transfer history on your own device when it has served its purpose; it is a record too, even if only a local one.
- Remember the recipient: what they keep and where they back it up is outside every technical measure above.
Choosing by threat, not by slogan
- Worried about the company seeing your files? Avoid upload services; P2P or a genuinely end-to-end-encrypted chat app.
- Worried about the recipient learning your IP? Use a relay or a VPN; note that a VPN can itself force relay mode (details).
- Worried about your network admin? Every method reveals volume and timing to the local network; only content is protected. Use a network you trust for anything sensitive.
- Worried about the file being kept? Only upload services and cloud shares keep one. P2P leaves nothing behind by construction.
Standards referenced
- RFC 8827: WebRTC Security Architecture: end-to-end key negotiation, and the IP-exposure property of peer connections.
- RFC 8656: TURN: what a relay forwards and what it cannot see.
- RFC 8446: TLS 1.3, for the server-name (SNI) exposure noted in the ISP row.
