What "Open Source Password Manager" Should Actually Mean
Every password manager claims your data is safe. That claim is unfalsifiable unless you can read the code that encrypts it. This is why "open source" matters for a password manager in a way it does not for a photo editor -- and why the label is worth interrogating rather than trusting.
The part that has to be open is the client
In a zero-knowledge design, encryption happens on your device before anything is transmitted. The server receives ciphertext and nothing else. That means the security promise lives entirely in the client: the browser extension, the mobile app, the desktop app.
A vendor who publishes their server but not their client has published the part that cannot betray you, and withheld the part that can. It is the wrong half. If you only get to audit one component, the client is the one that matters.
Your extension is already readable, so the question is whether it is honest
Here is something most people do not realise: a browser extension is not compiled to machine code. A .crx or .xpi file is a zip archive of JavaScript. Anyone can download it and read it today, minified but perfectly analysable.
So publishing an extension's source code does not reveal anything an attacker could not already obtain. What it changes is honesty: readable source, real variable names, comments explaining the reasoning, and a version history showing what changed and when.
Four questions worth asking any vendor
- Is the client published, or only the server? The client is where your secrets are handled.
- Is the cryptography in the published repository? A repository containing the UI but importing encryption from a closed package is theatre.
- Is each release tagged? Without a tag matching what is on the store, you cannot check that the published code is the code you installed.
- Is there a security policy? A project that wants scrutiny publishes how to report a flaw, and what it commits to in return.
What SandPass publishes
The SandPass extension and every line of its cryptography are public under the GPL-3.0 licence at github.com/sandprivacy/sandpass-extension. That includes:
- The full extension: popup, side panel, background service worker, and autofill.
@sandpass/crypto: key derivation, AES-256-GCM encryption, the OPAQUE client, TOTP, and password generation.@sandpass/core: the API client and vault service.
Every release is tagged, and the tag is the exact source tree the build was produced from. If you ever find a divergence between a tag and the extension you installed from the store, that is a security issue and we want to hear about it.
What SandPass does not publish, and why we say so
The backend is not public. We would rather state that plainly than let the words "open source" imply more than they do.
The reasoning: in a zero-knowledge model the server only ever receives encrypted data, and the published client is enough to verify that. Publishing server code would also prove nothing about which code actually runs in production, since you would still be trusting us. The audit that matters is the one you can perform yourself, and that audit is on the client.
We also publish what we accept
Our security policy lists the limitations we know about and have deliberately accepted, including constraints imposed by Manifest V3 that every browser-extension password manager shares, such as key material passing through chrome.storage.session.
We would rather state those ourselves than have someone find them and wonder what else went unmentioned. A vendor with nothing to disclose is usually a vendor who has not looked.
Read it before you trust it
You do not need to be a cryptographer. Open the repository, look at whether the comments explain reasoning or just restate the code, check whether releases are tagged, read the security policy. Those signals tell you a great deal about how seriously a team takes the thing they are asking you to rely on.