Auditability as proof: why a privacy tool must be readable

A privacy tool makes a claim. "Your data stays local." "Nothing leaves your machine." "We never see your prompts." These are good claims. They are also impossible to confirm when the software arrives as a sealed binary. You can read the marketing page, trust the logo, and install the thing, but you have taken the promise on faith. Faith is a strange basis for a security decision.

The fix is not a better promise. It is the ability to check.

A closed promise is just a promise

When a vendor ships closed software, the gap between what it says and what it does is invisible to you. A binary that claims to run locally might still phone home on launch, batch your data overnight, or open a connection the first time you touch a feature you rarely use. You would not know. The behaviour lives inside code you are not allowed to read.

This is not a claim that every closed tool is dishonest. Most are not. The problem is structural. You have no way to tell the honest ones from the rest, because the only evidence that would settle the question is the source, and the source is the one thing you cannot see. A promise you cannot test is not a security control. It is a brand asset.

Security-minded buyers already know this in other contexts. You would not accept "trust us, the encryption is fine" from a vendor who refused to name the algorithm. Privacy behaviour deserves the same scrutiny. If the claim is "no network at runtime," the natural follow-up is "show me."

What auditability actually buys you

Readable source answers "show me" by default. The license matters, but the real value is the inspection it permits. A few concrete things you get:

• Independent review. You do not have to read every line yourself. Anyone with the skill can, and in an active project, people do. A hidden network call is the kind of thing a contributor or a curious user notices and files.
• No silent network calls. When the code is public, claims about what crosses the network become checkable against reality. You can search for the functions that open sockets, make HTTP requests, or resolve domains, and see exactly when they run.
• Reproducible behaviour. Open code plus a clear build means you can confirm that the binary you run matches the source you read. Behaviour stops being a mystery and becomes something you can predict, test, and explain to your own security team.

Auditability also changes the incentive for the vendor. When anyone can look, cutting a corner is a corner that someone will eventually see. The discipline of building in the open tends to produce software that is honest about what it does, because dishonesty has a much shorter shelf life.

You do not have to read every line

A common objection: most buyers are not developers, so what good is source code they cannot parse? Plenty of good, as it turns out. Auditability is a property the whole ecosystem benefits from, not only the people doing the audit. You can gauge a project's health with signals that need no coding:

• An active community. Look at recent commits, the pace of releases, and whether maintainers respond to questions. A project that moves is a project that is being watched.
• A public issue tracker. Open problems discussed in the open are a sign of a healthy process. A tracker with real bugs, real answers, and real fixes beats a flawless-looking page with nothing behind it.
• A clear build. Documentation that lets a technical person compile the tool and get the same result tells you the "show me" path is real, not theater.
• Tests that assert the privacy claim. The strongest projects encode their promises as checks. A test that fails if the app makes a network request turns "runs locally" from a sentence into something the codebase enforces on every change.

You can also borrow trust. Hand the repository to a security consultant, an engineer on your team, or a community you already rely on. The point is that the verification can be done by someone, and that you get to choose who.

Why Velum ships readable source

Velum's engine is source-available via npm under the PolyForm Noncommercial License. That is deliberately not the same as open source: PolyForm restricts commercial use, which fails the Open Source Definition, and we would rather name the licence accurately than borrow a word that sounds better. What it gives you is the part that matters here: the ability to read the code and check the central claim, that it runs locally with no network calls at runtime, instead of taking it on faith. Personal and noncommercial use is free; commercial use needs a paid licence.

We think that is the only honest way to ship a privacy tool. A product whose entire value is keeping your data in your hands has no business asking you to take that on trust. Readable source is not a giveaway or a marketing flourish for us. It is the proof that backs the promise, and it keeps us accountable to the same standard we ask of everyone else.

A privacy tool earns trust by being inspectable. Everything else is a slogan.

If you want to see what that looks like in practice, read about Velum or request a demo and bring your hardest questions.