Security
Security model, stated carefully
Security claims should match the code. Here is what XtremeShare actually does — and what it does not promise.
Start sharing freeTransport and payload encryption
When the site is served over HTTPS, signaling and page loads use TLS. Separately, file chunks are encrypted in the browser with AES-GCM before they are sent on the data channel.
Open shares place a transfer key in the URL fragment (`#k=`), which browsers do not send to servers in normal navigation. Password-protected shares derive a key with PBKDF2 from the password and a salt.
What servers can see
Room metadata includes filenames, sizes, MIME types, presence, and WebRTC signaling messages. Password hashes (when used) are stored for verification. File bytes are not written into an XtremeShare cloud archive on the live P2P path.
If TURN is configured and ICE selects a relay, relayed WebRTC traffic may pass through that relay as ciphertext for the payload path.
Password protections
Optional passwords gate starting a transfer. After three failed attempts, the room is removed. Passwords are a link-sharing control, not a substitute for endpoint security on either device.
Responsible disclosure
If you believe you found a security issue, email hello@xtremeshare.cloud with enough detail to reproduce. Prefer coordinated disclosure. See also /.well-known/security.txt.
FAQ
- Do you claim end-to-end encryption certification?
- We describe the implemented AES-GCM chunk encryption and password derivation. We do not invent audit badges or certification logos.
- Are share links private from search engines?
- Share URLs are disallowed in robots.txt and marked noindex. Treat links like secrets anyway — anyone with the link (and password, if set) can attempt a receive while the room is live.