How We Secure Cuewise's Releases
Cuewise lives in your new tab and quietly updates itself. The most important promise we can keep is that every update is exactly the code we reviewed and built — never something slipped in along the way. Here's how we make that true.
What We're Protecting
Your data already stays on your device — your goals, your focus, your settings never touch our servers. That's our privacy promise, and it hasn't changed. This post is about the other half of the story: the integrity of the extension itself.
Cuewise updates automatically inside your browser, and that convenience is exactly the thing most worth protecting. The real risk isn't someone reading your to-do list — it's a bad actor slipping tampered code into an update on its way to you. So we've built our release pipeline around a single promise: every version you receive is exactly the code we reviewed and built, and you never have to take that on faith.
The Path Every Update Takes
Before a single line of new code reaches your browser, it travels through a series of gates — each enforced automatically, not by anyone remembering to do the right thing:
It starts with review. Every change is a pull request that has to pass our automated tests and checks before it can join main — the one branch we ever release from. That branch is locked: no force-pushing, no editing it directly, no shipping something that didn't pass. If a change didn't earn its way in, it doesn't go out.
When it's time to publish, the keys to the Chrome Web Store come into play — and those are the keys to the kingdom. They live in a sealed vault that only the release branch can open, and only after a human approves the release and a short cooldown passes. Just as important, the step that actually holds those keys runs none of our third-party code: it's a tiny, dependency-free script, so even a compromised library can never reach them.
And while a release is being built, the build machine is kept on a short leash. It can talk to a tiny list of services — our package registry and GitHub — and nothing else; every other connection is blocked outright. Modern software leans on hundreds of open-source packages, so if one were ever tampered with, it would have nowhere to send data and no way to pull in extra code during our build.
Signed, So You Can Verify It
When a release is finished, we don't just ask you to trust it — we give you a way to check. Every published build is cryptographically signed with a provenance attestation that ties the exact file to the exact commit and build that produced it. Anyone can verify it:
gh attestation verify cuewise-extension-<version>.zip --repo kYem/cuewiseIf a file's signature doesn't trace back to our pipeline, it didn't come from us. We also keep a constant watch on everything Cuewise depends on: we get automatic alerts — and ready-made fixes — the moment a known vulnerability appears in a dependency, and we deliberately wait two weeks before adopting brand-new package versions, long enough for a malicious release to be caught and pulled before it could ever reach you.
Don't Take Our Word for It
None of this is just words: Cuewise is open source, so you're welcome to read the pipeline yourself and hold us to every claim on this page.
And if you ever spot a security issue, please report it privately through GitHub's security advisories rather than a public issue — we'll get back to you quickly.
Private by Design, Secure by Default
Calm, mindful productivity you can actually trust.