Security & privacy
We do not do “military-grade” marketing. This page states precisely what is protected, by which mechanism, and what remains your responsibility. The guides below answer the specific questions people ask before sending something that matters.
Guides by question
Is a WebRTC Data Channel Encrypted? Yes — Here Is How
DTLS, SCTP and certificate fingerprints: the encryption WebRTC mandates, what it protects against, and the one attack it cannot stop on its own.
“End-to-End Encrypted” vs “Encrypted”: They Are Not the Same Thing
Encrypted at rest, encrypted in transit and end-to-end encrypted describe three different sets of people who can read your file. How to tell which one a product actually means.
How a Safety Code Proves You Are Connected to the Right Device
Why encrypted is not the same as authenticated, and how comparing a short code derived from DTLS fingerprints detects a man-in-the-middle.
Sending Files on Public Wi-Fi: Real Risks, Not Scare Stories
Most public-Wi-Fi warnings are ten years out of date. What an attacker on the same café network can and cannot do to an encrypted transfer today, and the two checks that actually matter.
How to Send Sensitive Documents: a Practical Checklist
Ten checks, in order, before a contract, medical record or ID scan leaves your device, covering the channel, the recipient, the copies left behind and the things encryption cannot fix.
What a File Transfer Reveals — and to Whom
Even an encrypted transfer leaks something. A layer-by-layer map of what your Wi-Fi admin, your ISP, the service, a relay and the recipient can each observe, for cloud links, chat apps and peer-to-peer.
How to Know a Received File Is Complete and Uncorrupted
Transfer finished does not mean file intact. How end-to-end SHA-256 verification works and why ShareDrop.org refuses to mark a file done without it.
The security model
Transport encryption
Every ShareDrop.org transfer runs over a WebRTC data channel. The WebRTC standard makes encryption mandatory: data channels use DTLS (the datagram version of TLS) with keys negotiated directly between the two browsers. Neither our signaling server nor a TURN relay possesses those keys. This is standardized behaviour (RFC 8827, RFC 8831), not something we bolted on.
What each component can see
| Component | Sees | Never sees |
|---|---|---|
| Signaling server | Room lifecycle, connection negotiation messages (SDP/ICE), IP addresses | File names, file bytes, file hashes, the invite secret in your URL |
| TURN relay (relay mode only) | Encrypted packet flow, packet sizes and timing, IP addresses | Decrypted file content — it has no keys |
| The other device | Everything you choose to send it | — |
That last row matters: once a file arrives, the receiving device owns a copy. Encryption in transit says nothing about what the recipient does afterwards.
Identity: what safety codes solve
Encryption alone answers “can anyone eavesdrop?” but not “am I talking to the right device?”. If an attacker fully controlled the signaling path, they could try to terminate encryption on their own machine and re-encrypt towards each of you. The safety code closes this gap: both browsers derive a six-digit code from the DTLS certificate fingerprints they actually negotiated. An interception of this kind produces different fingerprints on each side — and therefore different codes. Compare the code over any independent channel (out loud, over a call) before sending sensitive files. Full derivation details: safety codes explained.
Integrity
Both ends compute an incremental SHA-256 of every file. The receiver only reports success if its checksum equals the sender's. Corrupted or truncated files are marked failed and the partial data is discarded, never silently kept as a “complete” file.
Abuse resistance
- Rooms are single-use, unguessable (128-bit random IDs) and expire in minutes.
- Short codes are 6 characters from an unambiguous alphabet, single-use, aggressively rate-limited, and still require your explicit accept.
- Session credentials are short-lived and single-use; replaying one is rejected.
- File names from the other device are treated as untrusted input and sanitized before they touch your screen or disk (including path-traversal attempts in folder transfers).
- TURN relays refuse to forward traffic to private or loopback networks.
Honest limits
- We cannot scan files for malware: there is no server that ever holds them. Treat received files from strangers with the same caution as email attachments.
- Metadata (IP addresses, timing, transfer sizes) is visible to networks in the path, as with any internet traffic.
- If you skip the safety-code comparison, you are trusting the signaling infrastructure. The app reflects this by showing “identity not verified”.
Common questions
Do my files pass through your servers?
File bytes never touch our application servers: there is no upload endpoint. When a direct connection is impossible, an encrypted relay forwards packets it cannot decrypt and does not store. The app always shows which mode you are in.
How do I know the file arrived intact?
Both devices compute a SHA-256 checksum. Only matching checksums mark a file as done; anything else is reported as failed and discarded.
Start a transferFree, no account, nothing to install.
Found a vulnerability? Please read our security disclosure policy.