Disclaimer: This commentary is a personal response to the Task Force Report and does not represent either the Iowa Board of Examiners for Voting Machines and Electronic Voting Systems or the University of Iowa.
Acknowledgement: I would like to thank David Jefferson, chair of the technical committee of the Task Force, for his comments and support.
In January, 2000, the California Internet Voting Task Force, convened by Secretary of State Bill Jones, released "A Report on the Feasibility of Internet Voting"; this is available on-line from The Election Center. This report is an very important step in assessing the problems and potential benefits of use of the Internet to conduct elections, but it is incomplete in several ways.
I have the impression that the Task Force was working under a fairly strict timetable aimed at putting some groundwork in place for experimental use of Internet voting in the Fall 2000 general election, and that this explains the somewhat jumbled structure of the Report. Furthermore, it is evident that some of the major insights that the Task Force arrived at came late in the drafting of the report.
I agree with and strongly support the following recommendations of the Task Force Report, that Internet voting ...
The remainder of this work can best be read as a suppliment to the Task Force report, outlining the few points where the Task Force report may be wrong, and more importantly, detailing points where the Task Force report did not go far enough. I have listed these in what I perceive to be the order of importance.
The Internet is not the only relevant telecommunications technology!
Internet Voting is not the only electronic voting technology!
The single most important oversight of the Task Force Report, an oversight that may be inherent in the charter from the California Secretary of State, is that it focuses on the use of the Internet. The Task Force apparently began its deliberatons with an almost exclusive focus on the use of the Internet to vote using privately controlled personal computers, and only late in the drafting of the Report did it emerge that many of the issues being dealt with applied to the use of the internet in other contexts.
Many of the issues raised by the Task Force Report are general issues that apply to all electronic processing of ballots, for example, in mark-sense or direct-recording electronic voting machines, and others are general issues that apply to all transmission of ballots using any telecommunications medium.
The current generation of electronic voting machines raises many of the same issues as Internet voting. Today's electronic voting machines are routinely sold with internal modems and central support software allowing a canvass of the precinct voting machines to be computed automatically. Another common technology used on current voting machines is an electronic record of the ballots cast, stored on a removable storage medium such as a diskette or flash EEPROM card, where the votes recorded in these media may be hand carried to a central machine for automatic incorporation into a canvass.
Today's direct-recording electronic voting machines present user interfaces that are essentially identical to the kinds of interfaces we can expect from Internet voting machines. Some use smartcard technology to authorize voting at individual consoles, some require authorization in the form of a PIN, and some are designed to be locally networked at the polling place, with the distinct possibility of Internet connections designed into the machines.
Recommendation: We need laws that address the digital storage and transport of ballots, whether these ballots are stored and transported in hand-carried digital storage media such as disks or EEPROMs, whether they are stored at the voting machine or at a central location, and whether they are transmitted by hand carrying storage media, transmitted by telephone, or transmitted by the Internet.
Recommendation: We need laws that govern the electronic presentation of ballots to voters, whether these ballots are presented by a stand-alone direct recording voting machine, presented by a networked voting machine, presented by a personal computer running dedicated election management software, or presented using a web browser. Issues of on-screen electioneering and adversing, ballot presentation, and the mechanics of casting a vote do not generally depend on the nature of the network, if any.
Recommendation: Only where the special context of voting on a personal computer or voting in the context of a web browser user interface poses new constraints should the law specifically address the use of personal computers, the internet, or the world-wide-web. For example, if the ballot presentation and voting software only controls the contents of some of the windows on the voters's screen, the law cannot reasonably place limits on the contents of the background display or other windows.
Voters will not distinguish direct-recording electronic voting machines from Internet voting at polling sites!
The Task Force Report firmly recommends that Internet voting be treated as an alternative to absentee voting. This suggestion is very appropriate for votes cast using computers in the home or workplace, but the wording in the report is universal, so that it applies equally well to Internet voting as it might be phased in, starting with Internet voting machines in regular polling places.
In fact, the most responsible scenerio for the introduction of Internet voting involves use of direct-recording electronic voting machines at regular polling places on election day, where ballots are transmitted using either telephone modems or the Internet when the polls close. Today, in most jurisdictions that use direct recording electronic voting machines, this electronic reporting is used primarily to get rapid totals for distribution to the press, while the official canvass is still carried out by hand-tallying of totals delivered on paper from the polling place.
Unfortunately, the political pressure, both from the more technophilic segment of the voting public and from election officials who need to project an image of being on the cutting edge, is to leap into full-fledged Internet voting, following, for example, the example set by the 2000 Arizona Democratic Primary.
Recommendation: We need to move carefully toward allowing votes to be reported from the polling place to the official canvass by electronic means. This would be the most responsible first step in the implementation of anything resembling Internet voting, and will most likely be carried out at the close of voting on election day.
Recommendation: Where Internet or other telecommunications-based voting is allowed as an alternative to absentee voting, it should not be allowed on election day, so that conventional polling places can serve as a backup in the event of problems that might prevent a voter from casting a successful Internet vote. Here, I restate a recommendation of the Task Force Report in order to distinguish it from the following:
Recommendation: Where Internet or other telecommunications-based vote reporting technology is used to transmit votes from regular polling places to a vote counting center, alternative manual transmission methods must be supported in the event that problems prevent successful transmission. This does not require the use of paper ballots, but rather, it requires that any direct recording electronic voting machines retain a local copy of all votes cast that can be relied on in the event that transmission fails.
Earning the public's trust is a central issue!
Two primary issues dominate most of the Task Force Report: First is the issue of reliability and security in the vote tabulation process. Clearly, all votes cast should be properly accounted for in the official canvass, yet no individuals vote should be disclosed. Second is the issue of voter authentication and security. Clearly again, none but the votes of properly registered voters should be included in the official canvass. Most of the recommendations of the report address these issues, with both technical and administrative proposals to assure that they are satisfied.
However, there is little discussion of the need for openness in the process. With manual vote tabulation, we have a longstanding practice of requiring that no ballot handling be permitted except in the presence of multiple witnesses and with provisions allowing for observers to be present representing any political party or other interested group. These traditions play a central role in ensuring that voters trust the election administration and believe that the results reported actually reflect the will of the voters.
When vote tabluation is carried out by proprietary software and votes are transmitted in digital form over public telecommunications lines, what mechanisms do we have to assuer a comparable level of oversight? The Federal Election Commission Voting System Standards currently suggests (and a growing number of states require) that the software used in voting machines be audited by an independant testing authority, but this requirement comes nowhere near providing a level of oversight comparable to the open ballot counting procedure traditionally used for manual tabulation of paper ballots.
Furthermore, current standards include an exemption for "industry standard" components. Thus, off-the-shelf operating systems, database packages, and high-level programming environments are being used with increasing frequency as implementatio tools for new direct-recording electronic voting machines. The perversion of an exempt component that is used, among other places, in voting machines could become a tempting target for someone interested in fixing an election, and neither current oversight mechanisms nor the Task Force proposals address this issue except with test and recount mechanisms.
Unfortunately, testing cannot hope to disclose any but the most naive insider attacks on the integrity of a vote counting mechanism, and recounts themselves are subject to attack! In a well known example from Chicago, involving lever voting machines, an election was fixed by replacing the voting machines after the polls closed, and then requesting a recount! In effect, the recount itself was used as the vehicle for rigging an election.
Recommendation: Current Federal standards and must be extended to cover not only the software resident in the voting machine but all software used to present a ballot to the voter or to process the votes cast by that voter. All such software should be equally subject to audit, without regard to the fact that it is run locally on a voting machine or remotely, for example, in a central counting center!
Recommendation: Whenever a ballot or vote total is passed through a component of the ballot presentation or vote counting software that is exempt from third-party audit or public inspection, protective measures must be taken and documented in the audited code to hinder attacks from exempt code. A demonstration that the exempt code can do no harm suffices, but frequently, measures such as encryption or electronic signatures will be required.
Recommendation: Whenever feasible, open-source software should be preferred over proprietary products in the construction of ballot presentation and vote tabulation software. There are several open-source operating systems on the market that will run, without modification, on the hardware used for many of the current generation of direct-recording electronic voting machines, and in this context, there is no justification for using proprietary products which are not open to any audit!
Computer systems are inscrutable in another way. If I look at a lever voting machine, I can easily verify how it works. During pre-election testing, the back is removed in the presence of observers and the mechanism is operated so that the odometer mechanisms that are used to record the votes for each ballot position can be inspected while they are used.
In comparison, there is no way to inspect the workings of a computerized voting system short of undertaking a major and destructive reverse-engineering effort! The assertion that the software resident in some computer is the identical code that was tested months ago at some laboratory is a very difficult assertion to prove!
Programmers and software vendors are notorious for making changes on short notice, and there is an entire genre of software feature, known by the fanciful name of easter eggs, which shows up in many software products without the approval of vendors! Just because, on starting a voting machine, it prints out some version number, we have absolutely no assurance that it is actually that version.
The current best practice in this area is to ask each software vendor to store a copy of the code used for each approved voting machine in escrow, held in secure storage by a third party. This is a useful step, but if a question arises, how do we verify that the software in the voting machine is the same as the copy recovered from escrow?
If the escrowed version is source code and the copy in the voting machine is object code, we must compile the source and compare it with the object recovered from the voting machine. Such a comparison is only meaningful if the same compiler and software development environment is used for the escrowed copy as was used during voting system development, so an escrowed copy of the source code may only be useful if the escrow also includes these tools!
If the escrowed version is object code, it should be easy to compare it with the code resident in the voting machine, but how do we prove that the object code was produced from the source code that was audited by the independent testing authority? Furthermore, object code does not serve other useful functions we can hope for from escrowed code; specifically, it does not provide the owner of the voting machine with insurance in the event that the vendor goes bankrupt or is otherwise unable to make necessary changes to the system.
Recommendation: We need to require vendors to place, in escrow, both the source code and the object code created from that source code for each approved version of any voting software.
Recommendation: We must require that voting systems be constructed in such a way that it is relatively simple to determine the actual software installed in the system, and this determination must be demonstrated by comparing the machine's version with the escrowed version in the presence of knowledgable witnesses acceptable to the election jurisdiction (probably the independent testing authority staff).
This is a difficult requirement; self-identification of the software by a version number is not sufficient! Systems that includes provisions for access to the entire contents of a machine's ROMs and disks are sufficient, and there may be cryptographic signature tricks that will work.
Recommendation: We must require that the escrowed object code be generated directly from the source code that is given to the independent testing authority, and both this generation and the chain of custody from this operation through the escrow authority to any later testing of voting machines against the escrowed software must be completely documented.
This is also a difficult requirement. If someone, in my presence, compiles a program and then burns the source code and object code for that program onto a CD-ROM and gives it to me, I have no assurance that the CD-ROM actually contains the code they said it does. The reason is, they controlled the computer that was used to perform the entire demonstration! They could easily have changed the commands so that commands that familiar and appropriate commands for the advertised purpose actually do something entirely different! Therefore, we will probably have to require use of a "straight out of the box" software development environment with no access to any software components other than those documented as being included in the voting system.
Standards encourage innovation and competition!
The current market for computer-based voting machines and vote counting systems is dominated by a handful of private companies that manufacture incompatable proprietary systems. While these make use of an increasing number of standard components, ranging from use of standard FAX scanning mechanisms in the new generation of optical mark readers to the use of standard motherboards and flat panel displays in direct-recording electronic voting machines, the software being written for ballot presentation and vote counting conforms to no standards.
Thus, if an election jurisdiction wishes to phase in a new voting machine, using it experimentally in a few precincts while using other machines in other precincts, ballots must be prepared independantly for each kind of machine, typically using incompatable proprietary ballot preparation software, and the votes cast on each kind of machine will be reported electronically to the counting center in incompatable proprietary data formats. If things continue as they are, Internet voting will simply add to this complexity!
Furthermore, the use of proprietary data formats means that the voting machine and software manufacturers are frequently reluctant to disclose any details of the format, even to the state boards of examiners who are required to make the final decisions about the adequacy of the voting systems to meet the requirements of state law. In several cases, it has become evident, after extended questioning of a vendor, that the proprietary formats being used included significant misunderstandings of cryptography and other significant security flaws. The Task Force Report does not propose a remidy to this, aside from the suggestion that the examiners be knowledgable in these areas.
The Task Force Report goes so far as to give a limited and somwhat reluctant endorsement of "security through obscurity" (see Appendix A, Section 6.2.2, item 7) as one measure that may help improve security, despite the fact this approach has led to repeated problems in other domains. This recognizes the reality of current industrial practice, but we must not encourage such inadequate practices!
Recommendation: Whenever possible, open standards should be used for ballot storage and transmission. The security provided by such standards will be open to verification and challenge by the public, including the community of security and cryptography experts, and the use of such standards should allow conforming machines from different manufacturers to compete within a jurisdiction.
Recommendation: In all cases, the audit of a voting system should include an audit of the secrets on which the security of the system rests. Where do the keys used for electronic signatures and cryptographic codes originate, how are they distributed, what is their lifetime, and what measures prevent their unauthorized or accidental disclosure? What technical details of the implementation must remain secret in order to assure the integrity of the system? Ideally, the system's security should be assured if all code were publically disclosed, with only a small handful of short lifetime keys being held secretly! Many cryptographic systems meet this requirement!
Fault tolerance requires duplicate copies of all ballots!
Current Federal voting system standards require redundant storage of ballots, and the use of atomic transaction technology requires that ballots be stored in duplicate, preferably in separate locations. During the transfer of a ballot using any telecommunications technology, one copy will exist temporarily on the sending machine while another exists on the receiving machine. Only after transmission is verified and a duplicate created at the receiving machine can the original be deleted.
When ballots are transmitted from a polling place using any form of telecommunications technology, a copy of the original is likely to be retained on the voting machine, perhaps on a hard disk or EEPROM. Current standards suggest that this be retained under seal until a recount is no longer allowed.
The problem raised by this duplication is that current voting standards grant complete authority to the "original ballot" as cast by the voter and grant no legal standing to any copies. While this makes perfectly good sense in the context of paper ballots, there is no clear definiton of an original in the context of voting systems that involve redundant storage of ballots.
When data is processed by and stored on computer systems, it is possible use electronic signatures and other forms of redundant storage to detect transmission errors, storage errors or deliberate alteration. (In general, these are indistinguishable from each other.) If there are multiple copies of a ballot (or of an intermediate result in computating the canvass of an election), such redundancy can be used to identify which copy is correct and reject the other.
In the Task Force Report, a specific atomic transaction protocol is implied in the suggestion that the voter "click here" to cast his or her vote, and then be asked to "click again" to confirm that, indeed, the intent was to cast the vote. We can properly refer to this as a "two phase" ballot deposit operation. Ideally, a copy of the ballot should be stored in response to the first "click", so that nothing but a confirmation needs to be transmitted upon the second "click". If the user decides not to commit his or her vote, the saved (possibly remote) copy can be deleted, allowing the local copy to be edited, and if the user decides to continue, the local copy can be deleted and the final validation attached to the remote copy.
In the event of a failure during a two-phase ballot deposit operation, it is possible to either declare that ballot was been deposited or that it wasn't. Both outcomes are technically correct, but the Task Force Report recommends that the copy be considered invalid if such a failure occurs. It would be quite feasible to consider an incompletely committed vote as a type of challenged ballot (to be counted only if there is no evidence that the voter tried again) or to consider the first "click" as a sufficient signal of voter intent and to accept the ballot.
The task force justification for their recommendation in the event of failure during a two-phase ballot operation is that the voter should be able to walk away from the voting machine at any point without penalty. Unfortunately, this means that a voter who walks away after the first click, thinking that the vote is complete, will not be counted.
Recommendation: Laws governing ballot storage and transport must be changed so that, in the event that one of several copies of a ballot shows evidence of corruption, a copy showing no such evidence may be legally substituted for the corrupt copy.
Suggestion: The Task Force recommendation about the action to be taken during a failed two-phase commit operation should be viewed skeptically. This item needs more thought.
An important part of the power of the web is customizability!
The Task Force report quite rightly expresses suspicion about the security of the current generation of personal computer operating systems and web browsers, and recommends, therefore, that any internet voting software be required to run on a clean operating system and web browser, that is, one that is distributed for use as a voting system and that requires that the user halt his machine and load this new clean system prior to voting.
Unfortunately, there is no way to guarantee that a system loads cleanly. Furthermore, with the new generation of RISC processors that emulate classic Intel chips in software, with products like Soft PC that allow an Apple Mac to emulate an Intel-based PC, or with virtual machine monitors (a 30 year old technology that is finally appearing on PCs), what the designer of the voting system perceives as a clean system may in fact be subject to arbitrary transformation by the emulation system.
Furthermore, one of the most important features of the web is that the user has, to a great extent, control of how web-based information is presented. Visually handicapped users frequently prefer text-only web browsers like Lynx, while others have strong preferences for the way one or the other major browsers presents information. If users are forced to reboot their systems and use a clean browser, they will typically lose their control over presentation style, and offering presentation style options or the option of allowing the user to customize the presentation style merely adds complexity to what ought to be a simple "point click and vote" operation. This may severely limit user acceptance.
A related problem is that of voter trust! The fact that the election jurisdicton trusts an internet voting system to correctly and securely allow users to cast their ballots does not imply that the voters can trust this system to run on their personal computers without leaving footprints, perhaps damaging files or leaving viruses behind which have nothing to do with the voting process. Inadvertant side effects such as these have proven to be dismayingly common in commercial software!
Recommendation: Voting software that runs on the voter's personal computer must be certified to be free of side effects on that computer as well as being certified as secure and reliable for voting!
A Pessimistic Observation: Until we can find an alternative to installing a completely new "clean system" on the user's personal computer for ballot presentation and voting, secure, reliable and trustworthy voting on personal computers will not be a realistic possibility. We must choose between convenience on the one hand and secure, reliable and trustworthy election administration on the other hand.