Is P2P file sharing safe?
Short answer: yes — when it is true P2P. File bytes travel over a DTLS-encrypted channel directly between the two browsers, and the server never receives them. But "encrypted" gets printed on a lot of boxes. Here's how to tell the real thing from marketing.
How the encryption actually works
When two browsers open a WebRTC data channel, they negotiate encryption with DTLS (Datagram TLS) — the same family of cryptography that protects HTTPS, adapted for real-time traffic. The keys are agreed directly between the two devices during connection setup; no third party holds them, and every 256 KB chunk of your file is encrypted before it leaves the sender.
The practical result: someone watching the network sees scrambled packets and packet sizes. They cannot see file names being transferred in-band, file contents, or anything usable — only that an encrypted connection happened. Our full data policy is in the privacy policy.
What the server sees (and never sees)
| Data | Server sees it? | Why |
|---|---|---|
| Room ID, file names + sizes | Yes (in memory) | Receiver must preview what's on offer |
| Connection setup (SDP/ICE) | Relayed, not stored | Browsers need introductions |
| Your IP (for rate limiting) | Transiently | Abuse throttling, never logged with transfers |
| File contents | Never | Bytes take the direct beam, not the server |
| Anything after you close the tab | Nothing — room deleted | Memory only, no database |
5 checks before you trust any tool
- Can the provider show you what it stores?
A privacy page that lists exact data (like ours does) beats "military-grade encryption" slogans. Vague means unverifiable.
- Does "encrypted" mean end-to-end?
TLS-to-server is table stakes — the server still sees plaintext. End-to-end (DTLS/WebRTC) means it can't. Ask which one.
- Is there anything to breach?
No stored files = no file breach. An account database, stored transfers, and analytics SDKs are all breach surface.
- What happens when you leave?
Close-tab-means-gone is stronger than a 30-day retention toggle you'll never open.
- Are files verified on arrival?
Every file here carries a byte count + SHA-256 digest; corrupt arrivals fail loudly and save nothing. A tool that can't prove integrity can't claim safety.
The relay exception, explained
On strict corporate networks, a direct path may be impossible — so the connection can fall back to a TURN relay. The relay operator can observe that an encrypted connection happened and how much data crossed, but still not the contents: DTLS terminates at the two devices, not at the relay. When no relay is needed, nothing extra is involved at all. Honest tools disclose this; now you know it too.
Encryption can't save you from sending to the wrong person. Check the file list on the receive page, confirm the sender through a second channel for sensitive files, and report anything suspicious — confirmed abuse disables rooms immediately.
Questions, answered
Can the operator read my files?
No. File bytes never reach the server, so there is nothing to read, scan, or hand over — even if asked. The server sees room metadata and connection setup only.
Is P2P safer than Google Drive?
For confidentiality from the provider, yes: Drive stores your files on Google's infrastructure. For availability (fetch while the sender sleeps), Drive wins. Pick per job — see the honest comparison.
What about malware in received files?
Integrity checks prove a file arrived intact — not that it's benign. Treat unexpected executables with suspicion, scan downloads, and report abuse; filenames are validated against spoofing tricks server-side.
Does incognito / VPN change anything?
The transfer encryption is identical. A VPN hides your IP from the server; incognito only affects local history. Neither weakens DTLS.
The safest transfer is the one that leaves nothing behind
Encrypted in transit. Zero bytes stored. Gone when you close the tab.