Why Commercial Open Source Is Not a Trust Model

Open source software is one of the most important developments in modern computing. It enables independent review, long-term survivability, and community-driven improvement. Much of the secure infrastructure we rely on exists because of open source. This service is built on open source software.

So let us be clear at the start:

Open source is good. Open source is valuable. Open source is necessary.

But it is not, by itself, a trust model. Increasingly it is used as a marketing tool in situations where it does not reduce the trust a user must place in a company at all. That misuse, in corporate, privacy-focused services that wave open source as a banner, is the focus of this article.

What People Think "Open Source" Means

When a company advertises that its client is open source, or that its software is fully open source, users tend to read a whole chain of guarantees into those few words that the words do not actually carry. They assume the experts have reviewed it, that the software behaves exactly as the published code suggests, that the compiled app they installed was built from that very source with nothing added at build time, that the server-side software behaves the same way, and that no extra logging or instrumentation is quietly running alongside it.

In other words, users are led to read open source as verifiable trust. It is not.

Source Code Is Not the Same as Running Code

Open source describes the availability of source code, not control over execution. The moment software is compiled by someone else, distributed to you as a binary, or run on servers you do not control, you are trusting their build system, their compiler, their deployment process, their configuration, and their operational discipline. Publishing the source code eliminates none of that.

Usually, Only the Client Is Open

There is a more specific problem with commercial, privacy-focused email services that wave the open source banner: in almost every case, it is only the client that is open source. The running server architecture and its configuration, the part that actually receives your mail, handles your account, and decides what is logged and retained, is not published and cannot be inspected. That is the part that matters most, and it is the part you are simply asked to take on faith.

Thunderbird makes the point neatly. Thunderbird is fully open source, and it is excellent, but its being open source does not mean that you can now trust every single email service on the Internet. An open client tells you about the client. It tells you nothing about the server on the other end. When a provider points at its open source client as evidence of its privacy, it is answering a question nobody needed to ask while leaving the real one, what happens on its servers, untouched.

And even the open client is not above suspicion. Every email client ever written, Thunderbird very much included, has shipped vulnerabilities that had to be patched, and more will surface in time.

Why "Just Audit the Code" Is Not Realistic

The common response is that anyone can review the code. In practice almost no one does, and for a small commercial client it is entirely possible that no one ever has. When reviews do happen they are often paid for, and paid reviews are rarely adversarial; behavior that does not break functionality is rarely questioned. None of it proves that the compiled binary on your device, or the code actually running on the server, matches the published source.

There is also a simpler question hiding here: did you personally read the entire client, understand it, and build it yourself? If not, you are trusting that somebody else did, and that the binary you actually installed was built from that source with nothing slipped in along the way.

Many non-commercial open source packages with hundreds of millions of installs have gone years, and in some cases decades, with vulnerabilities nobody noticed. A small commercial offering with an open source client will be reviewed far less than that, which raises an awkward question: have you ever actually seen such a provider publish a vulnerability and a fix for its own client? If not, it is worth asking how one small company manages to produce flawless software that nobody else on the Internet can, especially while building on the very libraries that have had vulnerabilities of their own.

Harmful behavior also does not need to be obvious to be effective. To illustrate, consider the following example.

Two open source functions that appear to function similarly, but don't

Below are two short C functions. They are intentionally written to look boring, generic, and low-level. They have nearly identical structure, use the same helper functions, produce the same visible results, and pass the same tests. Only one of them runs safely.

Version A

#include <stdint.h>
#include <string.h>
#include <unistd.h>

static uint32_t m(const uint8_t *p, size_t n)
{
    uint32_t v = 0x9e3779b1;
    for (size_t i = 0; i < n; i++)
        v ^= (v << 5) + (v >> 2) + p[i];
    return v;
}

static void d(const char *s, uint8_t o[32])
{
    uint32_t v = m((const uint8_t *)s, strlen(s));
    for (int i = 0; i < 32; i++)
        o[i] = (v >> ((i & 3) * 8)) & 0xff;
}

static int q(const uint8_t k[32], const char *p)
{
    /* placeholder for opaque operation */
    (void)k;
    (void)p;
    return 0;
}

int fn(const char *a, const char *b)
{
    uint8_t k[32];
    uint32_t v;

    if (!a || !b)
        return -1;

    v = m((const uint8_t *)a, strlen(a));
    d(a, k);
    write(3, &v, sizeof(v));
    return q(k, b);
}

Version B

#include <stdint.h>
#include <string.h>
#include <unistd.h>

static uint32_t m(const uint8_t *p, size_t n)
{
    uint32_t v = 0x9e3779b1;
    for (size_t i = 0; i < n; i++)
        v ^= (v << 5) + (v >> 2) + p[i];
    return v;
}

static void d(const char *s, uint8_t o[32])
{
    uint32_t v = m((const uint8_t *)s, strlen(s));
    for (int i = 0; i < 32; i++)
        o[i] = (v >> ((i & 3) * 8)) & 0xff;
}

static int q(const uint8_t k[32], const char *p)
{
    (void)k;
    (void)p;
    return 0;
}

int fn(const char *a, const char *b)
{
    uint8_t k[32];
    uint32_t v;

    if (!a || !b)
        return -1;

    v = m((const uint8_t *)a, strlen(a));
    d(a, k);
    write(3, a, strlen(a) < sizeof(v) ? strlen(a) : sizeof(v));
    return q(k, b);
}

Why This Matters (Without Needing to Read C)

Both functions pass their tests and look entirely normal, and yet they behave differently. Version A is safe: it writes only derived data. Version B is not: it writes the raw input. Buried in the rest of a codebase, most people would never notice what B is doing.

Open source does not force adversarial review, prevent subtle side effects, or guarantee behavior. It only makes review possible, not necessarily effective. It is worth repeating that many popular, widely used non-commercial open source products went years, and some went decades, before anyone noticed a vulnerability. That Billy Joe Jim Bob's Discount Email, Bridal Boutique, and Truck Wash™ custom client source code is not going to be anywhere close to as well reviewed.

The Trust Gap Widens with Binaries and Servers

The situation gets worse once users install precompiled clients and the service itself runs on servers nobody outside the company can see. Users cannot verify the builds, cannot inspect runtime behavior, cannot see the configuration, and cannot observe what is being logged. Even a completely honest provider cannot prove to its users what exact code is running, how it is configured, or what is being watched at runtime. This is not deception. It is simply the reality of remote services.

Configuration Is Part of the Product

Even for a fully open source service, configuration changes everything: how much is logged, how much metadata is exposed, how access is segmented, how long data is retained, and how large the attack surface becomes. Two installations of the very same software can behave radically differently. At that point, open source describes the ingredients, not the meal.

Why Open Source Is Used as a Marketing Signal

It is used because it sounds like proof. It suggests ethics, transparency, safety, and trustworthiness. Historically that reputation was earned, but today publishing a repository is easy, while running a privacy-respecting service is hard. When open source becomes the primary selling point, it tends to stand in for the deeper questions that actually determine privacy outcomes.

Open Source Is a Label, Not a Guarantee

Open source improves the potential for trust. It does not create trust by itself.

Trust comes from architecture, from data minimization, from a clear threat model, and from operational discipline and transparency. It does not come from labels. When you evaluate a privacy service, open source should be one input, not the deciding factor.

This is also why commercial open source privacy email clients, on their own, can never make a system trustless. Trustlessness is an architectural property, not a licensing one. It comes from keeping the provider out of the cryptography path entirely, so that its honesty, its build pipeline, and its server configuration simply do not matter. A published repository asks you to trust that the running system matches it. An architecture where the provider never generates or holds your private key, and never sits in the decryption path, asks you to trust nothing at all. We cover that distinction in The Truth About Zero Knowledge / Zero Trust / Zero Access and in our look at walled garden email services.

If this article causes even a moment of pause, a shift from "they say it's open source" to "what am I actually trusting?", then it has done its job.