Why Open Source Alone Is Not a Trust Model

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

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 existing secure infrastructure exists because of open source. In fact, this service is built on open source software.

So let's 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, and increasingly, it is used as a marketing signal in situations where it does not actually reduce the trust a user must place in a company.

This distinction matters most in corporate provided privacy-focused products and corporate privacy services using open source as a marketing tool. This is the focus of this article.

What People Think "Open Source" Means

When users see a company advertise:

"Our client is open source"
"Our software is fully open source"

they often infer several things that are not guaranteed:

  • That all of 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 source
  • That nothing extra was added at build time
  • That the server-side software behaves the same way
  • That no additional logging or instrumentation exists

In other words, users are led to believe that open source equals verifiable trust.

It does not.

Source Code Is Not the Same as Running Code

Open source describes availability of source code, not control over execution.

Once software is:

  • compiled by someone else,
  • distributed 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 source code does not eliminate that trust.

Why "Just Audit the Code" Is Not Realistic

A common response is:

"But anyone can review the code."

In practice:

  • Almost no users do and maybe nobody has
  • Reviews are often paid for
  • Most reviewers are rushed
  • Reviews are rarely adversarial
  • Reviewers assume good intent
  • Behavior that doesn't break functionality is rarely questioned
  • This still doesn't prove that the compiled binary or running server code is the same as the published source

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

Two Open Source Functions That Look the Same, But Aren'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 does exactly what it claims.

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 tests and appear normal.

And yet, the behavior differs:

  • Version A: safe, writes only derived data
  • Version B: unsafe, writes raw input

This example is blatant and most should catch it, but it can be subtle enough that even experienced programmers will miss it.

Open source does not:

  • force adversarial review,
  • prevent subtle side effects,
  • or guarantee behavior.

It only makes review possible, not necessarily effective. In fact, many popular widely used non-commercial open source products have gone years (and some, decades) before someone noticed a vulnerability.

The Trust Gap Widens with Binaries and Servers

The situation becomes more complex when:

  • users install precompiled clients, and
  • services run on servers they do not control.

In these cases:

  • Users cannot verify builds
  • Cannot inspect runtime behavior
  • Cannot see configuration
  • Cannot observe operational logging

Even a fully honest provider cannot prove to users:

  • what exact code is running,
  • how it is configured,
  • or what is being observed at runtime.

This is not deception, it is simply the reality of remote services.

Configuration Is Part of the Product

Even for fully open source services, configuration changes everything:

  • logging scope
  • metadata exposure
  • access segmentation
  • retention policies
  • attack surface

Two installations of the 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

Because it sounds like proof.

It suggests:

  • ethics
  • transparency
  • safety
  • trustworthiness

Historically, that reputation was earned. But today, publishing a repository is easy; running a privacy-respecting service is hard.

When "open source" is used as a primary selling point, it often substitutes for deeper questions that actually determine privacy outcomes.

Better Questions for Users to Ask

Instead of asking:

"Is it open source?"

Ask:

  • What metadata exists by design?
  • What logs are unavoidable?
  • What happens when credentials are compromised?
  • What does the provider never see?
  • What assumptions am I being asked to trust?

These questions are meaningful whether the software a company is running is open source or not.

Open source as a label is not meaningless, but it is incomplete.

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

Trust comes from:

  • architecture
  • minimization
  • clear threat models
  • operational discipline
  • operational transparency

...not labels.

When evaluating privacy services, "open source" should be one input, not a deciding factor. 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.

← Back to Security Documentation