Security
Useful protection, explained without magic words.
Dropfile reduces permanent storage exposure, but no browser transfer can remove every risk. The safest choice starts with understanding the boundaries.
Transport encryption
WebRTC data channels use encrypted transport between connected peers. This protects file pieces from ordinary interception while they cross the network. HTTPS also protects requests made to Dropfile's coordination service.
Password-derived access
The browser derives a 256-bit access value from the download password using PBKDF2 with SHA-256 and a per-share salt. Dropfile stores a hash-based proof for authorization rather than the plain password. Strong, unique passwords remain important.
Piece integrity checks
The sender creates a temporary P-256 signing key. File pieces are hashed with SHA-256 and signed, allowing recipients to reject a piece that does not match what the sender produced.
Metadata still exists
Dropfile temporarily stores coordination data such as the share identifier, file name, media type, size, timestamps, hashed proofs, presence records, and WebRTC signaling messages. File bytes are not intentionally stored in that coordination bucket.
Peer-to-peer tradeoffs
Direct peers may learn network information exposed by WebRTC. Dropfile currently uses a STUN service and does not promise IP anonymity. Employers, schools, mobile carriers, VPNs, and firewalls may also restrict peer connections.
Your responsibilities
Treat the link and password like separate secrets, verify the recipient through another channel, scan unfamiliar downloads, and keep your own original copy.
- Send the link and password through different channels when possible.
- Stop sharing immediately if the link reaches the wrong person.
- Do not use Dropfile for pirated, stolen, malicious, or abusive material.
- For highly sensitive data, encrypt the file itself before sharing.