Why Elections Need TCP/IP
By Jim Reynolds | www.reynolds.com
September 23, 2026
The Internet works because nobody has to trust everybody else.
Your computer may be made by Apple. Mine may be made by Dell. The router may be made by Cisco. The server may be running Linux. The network in between may cross equipment owned by a dozen different companies.
Yet they all talk to one another.
Why?
Because they follow protocols.
The rules are public. A packet, which is the basic unit of transmission, has defined fields. Certain information belongs in the header. The payload follows a known structure. Invalid packets are rejected. Errors are handled according to known procedures. Lost information can be retried. Routers know what to forward and what to discard. Monitoring systems can watch traffic and identify bottlenecks, failures, congestion, and abnormal error rates.
Nobody gets to say, “Trust our proprietary interpretation of what an Internet packet should look like.”
The protocol defines it.
That is one of the great engineering achievements of the modern world. We built a global system containing billions of devices made by competing companies, operating under wildly different conditions, and made them cooperate by agreeing on common rules.
The companies compete over implementation.
They do not get to own the rules.
Why do we not run elections the same way?
The Wrong Question
When Americans argue about voting machines, the conversation usually degenerates into one of two positions.
One side says the machines are secure and we should trust the certification process.
The other side says the machines are black boxes and cannot be trusted.
Both arguments miss the better solution: we should not have to trust the machines at all.
That is the whole point of a protocol.
Voting technology should operate under a public, uniform election protocol that defines exactly how ballots are recognized, validated, rejected, corrected, counted, transmitted, audited, and monitored.
The protocol should be more important than the machine.
A Ballot Is a Message
From a software-engineering standpoint, a ballot is not terribly exotic.
It has two basic parts.
First comes a common structure.
Call it the envelope.
Every ballot has certain information that identifies what kind of ballot it is and how it should be handled. Election identifier. Jurisdiction. Precinct. Ballot style. Version. Contest definitions. Validation information. Status information.
Then comes the payload, which is where one election differs from another.
President: choose one.
Senator: choose one.
School board: choose up to three.
Proposition 12: yes or no.
The payload changes from election to election. The underlying protocol does not.
This is exactly how network systems work. The header follows standardized rules. The payload varies according to what is being transmitted.
Once the ballot structure is standardized, the rest becomes much easier.
Authenticate the Voter, Then Anonymize the Ballot
Before a ballot is issued, the system should answer three questions:
Are you who you say you are?
Are you eligible to vote in this election?
Have you already been issued a ballot?
Those are authentication problems.
A voter presents an approved ID. The system verifies identity, confirms registration and eligibility, and checks that no ballot has already been issued. Local facial comparison could provide an additional check, with uncertain cases sent to a human rather than automatically rejected.
Then something important happens.
The identity disappears.
The authentication system issues an anonymous ballot credential confirming only this:
One valid ballot has been issued to one eligible voter.
The counting system does not need the voter’s name. It should never receive it.
The authentication system needs to know that Jim Reynolds received a ballot.
The counting system needs to know that Ballot 4A72 is valid.
Neither system needs to know both.
That separation preserves ballot secrecy while separating voter authentication from vote counting.
From a protocol standpoint:
identity verification → eligibility check → duplicate check → anonymous ballot credential → voting
Then the ballot enters the counting system with no personal identity attached.
Prove the voter. Anonymize the ballot. Verify the count.
That is a straightforward separation of functions.
Recognition and Counting
There are really only two significant software functions at the heart of the process.
1. Recognition.
2. Counting.
Recognition determines what the voter marked.
Counting applies the contest rules and increments the totals.
Neither should require mysterious proprietary software.
A scanner can determine whether an oval is clearly filled, clearly blank, or ambiguous. If the system cannot confidently identify the voter’s choice, it should not guess.
It should reject the ambiguity at the source.
For an in-person voter, the scanner should simply say:
Contest 7 cannot be read with sufficient confidence. Please review your ballot.
The voter fixes the problem before the ballot enters the count.
That is much cleaner than asking election workers later to divine what somebody meant.
The rule should be simple:
· Clear mark: accept.
· Clear blank: accept.
· Ambiguous mark: return for correction or send through a defined adjudication process.
No improvisation.
No proprietary judgment.
No hidden decision-making.
Counting Should Be Boring
Once recognition is complete, counting is almost embarrassingly simple.
Load the ballot definition.
Validate the ballot.
Apply the contest rules.
Increment the totals.
Produce an audit record.
A competent programmer could write the core logic quickly.
That is not an argument for careless software. It is the opposite.
The security-critical portion should be deliberately small.
In computer security, complexity is the enemy of confidence. The more code buried inside the trusted core, the more places there are for errors, unintended behavior, or malicious logic to hide.
So keep the trusted part tiny.
Everything complicated should be pushed outward.
User interfaces can be complicated.
Accessibility features can be complicated.
Reporting systems can be complicated.
Election administration can be complicated.
But the thing that decides whether Candidate A received 10,001 votes or 10,002 should not be.
Voting Needs an RFC
The Internet Engineering Task Force has spent decades publishing documents known as RFCs: Requests for Comments.
They define how Internet systems behave.
Elections need the equivalent.
Here is the surprising part: we have already started building it.
NIST has developed common formats for ballot definitions, cast-vote records, voter records, election logs and results. The Election Assistance Commission has incorporated interoperability into its voting-system standards.
In other words, the engineering world has already recognized the problem.
We just haven’t finished the architecture.
There should be a public election protocol specifying, in exhausting detail:
what a valid ballot looks like;
which fields are required;
how ballot styles are identified;
how malformed ballots are rejected;
how ambiguous marks are handled;
how duplicate ballots are detected;
how spoiled ballots are replaced;
how retries work;
how rejected ballots are recorded;
how adjudication decisions are logged;
how totals are calculated;
how results are transmitted;
and how every step is independently verified.
The specification should be public.
The test suites should be public.
The expected results should be public.
Then everybody gets to beat on it.
Universities. Political parties. State governments. County officials. Independent programmers. Security researchers. Voting-equipment vendors.
Anyone.
That is how confidence is earned.
Not by saying, “Trust us.”
By saying, “Here are the rules. Try to break them.”
Let the Vendors Compete
Standardization does not eliminate private companies.
It makes competition healthier.
Cisco, Juniper, Arista and other companies can all build network equipment because they implement common protocols.
Voting should work the same way.
One company could build an excellent scanner.
Another could build better accessibility equipment.
Another might specialize in high-volume ballot processing.
Another could develop superior audit software.
Another could build monitoring systems.
They can compete on reliability, price, service, speed, usability, security, and support.
But none of them gets to own the rules.
That belongs to the protocol.
A county should be able to replace one vendor with another without replacing the conceptual foundation of its election system.
The machines change.
The protocol remains.
The Acid Test
There is a simple way to know whether we have actually created a protocol.
Give the specification and its test suite to two companies that have never seen each other’s code.
If Company A can produce a ballot that Company B can read, both reject the same invalid inputs, both produce the same count from the same ballot set, and both generate records that the same independent monitoring software can understand, we have a protocol.
If they cannot, we have more work to do.
If two implementations disagree, the disagreement tells us where the protocol is underspecified.
And Then We Monitor It
Network engineers do not merely design protocols and hope everything works.
They monitor the network.
Throughput. Errors. Failures. Retries. Anomalies.
Election systems could work the same way.
Independent, read-only monitoring systems could watch the health of an election without seeing voters or their selections.
How many ballots are being processed?
What percentage are rejected or rescanned?
Are particular machines failing unusually often?
Are adjudication rates suddenly spiking?
Is one precinct rejecting six percent of ballots while comparable precincts reject less than one percent?
That is not an accusation of fraud.
It is telemetry.
And telemetry tells you where to look.
The monitors should not control anything, and there should be more than one. Because every system understands the same public protocol, political parties, universities, news organizations, states, audit firms, and private companies could build independent monitoring systems.
If several independent monitors see normal operation, that tells us something.
If they all detect the same anomaly, that tells us something too.
A network engineer does not declare sabotage every time a router starts dropping packets. He sees the anomaly and investigates.
Election administration should work the same way.
The Paper Ballot Still Matters
None of this means replacing physical evidence with software.
Quite the opposite.
In this architecture, the paper ballot remains the final source of truth.
The computer is there to accelerate recognition and counting.
The physical ballot exists so the machine never gets the last word.
If the electronic total becomes questionable, humans can return to the paper.
That is an important design principle:
The software should make elections faster.
It should not make election results dependent on trusting software.
The Bigger Problem
There is another integrity issue that software alone cannot solve.
A counting system can tell us whether valid ballots were counted correctly.
It cannot tell us whether every ballot entering the system should have been there.
Those are different problems.
Ballot issuance.
Voter eligibility.
Signature verification.
Chain of custody.
Mail-ballot handling.
Duplicate prevention.
Ballot harvesting rules.
These belong to election administration rather than tabulation software.
But the same principle applies.
Define the protocol.
Define the required records.
Define the reconciliation rules.
Define what constitutes an exception.
Log the exceptions.
Audit them.
Do not leave critical decisions buried in discretion.
Remove Trust From the System
That is really the objective.
People often say that Americans need to regain trust in elections.
I would phrase it differently.
We should design elections so that trust matters less.
Engineers do this all the time.
We do not secure computer networks by assuming everybody involved is honest.
We assume machines fail.
We assume programmers make mistakes.
We assume networks break.
We assume people attack systems.
Then we design protocols that detect failure, reject bad information, preserve evidence, and allow independent verification.
Why should voting receive a lower engineering standard?
The system should not depend upon whether Republicans trust the voting-machine company.
It should not depend upon whether Democrats trust the county clerk.
It should not depend upon whether anybody trusts the programmer.
Trust the protocol.
Verify the implementation.
Monitor the operation.
Audit the physical record.
That is how the Internet works.
It might be time to bring elections into the same century.
Let companies compete over the machines. Never let them own the rules.
Author’s Note: Many of the pieces described here already exist. NIST and the Election Assistance Commission have developed common data formats, interoperability requirements, event logging, auditability and other standards for election systems. The proposal here is to carry that engineering approach further: organize the pieces around a comprehensive public protocol architecture in which independently developed systems can interoperate, be monitored and be verified without depending upon proprietary implementations.
Do you ever see elections being conducted via the internet? If protocols are secure and trustworthy, will there be a need for paper ballots?
Here in Oregon, we vote by mail for all elections. I've reported multiple ballots being sent to my address but the Sect of State doesn't seem too interested. Would internet voting correct that or exacerbate the problem?