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

From: Lillie Coney <coney_at_epic_dot_org>
Date: Thu Apr 26 2007 - 08:21:55 CDT

Transparency in public elections should be the rule. I agree
that most people would not have the skills or experience to
review the information provided under a disclosure requirement.
However, that is not the point of open source access to voting
technology it is the principles of self governance. Computing
professionals, non-profits, academic researchers and partisan
efforts would expend resources to look at the information
provided. You would be surprised at how much is dedicated
to election integrity and election protection each year. There
are organizations with this one objective as their mission statement.

Let the companies that want to make the argument for non-disclosure
do so they will lose in the end or their products will not be used
for electronic voting systems.


>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

Lillie Coney
Associate Director
Electronic Privacy Information Center (EPIC)
Coordinator, National Committee for Voting Integrity (NCVI)
1718 Connecticut Avenue, NW
Washington, DC 20009
(p) 202-483-1140 x 111
(f) 202-483-1248
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