Open source
TL;DR: CookieVault Editor and Guardian are MIT-licensed open-source browser extensions. Each has its own public GitHub repository, including the shared client code and cryptography needed to build and audit it. The hosted sync service remains proprietary.
CookieVault is open source at the extension layer: both browser extensions — Editor and Guardian — are published on GitHub under the MIT license, including the shared client packages and the on-device encryption code they need to build. Publishing that cryptographic boundary lets anyone verify that cookie plaintext is encrypted before it reaches the hosted sync service, which remains proprietary.
What is published
In short: Both browser-extension clients and their required shared packages are public. The hosted sync service, internal documentation, and private operational material are not.
| Repository | What it contains | License |
|---|---|---|
| CookieVault Editor | Cookie manager extension and required shared client packages | MIT |
| CookieVault Guardian | Auto-delete extension and required shared client packages | MIT |
The hosted sync service is deliberately kept outside these repositories. It stores ciphertext produced by the public client-side cryptographic implementation; the server does not need access to cookie plaintext.
Why open source matters here
In short: A cookie extension has privileged access to your session tokens. Open source plus reproducible builds turns “trust us” into “verify us” — the only honest posture for a tool with that much access.
Three reasons transparency is non-negotiable for this category:
- Privileged access — an extension with the cookies permission can read every session token in your browser. You should be able to see exactly what it does with that access.
- The provenance gap — EditThisCookie’s source was visible, but the post-transfer store binary was not verifiable against it. Reproducible builds close that gap.
- Supply-chain resilience — public code and signed, reproducible releases make a silent malicious update detectable rather than invisible.
Reproducible builds
In short: Each Chrome Web Store release is tagged in Git, and the store binary is byte-identical to the CI artifact for that tag. Verify with a SHA-256 comparison.
The verification flow is four steps:
- Note the version of the extension you have installed (or want to verify)
- Find the matching tagged release on GitHub and download its
SHA256SUMS - Download the CRX (from the store or the release) and run
sha256sumon it - Compare the two checksums — a match proves the binary is the published source
This procedure means you never have to take our word for what the extension does; the math does the trusting.
How to contribute
In short: Read CONTRIBUTING.md, discuss before large PRs, sign commits, use Conventional Commits. No CLA required.
- Read
CONTRIBUTING.mdin the relevant repository first - Open a discussion before large or architectural changes
- Sign your commits so authorship is verifiable
- Use Conventional Commits (
feat:,fix:,docs:, etc.) - No CLA — we trust the MIT license and do not require contributor agreements
- Good first issues are labeled in each repository
License
The Editor and Guardian repositories use the MIT license. You may read, fork, modify, build, and redistribute their code under those terms. The CookieVault name and logos are not granted under the MIT license and remain protected trademarks.
See also
- Security — the encryption design you can audit
- About — who maintains the code and how it is funded
- Download — install from a store or build from source
- No-sale pledge — the data commitment behind the code
- Encrypted cloud sync — the crypto boundary in detail