CommonSec Share
Part of CommonSec: practical security tools, researched in the open.
Try it: https://share.common-sec.org/
Share files and secrets directly between browsers, without storing them on anyone's server.
Most ways of sending a password, a key or a confidential file to someone leave a copy behind: in a
chat history, an email server, a cloud drive, or a "one-time secret" service that stores it until
it's read. CommonSec Share moves the data straight from one browser to the other, encrypted end to
end, and keeps nothing afterwards. It's a static web page with no backend, no accounts, and no
tracking. You can read all of it, run it locally, or host it yourself.
The aim is to make secure sharing easy for anyone: privacy by default, not anonymity.
| Tool | What it does |
|---|
Secure Share (/, the home page) | Encrypted transfer from computer to computer, browser to browser: ideal for passwords and sensitive files, between any kind of user, with no special software. Send text and/or files once to one person. They need the link and a passphrase. Once delivered, the link is dead. |
Secure Chat (/chat/) | For several things to exchange, replies, or more than two people: group chat with file sharing. The host approves every member, messages are signed and encrypted, and the room disappears when the host closes it. |
Encrypted files (/files/) | Encrypt files or a whole folder with a password into one OpenPGP file, to keep in the cloud or on a USB stick and open on any system, and decrypt it again. To give files to someone, Secure Share is the way. In the browser and offline: nothing is uploaded. GnuPG, Kleopatra and GPG Suite open the file too. |
Password Generator (/passwords/) | Memorable passphrases that are not just dictionary words (Stone~Behind~Karrotish~Pencils42~Over~Quail), or random-character passwords. |
How it works, in short
- The sender opens a room. The link carries a random 256-bit secret after the
#, the part of
a URL that browsers never send to any server. A separate passphrase is shared another way, for
example read aloud on a call.
- Both browsers find each other through a few public Nostr relays (via
Trystero). Only encrypted connection offers pass through
them, and the browsers disconnect from the relays as soon as they're no longer needed.
- The browsers connect directly with WebRTC, using public STUN servers to get through NATs.
Data is encrypted twice: by WebRTC (DTLS) and by the app (AES-256-GCM, keyed from the link
secret and the passphrase).
- The host proves its identity, the guest proves the passphrase, the host approves, and both
screens show a safety code to compare, which detects a man-in-the-middle.
There's no relay server for data (TURN), so if both sides are behind strict NATs or firewalls a
direct connection may be impossible. This is a deliberate trade-off: no third party ever carries
your data.
Documentation
| Document | For |
|---|
| docs/COMMUNICATION.md | How two browsers find each other and connect, step by step with diagrams (Nostr, NAT, WebRTC) |
| docs/DECISIONS.md | The decisions behind the design, why, and when to revisit them |
| docs/ARCHITECTURE.md | Components, data flow, network connections and ports, third parties |
| docs/PROTOCOL.md | Exact key derivation, handshake and message formats (for auditors) |
| docs/THREAT_MODEL.md | What is protected, against whom, and the known limits |
| docs/DEVELOPMENT.md | The containerised dev environment, pinning and supply-chain rules |
| docs/RELEASES.md | Rebuilding a release and verifying its checksums against what is served |
| docs/TESTING.md | How the test suite works and how to run it |
| SECURITY.md | Reporting vulnerabilities, audit scope |
| docs/ROADMAP.md |
Run it
Everything runs in containers (Docker + Compose; see docs/DEVELOPMENT.md):
docker compose run --rm build # type-check, build dist/, check it's reproducible
docker compose up web # app at http://127.0.0.1:8080
docker compose run --rm test-unit # unit tests (Chromium, Firefox, WebKit)
docker compose run --rm test-e2e # end-to-end tests through the real UI
docker compose run --rm semgrep # or trivy, trufflehog
The built app (dist/) is static files: any static host works for deployment (GitHub Pages, Cloudflare
Pages, Netlify). The Web Crypto API needs a secure context (HTTPS or localhost).
Design principles
- No backend, no storage. Nothing is uploaded, and nothing outlives the browser tab, except
the host's non-extractable keys while a chat room is open (to survive a reload, not a closed
tab). Rooms close on their own after a time limit (4 hours by default).
- No hand-rolled cryptographic primitives. All of them come from the browser's Web Crypto
API: AES-GCM, ECDSA P-256, HKDF, PBKDF2, HMAC, SHA-256 and the CSPRNG. Encrypted files use the
OpenPGP format through the audited openpgp.js library, so GnuPG opens them too. The protocol that combines
them is documented in PROTOCOL.md and covered by adversarial tests.
- Minimal dependencies. Four runtime dependencies (Trystero; qrcode-generator for the QR
code; openpgp.js and client-zip for encrypted files, decision D25), locked and bundled at build time, no framework, no CDN. Every line that runs is in this
repository or in the locked libraries.
- Readable and verifiable. Strict TypeScript, a strict Content Security Policy, and a
reproducible build: anyone can check the served files match the source.
Static analysis (Semgrep) runs on every push.
