End-to-end encrypted cloud sync
TL;DR: CookieVault encrypted cookie sync uses libsodium’s XChaCha20-Poly1305 with Argon2id-derived keys. Your cookies are encrypted on the device before leaving the browser, and the sync server stores only opaque ciphertext — ciphertext that even CookieVault engineers cannot decrypt. It is a Pro, zero-knowledge feature.
End-to-end encrypted cookie sync is a zero-knowledge mechanism that keeps your cookies in lockstep across devices while ensuring the cloud server stores nothing but undecryptable ciphertext. Your passphrase derives the encryption key on your own device using Argon2id; that key never touches CookieVault infrastructure, which means neither our engineers, a server compromise, nor a legal demand can reveal your cookies. It is the Pro-tier backbone shared by both CookieVault Editor and CookieVault Guardian, and the cryptographic boundary is open source so the claim is verifiable rather than promised.
How the encryption works
In short: Your passphrase goes through Argon2id (memory-hard key derivation) on-device to produce a master key. Each cookie record is then sealed with XChaCha20-Poly1305 from libsodium before leaving the browser. The server receives only ciphertext and an authentication tag; it never sees the key.
The pipeline is deliberately built from well-reviewed primitives rather than custom cryptography. Argon2id is the memory-hard algorithm that won the Password Hashing Competition, chosen specifically because it resists GPU and ASIC brute-force attacks against a human-memorable passphrase. XChaCha20-Poly1305 is an authenticated encryption construction with a 192-bit extended nonce — wide enough to pick nonces at random without practical collision risk, which removes a whole class of implementation footguns.
Six properties define the design:
- Client-side key derivation — Argon2id turns your passphrase into a key on your device; the key is never transmitted or stored server-side
- Per-record encryption — each cookie is individually sealed with XChaCha20-Poly1305, so a single corrupted blob never poisons the whole vault
- Authenticated ciphertext — the Poly1305 tag detects any tampering, so a modified blob is rejected rather than silently decrypted into garbage
- Per-device subkeys — each browser derives a fast-unlock subkey so it does not re-run the full Argon2id cost on every sync cycle
- Ciphertext-only storage — the sync server persists opaque blobs plus minimal routing metadata, never plaintext
- Open cryptographic boundary — the derivation, encryption, and sync-client code are public so the data path is auditable
A widely held principle in applied cryptography is that you should encrypt before you upload, not trust the server to encrypt for you. That is exactly the boundary CookieVault enforces: the browser is the only place plaintext ever exists.
The threat model
In short: We assume the server can be fully compromised and design so that it does not matter. Server breach, network interception, and a subpoena all reduce to “attacker has ciphertext.” The one scenario that exposes plaintext is an attacker controlling your unlocked device — which no sync system can defend against.
Cookies are bearer tokens: whoever holds a valid session cookie is, to the destination site, you. Browser documentation is explicit that cookies carry session identifiers and authentication state1, which is precisely why syncing them in plaintext to any third party would be reckless. The threat model treats that seriously.
| Threat scenario | What the attacker sees | Outcome |
|---|---|---|
| Sync server fully breached | Opaque XChaCha20 ciphertext | No usable cookies; no key on the server |
| Network MITM | TLS-wrapped ciphertext | Double-protected; nothing to read |
| Legal demand / subpoena | Stored ciphertext only | Nothing decryptable to hand over |
| Malicious insider | Same ciphertext as everyone | Zero-knowledge means no privileged access exists |
| Stolen, locked device | Encrypted local vault | Needs your passphrase to unlock |
| Stolen, unlocked device | Plaintext after unlock | Out of scope — protect device-level access |
The honest boundary is the last row: end-to-end encryption protects data in transit and at rest on the server, not an attacker who is already sitting at your unlocked browser. For that you rely on device login, full-disk encryption, and screen locks — defenses that live below the extension.
Free vs Pro
In short: All local cookie work is free forever. Encrypted cross-device sync is the Pro feature ($4/month or $36/year) because it is the only capability that needs server infrastructure. The crypto protecting your data is identical regardless of tier.
| Capability | Free | Pro ($4/mo or $36/yr) |
|---|---|---|
| Local cookie view / edit / delete | Yes | Yes |
| Local export (JSON / Netscape / HAR) | Yes | Yes |
| Auto-delete on tab close (Guardian) | Yes | Yes |
| Cross-device encrypted sync | No | Yes |
| Cookie history with undo (30 days) | No | Yes |
| Encrypted profile sync | No | Yes |
| Zero-knowledge architecture | n/a (local) | Yes |
Pro is only worth paying for if you use more than one device and want them to stay in sync, or if you want the safety net of cookie-history undo. A single-device, local-only user gets the entire core workflow for free. See the pricing page for the full Free / Pro / Team breakdown.
How to set up encrypted sync
- Install CookieVault (Editor, Guardian, or both) from the download page
- Open the extension popup and click “Enable sync”
- Create a Pro account with your email — this only handles billing and routing, never your key
- Choose a strong passphrase and store it in a password manager; this is the only thing that can ever decrypt your data
- Confirm the on-device key derivation runs (the popup shows “deriving key…” while Argon2id works)
- Wait for the first encrypted snapshot to upload — all selected cookies are sealed before transmission
- Install CookieVault on a second device and enter the same passphrase to derive the same key locally
- Verify the sync indicator turns green on both devices; changed records now replicate as encrypted blobs
If you ever change the passphrase, every device re-derives a new key and re-encrypts its local vault before the next push. There is no server-side re-encryption because the server has no key to use.
Audit and verifiability
In short: The encryption code is open source and reproducible-built, so the data path is verifiable today. An independent third-party audit of the crypto stack is scheduled for Q3 2026, with the report and any findings published in full.
Trust-me security is not security. Because the derivation, encryption, and sync-client code live in public MIT-licensed repositories, anyone can confirm that the key never leaves the device and that only ciphertext reaches the server. Chrome’s extension model further constrains what an extension can touch2, and cookies are read and written through the official browser cookie API1 rather than any private channel. The planned external audit is meant to add a second, independent set of eyes; we will link the report from the security page when it lands.
See also
- CookieVault Editor — the cookie editor that uses this sync engine
- CookieVault Guardian — the auto-delete extension that shares the same Pro sync
- Security — the full E2E encryption design and threat model
- Open source — MIT license, public crypto boundary, reproducible builds
- Multi-account profiles — encrypted profile snapshots that sync the same way
- Pricing — Free / Pro / Team breakdown
Footnotes
-
The browser cookie store, including session and authentication cookies, is documented by MDN at https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies. CookieVault reads and writes cookies only through the official browser cookie API. ↩ ↩2
-
The Chrome extensions cookies API and its permission model are documented at https://developer.chrome.com/docs/extensions/reference/api/cookies, which defines the only interface an extension may use to access the browser cookie store. ↩