Security model
We do not do “military-grade” marketing. This page states precisely what is protected, by which mechanism, and what remains your responsibility.
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 8 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”.
Found a vulnerability? Please read our security disclosure policy.