Open source
TL;DR: CookieVault is MIT-licensed open source. The Editor extension, Guardian extension, sync server, and this website all live on GitHub with reproducible builds, so you can verify the store binary against a tagged commit. Contributions, audits, and forks are welcome.
CookieVault is an open-source project: every component — the Editor and Guardian extensions, the end-to-end encrypted sync server, and this marketing site — is published on GitHub under the MIT license. The extension binaries on the Chrome Web Store are reproducible-built from tagged GitHub releases, which means the code you can read is provably the code that runs. This is the structural answer to the trust problem that took down EditThisCookie.
What is published
In short: Everything. There is no closed core. The cryptographic boundary that protects your cookies is fully auditable.
| Repository | What it contains | License |
|---|---|---|
| Editor | The cookie manager extension | MIT |
| Guardian | The auto-delete extension | MIT |
| Sync | The end-to-end encrypted sync server | MIT |
| Web | This marketing site (Astro) | MIT |
| Docs | Technical documentation | MIT |
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
MIT, everywhere. No CLA, no relicensing of contributions, no proprietary fork. You may read, fork, modify, self-host, and redistribute under the MIT terms.
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