← All postsJune 22, 2026

Open-source voting: necessity, not hype

The software counting your vote is a secret — and the officials asking you to trust it have no way to prove it's doing what they say.

On January 7, 2021 — the morning after the Capitol had been breached — a computer-forensics team walked into the Coffee County, Georgia elections office and left with a copy of everything. The Election Management System. The ballot-marking devices. The statewide Dominion software. All of it, burned onto drives and taken out the door.

The voting system in Coffee County had been treated as a secret worth protecting. Hide the code, secure the machines, trust the officials. That strategy collapsed the moment someone with a key decided the rules didn't apply to them.

Secrecy is not security. Coffee County proved it. But there's a deeper lesson buried underneath the headline — and it's one that applies whether or not anyone ever breaks in.

The thing about secret code is that no one can check it

When a voting machine runs proprietary software, the only people who can read that code are the vendor and, sometimes, a small team of government-approved testers who sign nondisclosure agreements. You can't read it. Your county commissioner can't read it. The Secretary of State who certifies it probably can't read it.

What everyone gets instead is a promise: we tested it, it's fine, trust us.

That's not a security model. That's a business arrangement.

The Princeton researchers who took apart a Diebold AccuVote-TS machine in 2006 — the same kind of touchscreen deployed across millions of American voters — found that the software could be subverted in about a minute with a memory card. Not just tampered with: subverted in a way that rewrote every log and counter to stay internally consistent, leaving no detectable trace. The code could even spread itself to other machines during normal election-night transfers. The researchers published this because they had the machine. They could look at the software. Most people never get that chance.

The AccuVote-TS wasn't an outlier. It was a window — briefly opened — into systems that are normally sealed shut.

And here's the uncomfortable question: if that's what one independent analysis found in a week, what might persist undetected in systems that have never been publicly examined? We have no way to know. That's the whole problem.

'We audited it' is a claim, not a conclusion

Officials like to say that post-election audits confirm the results. Sometimes that's true. Often it's more complicated.

In Antrim County, Michigan, in November 2020, wrong unofficial results were published. Not marginally off — thousands of votes in the wrong column. The error was caught, but not by any internal safeguard. It was caught because the result was absurdly implausible for a county everyone knew leaned heavily Republican. A subtler error, in a closer county, might have passed unnoticed.

Then, in December, officials conducted a full hand count of every presidential ballot to verify the corrected machine tally. The hand count came back with a twelve-vote spread from the machine total out of roughly 15,700 ballots cast. Twelve votes.

In a lopsided race, twelve votes is a rounding error. But here's the problem: in a genuinely close race — one decided by fifty votes, or twenty, or five — a manual recount that is itself off by a dozen votes cannot resolve anything. It can't. Not mathematically. The "gold standard" manual audit carries its own irreducible human error: ambiguous marks, fatigue at 2 a.m., disputed adjudication calls made differently by different pairs of hands.

When the Michigan Department of State said the audit "affirmed accuracy," that was a reassurance. It wasn't proof. The twelve-vote gap doesn't disappear because an official calls a press conference.

The real argument here isn't that anyone cheated. The argument is that "the Secretary of State says it's fine" and "a hand count confirmed it" are substitutes for independent verifiability — and substitutes are not the real thing.

What open source actually means for a voting system

People hear "open-source voting" and imagine hackers being invited to break the election. That's the wrong picture.

Open source means the software's source code — every instruction the machine executes — is published where anyone can read it. Security researchers. Academics. Your nephew who took two programming classes. Other vendors. Journalists. Independent watchdog groups. Anyone.

This matters for a reason that sounds almost too simple: you cannot hide a backdoor in code that everyone can read. Or rather, you can try, but the probability of detection collapses as the number of independent readers grows.

Modern cryptographic voting research goes further. Open source is the foundation, but the structure built on top is what turns "you can read it" into "you can prove it."

Here's how the pieces fit together:

Public source code means anyone can inspect what the software is supposed to do. That's step one, but only step one — because the code you compile and the code actually running on a machine can be different things.

Reproducible builds close that gap. If a voting system's build process is reproducible, it means that anyone who takes the published source code and follows the published steps will arrive at a binary — the actual machine-executable file — that is bit-for-bit identical to the binary running on certified machines. You can check the hash. If it matches, the machine is running what it says it's running. If it doesn't match, you know immediately, without trusting anyone's word.

A cryptographic integrity layer goes further still. Techniques like end-to-end verifiable (E2E-V) voting allow each voter to receive a receipt that lets them — and anyone else — confirm that their ballot was cast as intended, recorded as cast, and counted as recorded, without revealing who they voted for. The math is public. The verification is public. The result doesn't require trusting any official, any vendor, or any auditor.

Together, these three layers move the question from "do you trust the vendor?" to "can you check the math yourself?"

That shift is everything.

Why Coffee County proves that secrecy is the wrong strategy

Let's return to Coffee County for a moment, because the lesson isn't quite what most coverage suggested.

The breach was treated primarily as a security-of-custody story: unauthorized people accessed a system they weren't supposed to access. True. But underneath that story is a structural assumption that made the breach so consequential in the first place.

The system's security model depended on the software staying secret.

If the software had been open source, "they got a copy of the code" would be significantly less alarming — because anyone could already have a copy of the code. The integrity of the election wouldn't rest on keeping the code hidden. It would rest on the math: cryptographic commitments, public audit logs, verifiable records that anyone could check and no one could quietly alter.

What the people who walked into that office took was proprietary. Its value as a prize depended entirely on it being a secret. A system built for transparency and tamper-evidence wouldn't have handed them nearly as much.

Lawfare's reconstruction of the Coffee County episode is worth reading in full. The Atlanta Journal-Constitution's reporting adds additional detail on what was copied and how it spread. Together they illustrate a principle security professionals have understood for decades: systems that rely on obscurity are fragile in exactly the ways that matter most.

The reproducible builds problem is not theoretical

"Reproducible builds" sounds like a software-development housekeeping issue. It isn't.

Here is the concrete problem it solves. Imagine a voting machine vendor publishes its source code. Journalists and researchers read it. Looks fine. The certifying lab tests it. Passes. The Secretary of State certifies it.

Now imagine that when the vendor compiles that code into the binary that actually runs on machines, they make a small change. Not in the published source — in the compilation step. A single different instruction. The binary on every deployed machine differs from the binary anyone audited, in a way that no post-election paper check will catch, in a way that a risk-limiting audit will not catch, in a way that even a full hand count won't catch unless the paper record itself has been compromised.

You can't detect this without reproducible builds. With them, you can: compile the source yourself, compare the hash, and know. Instantly. Without trusting anyone.

This isn't a hypothetical scenario built for rhetorical effect. The supply-chain attack against SolarWinds — which had nothing to do with elections but everything to do with the principle — showed that sophisticated actors can modify software at the compilation stage, leaving source code that looks clean while deploying binaries that aren't. The same attack surface exists in voting software wherever builds are not independently reproducible.

No U.S. voting system currently deployed at scale offers independently reproducible builds that any member of the public can verify. That gap is real. It is measurable. And it is not closed by any official telling you the system was tested.

See how this gap compares across jurisdictions worldwide →

What 'verifiable' actually means — and what it still doesn't

It's worth being precise here, because "verifiable" gets used loosely.

A risk-limiting audit, like the one Colorado pioneered in 2017 or Georgia deployed at statewide scale in 2020, is a genuine improvement over fixed-percentage spot checks. Hand-examining paper ballots gives statistical confidence the machine count is right — if the paper is trustworthy and if the sampling is genuinely random.

Those are real "ifs." But even a perfect RLA only verifies that the paper and the machines agreed. It doesn't tell you whether the software that ran those machines was what it claimed to be. It doesn't verify the compilation step. It doesn't let a voter confirm that their specific ballot was included and counted. It confirms the tally against the paper; it doesn't make the software itself checkable.

An open-source, reproducible-build, end-to-end verifiable system doesn't replace audits. It gives audits something solid to stand on.

The hierarchy looks like this:

Proprietary, closed software: trust the vendor entirely
Open source only: trust that no one inserted something malicious in the build
Open source + reproducible builds: trust that the published code and the running binary match, independently confirmable
Open source + reproducible builds + E2E verifiability: trust the math, not the people

Each layer removes one more thing you have to take on faith. The goal isn't perfection. The goal is to make the question of "did this work correctly" answerable by anyone with a computer and time to check — not just by officials with an interest in saying yes.

The shareable truth

Here is the line worth screenshotting:

"Every time an election official says 'trust us, we audited it,' they are asking you to trust the auditors. The point of verifiable voting is that you shouldn't have to."

The cases in this piece — the code that couldn't be checked, the results that were wrong until they were obviously wrong, the software copied out of a county office on a hard drive — aren't arguments that elections are rigged. They're arguments that the current model asks for a level of trust that the architecture cannot justify.

Paper trails help. Audits help. But they're not enough if the software generating the results is a black box, if the binaries running on machines can't be independently verified against public source code, and if voters have no mathematical way to confirm their ballot was counted.

What would make this checkable by anyone? Three things, right now unresolved in most U.S. jurisdictions:

Full public source code for every voting system — not source-available-under-NDA, but genuinely public
Reproducible builds with published hashes anyone can verify
End-to-end cryptographic receipts so individual voters can audit their own ballot's inclusion

Until those three things exist, "the audit confirmed it" is a statement about what officials found when they looked. It is not a statement anyone outside the room can independently verify.

That's not a conspiracy theory. It's an engineering requirement.

Read the 2-minute version of these gaps → See which systems and jurisdictions have open-source gaps today → Explore reproducible-build failures in the gap atlas →

Sources

See all posts Explore the gaps