You Can NEVER Trust a Voting Machine

… because you can never know what its software is doing

Arizona legislators are trying to ban the use of voting machines in future elections. This is a great goal, and hopefully it’s the start of a national trend, but their rationale bespeaks their woeful technical ignorance. The ban is only upon machines that contain “chips” made in either China or Taiwan. Manufacturers can easily evade this by having equivalent components made elsewhere. But beyond that, the hardware is not the problem.

Here is a list of things that you do NOT need in order to compromise a voting machine:

• compromised hardware (“chips”),

• compromised human operators,

• Internet access (whereby an external human or computer might interact with the voting machine).

Anyone who believes that anything in the above list is required in order for a voting machine to commit fraud is ignorant of how computer-based systems work.

Here’s a story that illustrates this. Volkswagen was selling diesel cars in the United States that had inexplicably good performance, considering that Volkswagen had to meet the same emissions standards as everyone else. VW’s diesel cars had been passing the EPA’s emissions tests for years. The mystery unraveled when researchers discovered that the normal emissions of VW's engines were different from those observed under test. VW's engine control software could detect whether the car was undergoing testing, and during such tests it would alter its engine behavior to produce lower emissions, for the express purpose of fooling the EPA.

This was done by a tiny computer that is not connected to anything outside the car. From Volkswagen we learn these things:

• The “chip” is not the problem. The chip could have been made anywhere. The problem was the software that the chip was running – software presumably written by VW engineers.
  

• Computers do not need to be connected to the Internet or to a human operator or to any outside agent in order to cheat; the cheating can be built into the system in advance. And as we will see below, it is possible for this to happen without the manufacturer even knowing it.
  

• It is almost impossible to determine what a computer-based system will do under realistic conditions. For example, a voting machine could behave one way during testing (before the election) and a completely different way on election day, since the software could change its behavior based upon the date on the machine’s internal clock.

With our current systems we cannot audit elections

We formerly trusted elections because ballots were counted and tabulated by hand, with multi-partisan humans observing the process. It is incredibly strange that our leaders didn’t seem to notice the disappearance of this essential safety feature when they adopted electronic voting systems.

Humans cannot directly audit voting machines because the action is taking place at high speed within an object whose operations are completely opaque. One way to audit such machines is to have them audit themselves, which is to say that we’d have them produce reports about their own behaviors. But this type of auditing makes sense only in a trusted environment; obviously if a machine cannot be trusted, then it cannot be trusted to audit itself.

We might connect a voting machine to a separate auditing computer that monitors and records the voting machine’s every action. The resulting log could later be inspected to determine whether the voting machine was behaving properly. But this would be expensive, and the auditing system might also be compromised, especially since it must interact intimately with the voting machine.

A more practical way to independently audit a voting machine is to have a completely separate parallel system that processes ballots in the same way that the primary system does. To allow for cross-checking of individual ballots, every ballot would have to be marked with a unique serial number. It seems unlikely that we will undertake the expense of building parallel systems, and even if we did, we’d need to somehow be sure that there is no collusion between the two systems’ makers and no overlap in their software components and software development systems. And as you will see below, ensuring that the parallel (auditing) system isn’t also compromised might be impossible.

We could try auditing the voting machine’s results at some macro level. Actually, this is how we “audit” the software we use every day – by checking to see whether it seems to be producing expected results. But with voting we cannot spot-check expected behaviors since we don’t know what to expect. Our election systems intentionally divorce ballots from voters; there is no way to ask whether individual voters’ votes were recorded properly, since there is, by design, no way to connect a voter’s stored data with the voter. And unless we have some completely independent system that reads voters’ ballots in parallel with the primary voting system (as described above), we cannot audit the aggregate results, since there is no result against which to compare.

The problem is the SOFTWARE

Someone interfering in our elections would want to dynamically change the behaviors of voting machines based upon the specific election and upon the machines’ local environments. Putting such changes into hardware would require that different versions of the machines be produced for different locales. The malefactor must further arrange that only machines intended for specific locales end up there. And then, the hardware might have to be changed for every subsequent election. This makes no sense.

Aside from that, the behaviors that bad actors would want to modify are not even encoded at the hardware level. The logical place to encode malevolent behavior is where the high-level behavior of the machine is controlled – which is in the software.

So how do we check the software? If we cannot audit the behavior of a voting machine, the next-best thing is to review the machine’s source code. The best way to do that is to publish the code publicly, to allow as many independent reviewers as possible. Our first problem, then, would be to get the voting machine vendors to agree to publish of their proprietary code and to trust that they’ve provided the correct version, i.e., the version that runs on their machines on election day. But even if we could get them to do this, source code reviews are not enough.

Decades ago there were two guys working at Bell Laboratories who together invented the prototype of the software that now runs most of the computing devices on earth – including the operating systems of both Apple and Android phones. Their names were Ken Thompson and Dennis Ritchie. We would do well to heed their advice.

In 1983 Ken Thompson delivered a lecture to the Association for Computing Machinery (ACM) on the difficulties of ensuring software integrity. He called it Reflections on Trusting Trust. It won the ACM’s Turing Award for that year. In his lecture Thompson demonstrated how to modify the code of a compiler so that its compiled output files thereafter contain a Trojan horse. The compiler continues to implement the "horse" even after the compiler’s own malevolent source code that introduced the horse has been removed, so there is no trace of the horse in the compiler’s source code even though the compiler continues its altered behavior. Thompson didn’t just talk about this; he demonstrated it by doing it.

The purpose of this Trojan horse is to cause the compiler to insert malevolent code within the output files of the application programs that it is compiling – for example, your voting machine software. The compiler does this whenever it encounters benign-looking patterns in the application source or in the data that the application is processing - in this case those of the voting machine. Only the implementor of the Trojan horse knows what these patterns are.

To summarize: a reasonably educated programmer can make a one-time change to a compiler’s source code that causes the compiler thereafter to perpetually insert malevolent code into the compiled output files that it produces. Once the compiler has been used to compile itself, the source code that implements the Trojan horse can be removed, and the compiler will continue behaving as if that code were still there. Subsequent inspections of both the compiler’s own code and the code of the applications it compiles (e.g. voting machine software) will reveal nothing.

This has staggering implications. Because of the enormous cost of producing a compiler, there are few of them, and the few that exist are widely used. Examples: Microsoft’s compilers and the open-source GNU compilers. The code that implements these compilers has been touched by thousands of developers over the years; it is impossible that any agency (Microsoft, GNU, etc.) has exerted enough oversight to ensure that Thompson’s trick has never been applied ever, not even once. And there are thousands if not millions of applications that have been compiled with those compilers.

There is only one practical solution

Let’s review:

• We don’t need bad hardware, bad actors, or Internet connections to compromise a voting machine on election day.

• We can’t meaningfully test a voting machine before election day.

• With our current systems, we can’t audit a voting machine on election day, either at a micro (ballot) or macro (aggregate) level.

• We can’t really know what software is actually running on election day.

In the end, Ken Thompson, one of the great geniuses in the history of computing, said:

“You can't trust code that you did not totally create yourself. No amount of source-level verification or scrutiny will protect you from using untrusted code.”

And by “code” Thompson means not only all the code in your application (including all the libraries it uses) but also all the code in the software development systems that compiled your application, along with all the code in the operating system upon which your application runs. Since nobody can afford to develop all the components required to run a commercial software product, it is almost impossible to know whether your application is compromised.

The people who want to convince you to trust voting machines are either ignorant or corrupt. There is no way for anyone to know what any computer is doing at the moment. Except for highly unusual and prohibitively expensive auditing scenarios, the only way that we can affirm that a computer is doing what we wish is to observe its gross, overall behaviors and see that those appear to be in keeping with our desires.

Any election that is not fully audited should be presumed corrupt. Auditing a computer-processed election requires using totally independent parallel systems and comparing their outputs. Even then, it is unclear whether computer-based methods could match or exceed the integrity of human-audited, hand-counted voting. Unless we massively enhance our voting infrastructure to mimic the fault-tolerant systems that control airplanes, for example (which coincidentally are said to make decisions by “voting”), there is no electronic option.

With no current electronic option, we must have a process that is fully and directly observed by humans in real time - that is, humans watching as ballots are being counted and at every stage of ballot processing and vote tallying. This means hand counting individual ballots under the supervision of bi-partisan observers. Without a very expensive commitment to vastly upgrading our electronic systems to meet fault-tolerant standards, there is no other way.

Epilog (added 6/19/23)

In the wake of the 2020 and 2022 elections, Democrats have mocked and jailed people who have dared question the results. In typical fashion they’ve affixed a label to us: “election deniers.” Using this tag, as with all their other tags, they manipulate their NPC voters to avoid even contemplating the idea that something wasn’t right. Search on “election deniers” and you’ll be rewarded with copious results that all seem to speak unquestionable truths.

Federal law requires that publicly traded companies be audited both independently and regularly. The Sarbanes-Oxley Act of 2002 passed with bipartisan support, and few today would question the wisdom of requiring public corporations to submit to public scrutiny. Considering their constant rhetoric about how corporations and capitalists cannot be trusted, Democrats must certainly be the most enthusiastic about it.

How strange then, the Democrats’ position on voting machines. Here we have some corporation which cannot be trusted, delivering what amounts to a black box to an audience of technically naïve election officials. The untrustworthy corporation gives a demonstration showing that the box does indeed seem to do what people might expect it to do. The officials, most of whom probably couldn’t find the power switches on their home computers (if they even have home computers), then certify the machines as “good to go.” It doesn’t even occur to them that voting machines don’t even pretend to be audited; no doubt the officials don’t recall that in the days of hand counting, elections were always audited in real time.

The corporations delivering these boxes aren’t even known brand names; outside of election officials, almost nobody has heard of them. Nobody thinks about who owns them or where they might be based or where or how their machines might have been created or programmed. But if you suggest to a Democrat that we even question such things, the he/she will fly into an emotional rage and insist that there’s something wrong with you. And if you make a really big deal about it, you could end up in solitary confinement for years awaiting trial.

I am reminded of six-year-old Calvin, of Calvin & Hobbes. Calvin gets a cardboard box and writes some word on the outside that indicates what he wants the box to do. And because this box has this word written on it, well then, the box must certainly do that:

If it says “voting machine”, then it must be a voting machine.

As with most things in Democrat-land, the hypocritical inconsistency is almost too insane to contemplate. But, as Mick Jagger was inclined to say during interviews when commenting about the inexplicable, “There it is.”

====== ADDENDUM of 2/8/2024

In just four minutes, Mollie Hemingway states the obvious about U.S. elections to Congress. Apparently few seem to notice or care: Mollie Hemingway tells Congress what’s wrong with our elections

====== ADDENDUM of 8/9/2024

Wow. Who could have guessed? A principal staff member of a voting machine manufacturer involved in bribery and fraud? Impossible!

President Of Voting Machine Giant Smartmatic Indicted On $1 Million Bribery, Money Laundering Charges

Of course, they assure us, the fraud does not extend to the machines themselves. With trillions of dollars’ worth of contracts depending upon who gets into the White House every four years, there couldn’t be a few billion $$ floating around for bribes, could there?