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.

LayerPrimitiveRole
Key derivationArgon2idStretch passphrase into a strong key, on-device
Record encryptionXChaCha20-Poly1305Authenticated encryption of each cookie record
LibrarylibsodiumAudited, widely deployed crypto implementation
Fast unlockPer-device device keyAvoids 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:

  1. Read the source — the client and server are public on GitHub under the MIT license
  2. Locate the crypto boundary — find where plaintext cookies become ciphertext before any network call
  3. Check the tagged release — every Chrome Web Store version maps to a Git tag
  4. Reproduce the build — run the documented build to regenerate the artifact
  5. 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 security@cookievault.net, 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:

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.

ProgramStatusMilestone
Hall of fameActive from launchPublic credit for valid reports
Paid bug bountyPlannedLaunches at 10,000 installs
Independent auditPlannedQ3 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


Footnotes

  1. 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.

  2. The ChaCha20-Poly1305 AEAD construction is specified in RFC 8439: https://datatracker.ietf.org/doc/html/rfc8439.

  3. libsodium provides the XChaCha20-Poly1305 secretbox/AEAD APIs used here; documentation: https://doc.libsodium.org/.

  4. The 90-day coordinated-disclosure norm is documented by Google’s Project Zero: https://googleprojectzero.blogspot.com.