What an Open-Source Client and a Bug Bounty Actually Establish

Publishing the client source tells you what the software on your device is designed to do; running a bug bounty tells you the provider would rather hear about flaws than not hear about them. Both are genuine positives, and both are about the half of the system you can inspect. Neither is evidence about the half you cannot: what the exit server records, for how long, and who can ask for it.

That asymmetry is worth holding onto, because these two signals are frequently presented as answers to the logging question, and structurally they cannot be.

What “open source” covers in practice

The client application, usually. The app you install: how it builds the tunnel, what it sends home, what it does to your system’s configuration, whether it fails open or closed. This is the part where published code is most useful, because it is the part running with elevated privileges on your machine.

The protocol, almost always — and independently of the provider. The major tunnel protocols in use as of writing are public specifications with public implementations, so a provider “using open-source encryption” is describing the industry norm rather than a decision it made. That is one reason protocol choice matters less than you think.

Server-side software, sometimes. Some providers publish configuration or management tooling. This is more meaningful than a published client, and rarer.

What is running on the machine right now, never. This is the hard boundary. Source code describes an intended behaviour. It cannot establish that the binary serving your connection was built from it, has not been altered, and is configured the way the repository suggests. A published server stack narrows what is plausible; it does not verify what is deployed.

So the honest reading is: open source moves the client from “trust the vendor” to “trust the vendor plus anyone who checked”, and leaves the server side exactly where it was — which is where what a no-logs claim is worth leaves it too.

Availability is not review

Published code that nobody reads provides the same assurance as unpublished code, plus a reputational cost for obvious misbehaviour. The useful question is whether anyone outside the company has actually engaged with it. Things that indicate they have:

• external contributors in the commit history who are not employees
• security findings that were reported, fixed, and described in public
• issues filed by strangers that received substantive answers
• packaging by third parties, such as distribution maintainers, who have to read the build to package it

Things that indicate very little: a repository that mirrors releases with no history, a licence file, or the word “transparent” on a marketing page.

The build question

Between the source and the software you are running sits a build pipeline and a distribution channel. If you install from an app store, you receive a binary someone else compiled and signed.

Reproducible builds are the mechanism that closes this gap: the build is specified precisely enough that an independent party can compile the same source and obtain a byte-identical result, which makes tampering in the pipeline detectable. Few consumer applications achieve this, and a provider that does has done something substantially harder than publishing a repository.

Without it, the chain of trust includes the build machine, the signing key, and the store — three more parties in an arrangement that already has several, as the parties a no-logs promise cannot speak for describes.

What a bug bounty establishes, and what its scope reveals

The existence of a programme is a weak positive: it means someone decided that paying for reports beats discovering problems by press coverage. What is actually informative is the fine print.

Scope. Read what is excluded. A programme covering the marketing website and excluding the client and the server infrastructure is a support cost, not a security posture. A programme that explicitly invites testing of the tunnel and the authentication path is a different statement.

Safe harbour. Language committing the company not to pursue good-faith researchers is what makes a programme usable. Without it, the invitation is theoretical, because responsible disclosure carries legal risk for the researcher.

Evidence of payouts. A published hall of fame, dated and specific, or researchers’ own write-ups. A programme with no visible history may be new or may be decorative, and from outside those look identical.

Whether reports become public. Programmes that permit publication after a fix generate a record you can read. Programmes that require permanent silence generate a record only the company can see.

The strongest signal in this category

Not the repository and not the programme, but how the provider handled a real problem: a vulnerability found in its own software, an incident on its own infrastructure, a mistake in its own release. Specifically, whether it disclosed before it was forced to, described the mechanism rather than the sentiment, said what was and was not affected, and shipped the fix.

Providers with a long history and no disclosed incident of any kind are not demonstrating that nothing happened. Software of this complexity has flaws; a public record of finding and fixing them is a sign of an organisation that looks.

What none of this reaches

The claim most buyers care about — that connection records are not kept — is not verifiable by any of these means, because it is a claim about operational conduct inside a building you cannot enter, and code you can read cannot describe what someone chose to configure this morning. Assurance for that class of claim comes from independent examination of the running environment, with all the scope limits that implies, and from architectures that make the data absent rather than unlogged. That distinction is the whole subject of cannot versus will not.

How to weigh it

Roughly, in descending order of what it tells you: a published server stack with reproducible client builds and a public incident history; a published client with real outside participation; a bounty programme with broad scope and safe harbour; a repository nobody reads; a marketing page using the word “open”.

None of these is a reason to pick a provider on its own, and all of them are better evidence than the numbers on a comparison table, in the sense that server and country counts are not evidence of anything at all. Use them to narrow a shortlist, then go back to the threat model and ask whether the difference between two shortlisted providers matters to the observer you actually named.