← All postsSeptember 2, 2026

Open-source voting is necessary — and still not enough. Here's the rest.

LA County spent a decade building the world's most transparent voting system — open-source, publicly owned, independently auditable. Switzerland did the same thing. Researchers still found a hidden backdoor. Here's what both cases missed.

It is August 21, 2018, and a California state official is standing in front of a microphone about to say something that has never been said before in the state's history: Los Angeles County has just had its vote-tally system certified — and for the first time, the software counting the votes belongs to the public.

Not a vendor. Not a private company protected by trade-secret law. The public.

The system is called VSAP — Voting Solutions for All People. It took years and tens of millions of dollars to build. It was designed from scratch to serve the largest voting jurisdiction in the United States, replacing aging proprietary machines. And its source code — the actual instructions telling the computer how to count your vote — was published for anyone to read.

This is, genuinely, a milestone. And it is still not enough.

That gap — between open code and verified count — is what this post is about.

Why secret source code was always the wrong answer

To understand why VSAP matters, you have to understand what it replaced.

For decades, the software counting American votes was a trade secret. Vendors argued their code was proprietary intellectual property. Election officials had to take their word that the machines worked correctly. Researchers who obtained machines through other means — like the Princeton team that picked up a Diebold AccuVote-TS and spent a few weeks with it in 2006 — discovered they could install vote-stealing code in under a minute that would spread machine to machine and alter every internal log to stay consistent. The machine would report the tampered tally with perfect confidence.

The code was secret. The tampering was invisible.

Coffee County, Georgia in 2021 showed the other edge of that same sword: keeping code secret doesn't keep it safe. A forensics team was admitted to the elections office and walked out with a copy of the entire Dominion voting system — the Election Management System, the poll pads, the ballot-marking devices, the scanner, everything. Secrecy as a security strategy is only as strong as the most cooperative insider in the room.

Open-source code breaks both of those failure modes. You cannot hide a vote-stealing virus in code that everyone can read. You don't need to steal the secret because there isn't one.

But the moment you publish the source, you move the question. The question is no longer "what does the code say?" The question becomes: "Is the code that's actually running on election night the same code that's sitting on GitHub?"

And that question turns out to be very hard to answer.

The Swiss lesson: open code, hidden flaw

In 2019, Swiss Post and its Spanish vendor Scytl did something that looked like the gold standard of transparency. They published the full source code of Switzerland's internet voting system ahead of planned use in binding federal votes. Independent researchers could read every line.

Researchers Sarah Jamie Lewis, Olivier Pereira, and Vanessa Teague took them up on it. What they found inside the cryptography was not a typo. It was not a careless bug. It was a trapdoor — a mathematical structure buried in the mixnet's shuffle proof that allowed whoever held certain secret values to generate a verification transcript that would pass every check while having altered the votes underneath it.

The system claimed to offer "universal verifiability." A valid-looking proof would confirm the shuffle was correct. But if you knew the trapdoor values, you could make that proof pass for a shuffle that wasn't correct at all.

They called their report Ceci n'est pas une preuve — "This is not a proof." Swiss Post and Scytl acknowledged the finding. Swiss authorities suspended the system. A decade of work, a full public code release — and the flaw was still there, invisible until outside cryptographers dug into the math.

Here is the lesson that does not appear in the press release: open source code is necessary because it makes independent inspection possible. It is not sufficient because inspection still has to actually happen, by people qualified to find what they're looking for, and then the fixes have to be verifiably applied.

Publishing the code is the beginning of the story, not the end.

The reproducibility problem: from code to running machine

Let's make this concrete. Imagine you are a city council member in Los Angeles County. You can read the VSAP source code. You find it clean. You are satisfied the code is correct.

Election night arrives. Somewhere in a warehouse, a machine wakes up and starts counting ballots.

How do you know the machine is running the code you read?

The gap between "source code" and "running software" is called the build process. Source code is human-readable text. A computer runs compiled binary — machine instructions that a compiler produces from that text. The compilation process is not automatic, obvious, or verifiable by eye. It involves choices: which compiler version, which flags, which dependencies, in what order.

If two people compile the same source code using different compilers, they often produce different binaries. And if the binaries are different, you cannot tell by looking at them whether the difference is innocent (a different optimization setting) or malicious (an added instruction).

This is not a theoretical concern. It was described with lethal precision in Ken Thompson's 1984 Turing Award lecture, "Reflections on Trusting Trust." Thompson showed you could insert a backdoor into a compiler that would invisibly add malicious code to any program it compiled — including future versions of the compiler itself — leaving no trace in any source code anyone could read.

The solution, developed over the past decade in the free-software world, is called reproducible builds. The idea: if a build process is deterministic — same inputs, same outputs, every time — then any independent party can compile the same source and compare the binary fingerprint against what is actually installed on the machine. If the fingerprints match, the machine is running what the code says.

If they don't match, something changed between the code and the machine. That's not a philosophical concern. That's a security failure.

We covered this in more depth in our post on reproducible builds. The short version: without them, "open source" means "you can read the recipe." It does not mean "what came out of the oven is what the recipe describes."

VSAP's open-source architecture is a genuine step forward. But open source without a documented, reproducible build process leaves a gap that no audit of the source code can close.

Attestation: proving the machine is the machine

Reproducible builds tell you whether a binary matches the source. Attestation is the step that ties a specific machine to a specific verified binary at a specific moment in time.

Think of it as a chain of signatures. The jurisdiction certifies a binary. The binary is cryptographically signed. When the machine boots on election day, it measures its own software state and generates a signed report — a "measurement" — that can be checked against the certified value. If anything has been modified, the measurement won't match. This is not exotic; it's already how a modern smartphone protects its boot process.

In current election-system practice, the equivalent is a hash — a digital fingerprint — that is supposed to be checked against the certified version before deployment. But "supposed to be" is doing heavy lifting in that sentence. The checks are often manual, infrequent, or trust a chain of custody that may itself have gaps.

Consider what happened in Coffee County: the entire system's software was copied and distributed by people with legitimate physical access to the office. The systems passed their pre-election checks. A hash comparison after the fact would tell you whether the binary changed on the machine that stayed in the office. It would not tell you what was done with the copy that left.

Attestation does not solve the insider-threat problem alone. But it does mean that every machine, at boot, can be asked to prove what it's running — and the answer can be checked against a public registry before a single vote is cast.

Chain of custody: the physical layer that code can't replace

Here is what a fully auditable open-source system looks like at 2 a.m. on election night: a memory card comes out of a tabulator, goes into a sealed bag signed by observers from multiple parties, is logged in a ledger, transported by two people who are not from the same party, and arrives at a central facility where its seal is checked before the data is read.

And here is what it looks like when that chain breaks: the Austrian Constitutional Court in 2016 voided a presidential runoff — not because fraud was found, but because in multiple districts, postal ballots had been opened and counted by unauthorized people outside the legally required window, without the required witnesses. Roughly 77,000 votes were affected by proven procedural violations, which exceeded the 30,000-vote winning margin. The court found no fraud. It annulled the election anyway, because the procedures that would have made fraud detectable had not been followed — and an undetected manipulation is indistinguishable from an undetected manipulation.

The same logic applies to a voting machine with perfect open-source code and a reproducible build. If the memory card containing results is handled by a single person with no witnesses before it reaches the canvass, the chain of custody is broken. The code's correctness is irrelevant. You cannot prove the card holds the output the machine produced.

Physical chain of custody is not a legacy procedure that technology replaces. It is the anchor that connects the software world to the physical world. Without it, a perfect cryptographic proof of the count floats free of any physical ballot anyone can recheck.

Audits: the check that closes the loop

Germany's Federal Constitutional Court put the principle as plainly as any court has: an election's essential steps must be "examinable by the citizen reliably and without any specialist knowledge." The Court said this in 2009, voiding the use of Nedap voting computers in the 2005 federal election. The machines stored votes only in electronic memory. No independently verifiable record. No check a non-expert could perform. The court found that unconstitutional — regardless of whether the machines had ever malfunctioned.

Open source code partially satisfies this requirement for technically literate citizens. A cryptographically verifiable audit satisfies it for everyone.

Georgia's 2020 statewide hand-count audit — roughly 5 million presidential ballots, examined by 159 counties in under six days — confirmed the machine tally to within about a tenth of a percent. That is a meaningful result. A paper ballot the voter marked by hand, counted by a person the voter could in principle watch, checked against a machine total: that is a chain an ordinary citizen can trace without a cryptography degree.

But even that chain has limits. Colorado ran the first statewide risk-limiting audit in 2017, providing statistical confidence that the reported outcome was correct. A risk-limiting audit is more rigorous than a fixed-percentage check: it samples more ballots in close races, fewer in blowouts, and delivers a defined probability that a wrong outcome would have been caught. Colorado has continued tightening its risk limit. That is the direction of travel.

The lesson from both: an audit only works if there is something trustworthy to audit against. A paper ballot a voter marked and could inspect is trustworthy. A QR code the voter cannot read — which a federal court found in Curling v. Raffensperger "does not provide a verifiable and auditable ballot record" because the code itself tabulates the vote and the voter cannot verify it — is not an audit trail. It is a machine trusting itself.

Open source + reproducible builds + attestation + chain of custody converges on this: a durable, human-readable record the voter personally verified, which any independent party can recount, and whose path from the voter's hand to the final tally is documented at every step by multiple parties with conflicting interests.

The checklist nobody has fully completed

Here is the actual list of what "open source" gives you and what it doesn't:

What open source gives you:

The ability for qualified experts to read the code and find bugs or backdoors
The ability to compare the stated logic of the count against what it should do
Removal of trade-secret arguments that block security research
A foundation for reproducible builds and community audit

What open source does not give you:

Proof that the running binary matches the source (requires reproducible builds)
Proof that a specific machine is running the certified binary (requires attestation)
Proof that results were not altered between the machine and the canvass (requires chain of custody)
Proof that the count reflects the paper ballots in the box (requires audits against a voter-verified paper record)

Switzerland published its source and still hid a trapdoor — not because publication was useless, but because publication without sustained, expert, adversarial review left the trap unsprung for too long. Los Angeles County published its source and deserves credit. The question for the next decade is whether every county that uses VSAP can check, independently, that the binary on each machine matches what the source says, and that every memory card traveled an unbroken chain from machine to canvass.

Transparency is not a single moment. It is a process that runs from the source code repository to the sealed bag on the table at 2 a.m.

What would actually make this checkable

If you wanted to build a system where any independent party — not just an official, not just a vendor — could verify the entire chain from code to certified result, it would look like this:

One: Source code published in a versioned, immutable repository with a cryptographic hash for every release.

Two: A documented, scripted build process that any party can reproduce, producing a binary whose hash matches the certified hash.

Three: Pre-election attestation: every machine, before it processes a ballot, generates a signed measurement of its own software state. That measurement is checked against the certified hash and logged publicly.

Four: Voter-verified paper records — ballots the voter personally inspected that reflect human-readable choices, not barcodes the voter cannot read.

Five: Routine risk-limiting audits that sample paper ballots against machine tallies, sized to the margin of the race, conducted by observers from multiple parties, with results published at the precinct level.

Six: Machine-readable, precinct-level results published the moment they are certified — not after the fact, not in a format requiring a freedom-of-information request, but in a .csv or .xml file anyone can download and reconcile against the precinct tapes.

None of these steps is exotic. All of them exist somewhere in current practice. No jurisdiction has implemented all of them end to end, with independent verification at each link.

That is the gap. Not "open source vs. closed source." The gap is between publishing the code and making the entire chain — from source to machine to ballot to tally — independently verifiable by anyone who wants to check.

Until that chain is complete and public, "open source" is a necessary improvement. It is not a finished answer.

See how this gap appears across jurisdictions worldwide →

Read the 2-minute version of why open source is necessary but not sufficient →

Explore the specific gaps in reproducible builds and attestation →

Sources

See all posts Explore the gaps