Re: Microsoft-backed Consortium, AeA, Opposing Open Voting Bill, AB 852

From: Hamilton Richards <hrichrds_at_swbell_dot_net>
Date: Wed Apr 25 2007 - 23:01:47 CDT

At 5:38 PM -0700 2007/4/13, OVC Announce wrote:
>Dear Friends of Open Voting:
>The American Electronics Association (AeA) has come out against AB
>852 [1], the bill carried by California Assemblymember Paul
>Krekorian that would require full public disclosure of voting system
>technology upon state certification. A Microsoft lobbyist has also
>been working the state Capitol against us. We've heard that
>Microsoft is also turning up the heat in Washington D.C. in
>opposition to language in federal bills that would require voting
>technology disclosure.
>Let your legislators know that you want them to stand up to industry
>opposition. The people have a right to know how their votes are

Of course the people have a right to know how their votes are
counted, but let's pause for a moment to consider whether it's
worthwhile to devote a lot of attention, energy, and political
capital to the campaign for full public disclosure of voting
technology. There's good reason to doubt that public disclosure would
actually help the people to "know how their votes are counted".

The primary reason that disclosure's benefits are doubtful is this
bit of conventional computer-science wisdom:

      Inspecting and testing software can show that it is capable of
      operating correctly, but can never show that it is incapable
      of operating incorrectly.

What matters in elections is whether e-voting software can be relied
on to count votes correctly, and that question can never be answered
by inspection or testing.

For those who are not computer scientists and find the calls for
inspection and testing to be eminently sensible, some explanation is
in order.

Let's suppose that a vendor agrees to disclose their e-voting
software, and we set out to inspect it. The first problem we face is
that the code that's readable (and writable) by people (the "source
code") is not the code that actually controls the machine-- it has to
be translated into machine-executable code by a software package
called a compiler. Like e-voting software, a compiler can't be
assumed to perform its translation correctly, so we must include the
compiler in our inspection.
     That's not as simple as it sounds. The typical compiler is the
product of years of development in which each version is used to
compile the next version. As Ken Thompson explained in his Turing
Award lecture [2], this self-compilation makes it possible to infect
a compiler with a clever bug which reproduces itself invisibly in the
machine code of all subsequent versions, where it will lie in wait to
be triggered by a particular bit of source code in the software it's
compiling. So we must inspect not only the compiler that's used to
compile the e-voting source code but all previous versions of that
compiler as well--many of which may no longer exist (indeed, someone
who deliberately inserted a clever bug would do well to destroy every
copy of the infected source code).
      Another problem with our inspection project is that the e-voting
code is only a small fraction of the software that controls the
e-voting machine on election day. If we believe in inspection, we
must also inspect all of the operating-system software, not to
mention the firmware resident in graphics cards, disk controllers,
and so on. And for each of these, we must also inspect the compilers
used in their development, along with all of those compilers'
      At this point it's probably obvious that all this inspection
would be an enormous logistical nightmare. Even if Microsoft and the
other vendors of COTS software used in e-voting systems were to do an
about-face and open their source code to public inspection, there's
no way such a massive undertaking could ever be funded.

Suppose we give up the idea of inspecting software, and decide to
test it instead. Unfortunately, determining whether software can be
trusted by testing it is just as hopeless as inspecting it.
      The reason lies in a fundamental difference between software and
physical systems. If you're testing a bridge, and you prove that it
can handle a 10-ton load by driving a 10-ton truck across it, you can
reasonably trust it to handle any load weighing less than 10 tons.
With software, however, there are no physical laws supporting such
inferences; if a bridge were like software, you'd actually have to
test it with trucks of all possible weights less than 10 tons.
     And that's only the beginning-- the load a bridge can support is
a single variable, but the typical software package has many
independent inputs which would have to be tested in all possible
combinations. This situation is captured in the well known aphorism

      Testing software can reveal the presence of bugs, but can never
      confirm their absence [1].

Even if these insurmountable obstacles were somehow surmounted, we
would still face massive challenges in ensuring that the software
we've inspected and tested is the same as the software that's
controlling the machines on election day. To prevent unauthorized
installation of fraudulent software, every e-voting machine would
have to be secured with an unbroken chain of custody. Such stringent
security measures have been shown to exceed the capabilities of many
election administrators.

The bottom line is that no matter how much effort we put into
inspecting and testing disclosed e-voting source code, we still can't
say for sure that we know that it will operate correctly under all
conditions. If the software counts votes, we still don't know how our
votes are counted.

Some proponents of disclosure argue that inspecting and testing
software can reveal flaws, and that correcting those flaws must
necessarily improve the system, making it more trustworthy than it
was. Of course correcting software's flaws usually improves its
quality (the exceptions are the "corrections" that introduce new
    "More trustworthy", however, isn't good enough for elections.
Unless we know for sure that e-voting software is incapable of
operating incorrectly --and that's something we can never know-- we
must treat it as not to be trusted.

Note that these arguments against the linkage between source-code
disclosure and correctness apply equally well to open-source
software. Open source has many virtues --amply explained elsewhere--
but guaranteeing correct vote counting is not one of them.

Fortunately, as readers of ovc-discuss well know, the untrustworthy
e-voting software is part of a larger system, and that larger system
can be made trustworthy despite the untrustworthiness of its software
component. The OVC design [3] accomplishes this feat by printing each
ballot for its voter to check. The printer-equipped system can be
trusted, whether or not its source code has been publicly inspected,
because the results --the printed ballots-- are verified by the

So a good question is: What would disclosure, inspection, and testing
buy us? OK, it would ensure public humiliation of the vendor, but
satisfying though that may be, is it worth all the trouble?


1. E.W.Dijkstra, "The Humble Programmer". CACM 15 (1972), 10: 859-866

2. K.Thompson, "Reflections on Trusting trust". CACM 27 (1984), 8:
761-763 <>

3. Open Voting Solution <>

Hamilton Richards, PhD           Department of Computer Sciences
Senior Lecturer (retired)        The University of Texas at Austin      
OVC-discuss mailing list
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Mon Apr 30 23:17:14 2007

This archive was generated by hypermail 2.1.8 : Mon Apr 30 2007 - 23:17:16 CDT