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

From: Nathan L. Adams <nadams_at_ieee_dot_org>
Date: Wed Apr 25 2007 - 23:16:31 CDT

Summary: "Code review will never be perfect, so why bother?"



Hamilton Richards wrote:
> 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
>> counted!
> 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'
> ancestors.
> 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
> bugs).
> "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
> voters.
> 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?
> --Ham
> 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 <>

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