Security
TL;DR: CookieVault encrypts cookies on your device with Argon2id-derived keys and XChaCha20-Poly1305 before they ever reach our servers, so sync is zero-knowledge — we store ciphertext we cannot read. The code is open-source and auditable, with responsible disclosure, a bug bounty after 10,000 installs, and an independent audit planned for Q3 2026.
Security at CookieVault is the practice of ensuring that the data you trust to the product — chiefly the cookies you sync between devices — cannot be read by anyone but you, including us. The product achieves this with end-to-end encryption: keys are derived on your device from a passphrase we never receive, cookies are sealed before they leave the browser, and the cloud stores only opaque ciphertext.
Encryption architecture
In short: A passphrase is stretched into a key with Argon2id (memory-hard, the 2015 Password Hashing Competition winner standardized as RFC 9106), and each cookie record is sealed with XChaCha20-Poly1305 from libsodium. A per-device key enables fast unlock so the passphrase is only needed when enrolling a new device.
| Layer | Primitive | Role |
|---|---|---|
| Key derivation | Argon2id | Stretch passphrase into a strong key, on-device |
| Record encryption | XChaCha20-Poly1305 | Authenticated encryption of each cookie record |
| Library | libsodium | Audited, widely deployed crypto implementation |
| Fast unlock | Per-device device key | Avoids re-entering the passphrase every session |
Argon2id is the memory-hard key-derivation function that won the Password Hashing Competition and is now standardized as RFC 9106, chosen specifically to make brute-forcing a stolen ciphertext store expensive.1 XChaCha20-Poly1305 is an authenticated encryption construction with a 192-bit nonce, provided by libsodium, a portable cryptography library used across the industry.23
Open source and auditability
In short: The extension, the sync server, and this website are MIT-licensed and public. The cryptographic boundary is in code you can read, and store releases are reproducible-built from tagged Git commits so you can verify the binary matches the source.
How you can independently verify the claims:
- Read the source — the client and server are public on GitHub under the MIT license
- Locate the crypto boundary — find where plaintext cookies become ciphertext before any network call
- Check the tagged release — every Chrome Web Store version maps to a Git tag
- Reproduce the build — run the documented build to regenerate the artifact
- Compare hashes — match the store binary’s SHA-256 against the tagged CI artifact
This is what “auditable” means in practice: not a promise that the code is secure, but the ability for anyone to check it. Reproducible builds close the gap between “the source looks safe” and “the binary I installed is that source.”
Vulnerability disclosure
In short: Email [email protected], optionally PGP-encrypted using the key at /.well-known/pgp-key.txt. We run a 90-day coordinated-disclosure window, accelerate for active exploitation, and publish an advisory for every fix.
Our disclosure commitments:
- Contact —
[email protected], with a machine-readable pointer at/.well-known/security.txt - Encryption — PGP public key published at
/.well-known/pgp-key.txt(fingerprint added before launch) - Timeline — 90-day standard coordinated-disclosure window, accelerated for actively exploited issues
- Transparency — a public security advisory accompanies every fix
- Credit — researchers are credited unless they prefer to remain anonymous
A 90-day window aligns with the de-facto industry norm popularized by Google’s Project Zero, which balances giving vendors time to fix against leaving users exposed.4
Bug bounty and audits
In short: A paid bug-bounty program starts at 10,000 installs, when payouts are sustainable; until then researchers get public credit. An independent third-party security audit is planned for Q3 2026, and we will publish its report and our remediation.
| Program | Status | Milestone |
|---|---|---|
| Hall of fame | Active from launch | Public credit for valid reports |
| Paid bug bounty | Planned | Launches at 10,000 installs |
| Independent audit | Planned | Q3 2026, report published |
Sequencing the paid bounty after 10,000 installs is a deliberate, honest constraint: a credible bounty needs a budget that can pay out reliably, and we would rather credit researchers transparently now than advertise a bounty we cannot yet fund.
See also
- Privacy policy — what we collect and never collect
- No-sale pledge — our commitment never to sell data
- Open source — MIT license, reproducible builds, contribution guide
- Editor — the extension whose sync this architecture protects
Footnotes
-
Argon2 is specified in RFC 9106, “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications”: https://datatracker.ietf.org/doc/html/rfc9106. ↩
-
The ChaCha20-Poly1305 AEAD construction is specified in RFC 8439: https://datatracker.ietf.org/doc/html/rfc8439. ↩
-
libsodium provides the XChaCha20-Poly1305 secretbox/AEAD APIs used here; documentation: https://doc.libsodium.org/. ↩
-
The 90-day coordinated-disclosure norm is documented by Google’s Project Zero: https://googleprojectzero.blogspot.com. ↩