Testimony before the
Federal Election Commission
Washington D.C., April 17, 2002
Douglas W. Jones
Associate Professor of Computer Science, University of Iowa
Chair, Iowa Board of Examiners for Voting Machines and Electronic Voting Systems
Indexed on the web at http://homepage.cs.uiowa.edu/~dwjones/voting/
Elections are a defining feature of democratic government, but all too frequently, we take the actual mechanics of the election for granted. The voting system standards effort undertaken by the Federal Election Commission and the National Association of State Election Directors over the years since 1984 has been a welcome exception! The voluntary standard released in 1990 has proven to be very important, and the drafts for a revised standard released for public comment on July 10 and December 13, 2001 represent a real improvement.
As a long time member and now chair of the Iowa Board of Examiners for Voting Machines and Electronic Voting Systems, I have been involved in the certification and testing of voting systems for most of a decade. I am a volunteer, with a full-time job teaching computer science at the University of Iowa, but the issues raised by voting systems have consumed a growing fraction of my attention in recent years. I began to make public comments about the shortcomings of the 1990 standard two years ago, and as a result, in the wake of the 2000 general election, I have been called on to testify before the US Civil Rights Commission and the House Science Committee about the regulation of our voting technology.
I have serious problems with many parts of this revised standard, but I want to emphasize that even if these problems are not addressed, the Revised Draft Voting System Standard is generally an improvement over its predecessors and it will stand as an important document no matter what changes Congress makes to the administrative structure under which our voting system standards are set.
I would like to comment specifically on several areas in which I feel the current Draft Standard can be improved; in the comments that follow, I will draw attention to some of the public comments that the Commission has posted on its web site and to previous public statements I have made. My comments fall into the following broad areas:
One of the comments addressed to the Commission objected to the general form of the Draft Voting System Standards. The February 1 comment from AI Technology Inc. objected that parts of the draft standard read like a "FEDERAL LAW" and not like a voluntary standard. I disagree! The standard is voluntary in two senses: First, states may voluntarily enact this standard into law. 37 states have done so for the current 1990 Voting System Standard, and I hope states will enact this new standard into law. Second, vendors may voluntarily comply with the standard even when states do not require compliance. Strict prescriptive language is useful in both contexts!
Several comments addressed to the Commission objected to the prohibition against giving a receipt to the voter. Among these are the February 1 comment from AI Technology Inc. and the February 6 comment from Garland Favorito. I understand the appeal of a receipt, but I believe that these commentators do not understand the risk! Receipts allow a voter to prove how they voted to a third party. Without such proof, you can sell your vote as many times as you want to as many crooks as you want, and then ignore those sales when you vote; as a result, crooks cannot effectively buy votes. If we give voters physical receipts, they will become currency in a vote buying market. There is an exception to this -- that is, when the voters are forbidden to show their receipts to anyone and are required to deposit these receipts prior to leaving the polling place. In this case, what the voter interprets as a receipt from a DRE machine should be considered to be the official ballot, and it is the deposit of part or all of that receipt that actually constitutes the casting of a ballot. I believe that the system described in the comment from AI Technology may actually fall in this class.
Several comments addressed to the Commission have strongly supported Internet voting. Among these are the December 22 comment from the Campaign for Digital Democracy and the the December 20 comment from Matt Veal. Others have taken the exact opposite stance, for example, the December 13 comment from Lisa Fink demanding a paper trail or the January 25 comments from Illinois Information Technology Corporation asking for some assurance that is equivalent to paper in its robustness. I side strongly with the latter! I am not convinced that only paper will suffice, but as a programmer, I am greatly suspicious of both software and the recording media used on computers. Unlike some critics, I am willing to allow the development of paperless voting systems, so long as they are developed under very strict controls.
The goal of allowing as many people as possible to vote a secret ballot without the need for assistance is excellent, and I fully support it. I am bothered, however, by an assumption that seems to permeate much of the public discussion of this issue, that is, the assumption that handicapped access requires the use of direct-recording electronic voting technology.
I wrote about this in my comments on Section 2.2.7 of the standard, submitted on January 29. The February 1 comments from the American Council for the Blind also make this point quite strongly, and the February 1 comments from Belinda Carlton add a strong note of caution to some of the ambitious accessibility language in the draft.
I think that it is fair to assert that we will never successfully create voting technology that can be used to permit every voter to cast a secret ballot without the need for assistance in the voting booth; no amount of legislation or rulemaking will change this! I said this in my comments on Section 221 of HR3295, the Help America Vote Act of 2001, but it bears repeating. What we can and must do is attempt to assure the right to an unassisted secret ballot to as many people as is reasonably practical, while assuring, through administrative procedures, that appropriate assistance is available to those for whom this is not practical.
We leave responsibility for dealing with some classes of handicaps entirely with the voter. I wear glasses; if I forget them, the polling place is not required to provide corrective lenses to help me read the ballot. Mouth sticks for some of those with serious motor disability fall in the same category, as do hearing aids and artificial limbs. All of these are custom fitted to the individual, and we should not consider the failure of the polling place to provide such custom fitted assistive devices to be a systematic failing on the part of our system of elections! The proposed standard, in Section 188.8.131.52 item A specifically requires otherwise.
There are some broad classes of handicaps we must deal with, classes of handicaps where general purpose assistive technology can be reasonably provided. Millions of elderly voters have difficulty voting because they have mild to moderate vision problems and mild to moderate motor disabilities, and this is a disgrace. This is a huge class of voters for whom remarkably simple, low-tech solutions are effective. Conny McCormack, the Los Angeles County Registrar-Recorder/County Clerk, told me that one voting booth in each precinct in Los Angeles is equipped with a hand held magnifying glass and a ruler. These simple and very low-tech aids allow a large fraction of the mildly to moderately handicapped elderly to vote without assistance on punched-card voting machines!
The ES&S iVotronic system uses the same low-tech solution to the problem of text magnification. While it may seem odd to provide a magnifying glass on a computerized system when we know that variable text sizes are common on such systems, the problems of ballot layout and design for variable text size are difficult, and once this problem is solved, there is also the question of how to allow the user to select the text size. These issues are just complex enough to make the widely understood and easy to use "user interface" of a magnifying glass quite appealing.
As an aside, I would like to emphasize the role of the ruler as an aid for those who need a magnifying glass! When you view the world through a small window such as a close-up lens, it is hard to follow long rows and columns across the page. Ballots are full of such tabular structures, and a tool as simple as a ruler can go a long way toward solving this problem.
I would also like to note, as an aside, that the Votomatic and Data-Punch voting systems, while seriously flawed in many ways, are quite good systems for voters with some classes of mild-to-moderate motor disabilities. If properly aligned, the guide plate over the punched-card ballot guides the punch to the enabled voting positions while preventing random punches elsewhere on the ballot. Conventional paper ballots and optical mark-sense ballots do not traditionally come equipped with any similar aid. As a result, some voters who have no difficulty properly punching punched-card ballots make a wide variety of stray marks on the faces of conventional paper and optical mark-sense ballots.
If we copied an idea from the Votomatic system by providing a transparent overlay or pencil guide plate for paper or mark-sense ballots, with holes only over the voting targets, we could go a long way toward assisting voters with mild to moderate motor disabilities. I am convinced that such a low-tech solution would be faster and more convenient than some of the multi-button interfaces I have tested that are supposed to provide handicapped access to the direct-recording electronic machines currently on the market.
If some combination of ballot overlay, magnifying glass and ruler will satisfy the needs of most voters with mild to moderate visual and motor handicaps, the obvious question is, can we extend this to meet the needs of blind voters, those with profound visual handicaps? I do not know that we can do so, but I would like our Voting System Standards to openly encourage exploration of answers to this question instead of simply assuming that blind voters can only be realistically accommodated on direct-recording electronic voting systems.
I'd like to speculate about what a fully ADA compliant paper-based voting system might look like. For most of us, we might be given a paper ballot and a number-two soft lead pencil in the usual privacy folder. At least one wheelchair accessible voting booth in each polling place would have a magnifying glass and ruler in it, with a chair nearby for voters to use who wish to sit while they vote.
As an aid for voters with motor handicaps, there would be a transparent plastic ballot sleeve with holes punched over each voting position on the ballot. Pollworkers would insert ballots in this sleeve publically, asking those present to verify that the ballot is aligned with the holes as the binder clips are attached that lock the ballot in. This would be given to the voter in a privacy sleeve, and it would be arranged so that the binder clips could be removed and the ballot slid directly from the nested sleeves into the voting machine without giving anyone a chance to read the ballot.
For voters who are blind, we could use a very similar auxiliary ballot sleeve, marked in braille. Unfortunately, braille literacy in the blind population is low enough that this solution would not lead to universal ballot access, and we need some way for blind voters to inspect their ballots after voting to see if they are marked as intended. A handheld wand with an infrared proximity sensor in the tip might suffice to solve the latter problem. Hold it to a marked ballot position, and it would vibrate and emit a tone, hold it to an unmarked position, and it would thump once, indicating that it was working and had seen no mark.
Because not all blind voters are literate in braille, we need some way to walk a voter through the ballot. The simplest low-tech solution I can imagine is a simple tape-recorder with start-stop controls and headphones. The tape would be very boring but simple to make, starting with instructions and orientation of the ballot "The top edge of the ballot holder has the paper ballot sticking out, and the top edge of side one of the holder is rippled while the top edge of side two is straight." The tape would continue, ballot position by ballot position, in the following style: "To vote for Abe Lincoln for President, in the left column on side one, mark the 4th voting position down from the top."
We could do better if we had just a bit more money. Imagine a ballot sleeve, the same sleeve used for voters with motor disorders, but with a transponder buried in it by each potential voting position, and with a slightly more intelligent wand that would not only sense the presence or absence of a mark, but would also sense the coordinates of the voting position using these transponders. The wand would contain a computer system about as smart as an old Texas Instruments Speak&Spell toy, and it would be connected to headphones. On touching the wand to any voting position through a hole in the sleeve, the wand would announce, for example, "to vote for the Republican candidate for President, Abe Lincoln, mark here." If the wand sensed a mark at that position, it would change its message to "you have voted for the Republican candidate for President, Abe Lincoln."
I believe that the system outlined above would offer the same degree of universal access that people have come to hope for from direct-recording electronic voting systems, and it would do so while preserving the paper audit trail that we have come to expect from paper-based systems, where it is this audit trail, in the form of voter-verifyable physical ballots, that allows us to trust an election result even when we do not trust programmers. I would like to see our Voting System Standards clearly endorse the search for such solutions instead of simply assuming that handicapped accessibility will be possible only with the use of direct-recording electronic voting systems.
Most of the attention on the Voting System Standards has focused on direct-recording electronic technology and the hope for eventual Internet-based voting systems. This is no surprise -- it is always the exciting new technologies that attract attention. Unfortunately, these new technologies have distracted attention from paper ballots, and I want to emphasize that, particularly in the arena of optical mark sensing, we must improve the Standards. Optical mark-sense paper ballots are and will remain the preferred ballot format for vote-by-mail absentee voting, and until we have can fully trust the software in fully computerized direct-recording electronic systems, I would hope that machine-readable paper ballots remain the dominant technology.
I have written about this at length in my tutorial on counting mark-sense ballots, I discussed this in my Jan 29 comments on Section 184.108.40.206 and 220.127.116.11 of the second Draft Standard, and in my presentation at the 2002 workshop on Election Standards and Technology.
The fundamental problem with the Voting System Standards, as currently written, is that they do not differentiate between the prescribed mark on a paper ballot, that is, the mark made exactly according to instructions, and the acceptable mark, the mark that should be counted. This distinction was at the center of the controversy in the disputed election in Florida a year ago, and we must deal with it if we are to meet the mandate of the Supreme Court decisions that ended that dispute.
This issue mixes aspects of human factors with aspects of technology. On the human factors side, it revolves around how voters interpret instructions and how people interpret marks on ballots. On the technology side, it revolves around the repeatability with which a vote tabulating machine will sense or not sense particular marks, and around the variation between different machines.
The current Draft Standard avoids the human factors issues, focusing only on the technical, but in the area of mark-sense technology the technical side needs improvement. Unless we know what marks each machines will reliably count and what marks it will reliably ignore, we cannot begin to evaluate whether a mark-sensing machine conforms to the requirements of state law or any other reasonable standard! Under the current 1990 Standard and under the Draft Standard, the only thing the vendor must do is document the prescribed mark and show that the machine accurately counts ballots marked with the exact prescribed mark.
Data from machine recounts shows how machines count ballots marked by real voters. When we do this, we find that it is common for one ballot in 5000 to be read differently on the first and second count. I have experimented routinely with every optical mark-sense ballot scanner that has come before me to try to find the reasons for this variability in counting. In doing this, I have looked for:
I find it inexcusable that vendors are not required to give quantitative measures for each of these characterizations of what their machines will accept, and I find it unfathomable why our voting system standards do not require documentation of these issues.
This is not only a problem with the vendors and Voting System Standards! State laws vary immensely with regard to the question of what marks constitute valid votes! I have found several examples of voting machines that will accept and count marks that are specifically considered invalid by the law of some state. The problem is, many state laws define as valid only those marks that are substantially the same as the prescribed mark. Meanwhile, many vendors have been attempting to build mark-sensing mechanisms that accept a wide range of marks that match an intuitive notion of what a clear indication of voter choice ought to look like.
In this domain, I believe that the state laws are wrong, while the voting system vendors are right, but we will not be able to fix this until we require proper documentaiton of what the machines really do!
Section 4.2 of the standard, and particularly the detailed coding standards presented in Subsections 4.2.3 to 4.2.7 leave me feeling troubled. I have been programming computers since 1968, and in those many years, I have written code in many languages to various standards, as well as helping to developed several different sets of coding style guidelines. Overall, my recommendation is to considerably simplify this entire section of the standards.
I believe my recommendation is in line with the January 30 comments from the Election Integration Project on limitations on software module size and redirection prohibition, and the January 25 comments from Illinois Information Technology Corporation on Section 4.2.3 and their February 7 comments on Section 4.2.4, but these commentators focus on the details of the draft without challenging the approach it takes. my first comments on the December 2001 draft, submitted on January 29, did the same.
I believe that the January 28 comments from Sequoia Pacific and the January 29 comments from VoteHere on the coding standards in Section 4.2 should carry more weight. As I said in my later comments on this Section, submitted on February 10, the entire approach taken by Section 4.2 on coding standards is fundamentally flawed.
In general, the goal of the standards in Section 4.2 should be to ensure that all software subject to source code audit is readable by the auditor, and furthermore, we want these standards to ensure that it is difficult to include hidden functionality the code. I want to emphasize that hidden functionality is an extremely common feature of commercial software! It is so common that a new term has entered the jargon to describe such functionality, the Easter egg. A web search on this term will turn up several indices of such features -- almost every major software product on the market today contains or has contained Easter eggs!
Therefore, I suggest that the Voting System Standards should require the use, wherever practical, of languages that are widely used by large communities of programmers. Section 4.2.1, as currently drafted, merely requires the use of high-level languages, but this is not sufficient. There are plenty of obscure and hard-to-read high-level languages!
I believe that we should not encourage the developers of voting systems to be the first users of new programming languages or new programming methodologies. We should take a conservative stance here, encouraging the use of solidly established languages, languages that are understood by many programmers, and languages for which there are established and widely accepted style guidelines. The set of acceptable languages may change with time, but I would suggest that, to be acceptable, a language should meet the following objective criteria:
Given that it is reasonable to ask that programs be written in languages where there are accepted coding guidelines, and given that the bulk of the coding guidelines for any language will relate closely to that language, we should eliminate language specific style guidelines from the voting system standards!
The primary problem with the bulk of the material in Section 4.2 is that it is specific to the C family of languages (C, C++, Java), despite valiant attempts by various editors to keep it general. I believe that any set of coding standards that descend to this level of detail is bound to become language specific.
There are a few specific details we can demand. It must be possible to print the software on paper without destroying its readability. Some code auditors may wish to perform all or part of their audit on paper, and archival human-readable copies of all source code are essential if we are to avoid relying on any particular software to inspect the code at some later date, possibly much later.
Printable code must fit on the physical page. Requirements such as 80 (or 120) characters per line follow directly from this, so they are reasonable. Formatting requirements beyond this, however, become very difficult.
Therefore, I believe we must take advantage of existing comprehensive coding guidelines for the languages we allow. The vendor of any voting software must select, perhaps improve, and then adhere to some widely accepted guideline for developing software in each language used for developing voting systems. We can demand that certain objective standards be met by these guidelines:
I believe that the software auditor should be invited to comment on the coding standards as part of the audit process. Potential source code auditors under the FEC/NASED standards process (or any successor process) may well want to advertise, to their potential vendor/customers, the kinds of coding guidelines they prefer, but the ultimate burden for selecting appropriate coding guidelines ought to rest with the lead programmers who are in charge of developing the code.
Finally, I want to urge that the vast majority of the language concerning stylistic issues in the coding standards should be in the form of recommendations. Do not say: "No line shall be longer than 80 characters," say: "Ordinarily, lines should be under 80 characters. Exceptions to these recommendations, if they are frequent, may need to be justified by the software developer (perhaps in explanatory comments)." The reason I urge this is simple: Sometimes, the awkwardness of a rule violation is significantly less than the awkward constructs required to avoid that violation. Our goal is to maintain readability, not to nitpick!
There is a huge omission in the coding standards, as they are presented in the current draft. These standards say almost nothing specific to the problem of software for voting systems! They are almost entirely general standards, the same kind of standards I would impose on my students in a third-semester undergraduate programming course.
There are many auditable elements of voting system software that are specific to the voting context. In many cases, auditing these can be difficult unless the top-level design of the system builds firewalls between critical information and software components that should not use that information. I commented on this issue in my January 29 comments, notably with regard to Section 4.2.3 item a and 4.2.6 item i, but also in my comments on Section 6.4 where I noted the value of such firewalls in "walling off" parts of the system that use programming techniques that might otherwise be suspect.
I want to elaborate on this issue because I believe that it focuses attention on what ought to be a central concern in the auditing of the software used in voting systems. Here are some specific examples:
The value of the this counter is not stated in these documents, but it can inferred: The protective counter provides a secure record of the number of ballots counted on the machine during an election -- by subtracting the initial value of this counter when the polls are opened from the final value when the polls are closed. This makes it more difficult for a crook to create votes out of thin air.
Therefore, the protective counter is only of value if it is impossible to for the remainder of the system to interfere with it. In a classic lever voting machine, the counter was a separate mechanical unit, protected by a metal strongbox, security screws and seals, and incremented by an independent linkage to the actuating lever of the voting machine. In a computer-based electronic system, we can ask for firewalls that assure us that the value of the protective counter cannot be seen or modified by any vote-counting code (this is analogous to the role of the sealed box), and we can ask that there be no way to cast a voted ballot without incrementing the protective counter exactly once (this is analogous to the independent linkage to the actuating lever).
Source code auditing should therefore check for inappropriate access to vote totals and subtotals. Ideally, once an electronic ballot image has been constructed, it should be read-only, and the software that inspects one part of the ballot and counts votes on behalf of one candidate should never at the same time have any access to other parts of the ballot or vote totals for other candidates. If the language, operating system or hardware architecture can be rigged to securely compartmentalize this information, the auditor's job can be greatly simplified. The technology needed to do this securely is available in the Java and Ada programming languages, and even in older languages, careful selection of program structures can significantly aid the auditor.
Source code auditing should seek inappropriate use of this information, but if the language, operating system or hardware architecture can be rigged to deny access to this information to the software components of the system that do not need it, the auditor's job is greatly simplified. The technology needed to do this is widely available, even in ancient languages such as FORTRAN.
It is noteworthy that most of the hidden features in commercial software that have come to be known as Easter eggs are triggered by such magic sequences. Testing cannot detect all possible magic sequences that might be used to trigger undocumented behavior because there are infinitely many possible sequences. Source code audits can detect these, but even this is difficult. The widespread presence of Easter eggs in commercial software is evidence of the limited success commercial software firms have had in detecting such features.
I have seen an early version of a commercial DRE machine, the Fidlar and Chambers EV 2000, that accidentally retained information about the selections made by one voter and allowed the next voter to learn how they voted. The vendor corrected this problem promptly, but it should have been caught in the source code audit, and the system design should have prevented the retention of this information.
Source code auditing should therefore seek out evidence that any part of the voting system retains history information that is not necessary for the required function of that part of the system. Languages, operating systems and hardware architectures that limit access to information and that include provisions for forced forgetting of dangerous state information should therefore be encouraged.
This bit of crooked software is quite easy to write if the window manager is given the text of the label that goes with each pushbutton displayed on the screen. On the other hand, if the window manager is only given a graphic image of the ballot, with no hints about what parts of the screen are active and no hints about which pixels are parts of the text of the candidate or party names, the window manager would need to include complex pattern analysis software to understand the ballot. It would be far harder to hide the presence of such an advanced feature than to hide a simple check for a particular party name.
In general, therefore, the code auditor should look for effective isolation between the vote counting code and the names of the candidates and parties. Ideally, most of the counting should be done entirely in terms of ballot style and ballot position, so that even if the programmer strongly favors one candidate, there will be no way to exploit that preference.
The 1990 standard offered a generous exemption from any source-code audit for commercial off-the-shelf (COTS) software components, and this is preserved in Section 4.1.2 and 18.104.22.168 of the most recent draft standard.
I have repeatedly commented on the dangers of this! This subject was central to the E-voting paper I wrote 2 years ago; I recommended tightening this exemption again in my testimony before the US Civil Rights Commission and in my testimony before the House Science Committee last year, and again in my January 29 comments on the Draft Voting System Standard.
I am not alone. The January 30 comments from the Election Integration Project has an extended section on the problems with the COTS exemption. I strongly endorse this warning.
Unfortunately, market forces strongly favor weakening of the already weak COTS exemption, and this is reflected most strikingly in the comments from vendors, including Sequoia Pacific and VoteHere.
As I have pointed out, I believe that the widespread presence of so-called Easter eggs demonstrates quite conclusively that today's commercial off-the-shelf software is not subject to effective internal audits by the vendors. True, most of these Easter eggs are entirely harmless; nobody is harmed by the fact that a complex sequence of actions under MacOS 9 will reveal the names of the programmers who wrote one part of the system. In fact, some Easter Eggs may even be included in the software with corporate approval because they can be used to detect copyright violations -- if your version of the code contains the Easter egg, your claim to have reimplemented the code from the specifications is highly suspect. On the other hand, it is hard to believe that some of these Easter eggs had corporate approval; the most famous example is probably the flight simulator game that was "slipped into" Microsoft's Excel 97.
Two years ago, I proposed a scheme in my E-voting paper that could be used to construct a crooked window manager that would swing close elections in favor of the programmer's favorite political party. This bit of hidden function would appear only on election days, so it would be almost impossible to detect with any functional testing. The amount of programming needed to implement this scheme is far less than the amount needed to include even the simplest of typical Easter eggs in the program, and I think one well placed programmer working for a company like Microsoft, if they got into the right job, could easily include this feature in all production versions of the window manager without the knowledge or cooperation of the company.
I do not believe that we have, today, commercial off-the-shelf components that are rigged this way, but todays DRE voting systems are not yet a big enough target to attract those interested in large scale election fraud. What worries me is the future. It is all too easy to imagine our voting systems evolving to the point where half of all votes cast in the US are cast using machines based on, for example, versions of Microsoft's window manager, where that code remained a proprietary COTS component exempt from source code audit.
If that time comes, the value to the crook of buying the illegal services of a few well placed programmers inside Microsoft would be immense. We must avoid creating temptations of that magnitude, and the only way I can see to do so is to severely limit the class of exempt commercial off-the-shelf components.
I do not wish to imply that Microsoft is in any way intent on corrupting our system of elections, nor do I want to imply that the window manager is the only vulnerable point in the system. That company and that component are merely the most obvious example of a major vendor of a system component that is included in many systems and falls under the COTS exemption. Any vendor of widely used COTS software in the voting system arena poses similar problems.
Having said this, I should note that one example I have cited did suffer from a problem caused by the window manager in Microsoft Windows 95, the the Fidlar and Chambers EV 2000 DRE system. During the development process, an upgrade from Microsoft was incorporated into the system, and this was not rigorously tested or inspected because Windows 95 was classified as an exempt COTS component; one minor feature of this upgrade ended up causing the unintended disclosure of each voter's vote to the next voter using that machine! The vendor corrected the problem in the next version, but the important thing is that this problem remained unknown to the vendor when they brought the system to Iowa for state certification, and we could easily have overlooked it because we rely on the FEC/NASED testing process.
Therefore, I strongly urge that the exemption for COTS software be eliminated or severely limited. There are touch-screen DRE products on the market today that contain no COTS software, most notably the ES&S iVotronic system. If one vendor can do this, others certainly can, but the use of open-source code provides an alternative for vendors who cannot afford to develop new systems from the ground up.
It may be safe for a system to use unaudited COTS software if appropriate defensive measures are taken, but these should be clearly documented and their details subject to careful audit. I have already described how the developer of a voting system could defend against my crooked window manager proposal by presenting the ballot text to the window manager as an image, and I believe that similar defenses are possible against attacks from other unaudited components. The problem is, nothing in the current Draft Standard requires the use of such internal defenses.
If the Voting System Standards completely prohibited the use of unaudited proprietary off-the-shelf software within voting systems, this would not impose an unacceptable cost on the vendors! There are several completely open-source operating systems on the market, the most widely known being Linux. These systems include all of the essential features people expect in a touch-screen internet-capable platform on which voting systems could be developed.
I have pointed this out repeatedly, first, in my E-voting paper 2 years ago, and again last year in my testimony before the US Civil Rights Commission and my testimony before the House Science Committee. I repeated this yet again in my January 29 comments on the Draft Voting System Standard.
Open-source code is no panacea, but at least the source code for the system is publically available, so that anyone, including the source code auditors, can read the code. Of course, the fact that someone can read the code does not imply that they will, nor does it imply that they will understand it. And, even if it is read and understood, we still face a version control problem; we must assure ourselves that the code in the machine is the code that was inspected and approved.
Even if we do not require open source, we can favor products that adopt open standards for the interconnection of the component subsystems of the voting system. An open standard is one that is publically documented, as opposed to proprietary standards, where the details of the standard are hidden. I have pointed this out previously, and I am not alone. The January 30 comments from the Election Integration Project has an extended section on this topic that I strongly endorse.
Today, each vendor's voting system uses proprietary standards for communication between system components. Ballot definitions are communicated to the machine in proprietary format and electronically readable results from the polling place are returned in equally proprietary form. As a result, it is generally impossible for a jurisdiction to mix and match voting system components. Thus, if I want to use ES&S optical mark-sense ballots for vote-by-mail absentee ballots, but I prefer the Fidlar Doubleday DRE machine for early voting at satellite polling places, I cannot easily mix these systems. Instead, as the marketplace is constructed today, I am effectively forced to buy all of my voting equipment from one vendor. The vendors, of course, advertise this as a desirable feature!
Proprietary standards would be bad enough if they merely inhibited the full development of a competitive marketplace, but they do something more harmful, they obscure their own inadequacies! It would be one thing if these inadequacies were only hidden from crooks, but they are also hidden from the customer and from those involved in the FEC/NASED certification process. In fact, in many cases, the use of proprietary protocols has the consequence that even the developer is unaware of the weakness of their own security!
As currently conducted, source code reviews cannot assess the security of the proprietary communication standards used by the vendors. The skilled programmer who may be an excellent source-code auditor is unlikely also to know a sufficient amount about cryptographic protocols to assess the security of the data transmission scheme the code implements. Furthermore, the source code auditors frequently see only one end of the protocol at a time, for example, auditing the voting machine one year, as it is revised, and then at a later date, auditing a new version of the election management system; it is even possible that these audits would be performed by different auditors. The security of a communication protocol cannot be assessed by looking at only one end! The protocol must be examined as a whole, and only after this is there any point in examining the code used to implement that protocol at one end or the other.
My concern about this is not just academic! As a voting system examiner, I have seen several voting systems where the security of the entire system rested on the difficulty a hacker would have in counterfeiting a PCMCIA card, that is, a credit-card sized removable computer memory. Actually substituting a counterfeit card for the official card would be, literally, a simple card trick, and many laptop computers can read and write PCMCIA cards. Therefore, I had to ask how difficult it would be to create a counterfeit.
On investigating this question with various voting systems, I have occasionally learned some extremely alarming things! In a case that I cited in my testimony before the House Science Committee a year ago, I found that the vendor used only one encryption key for all voting systems they made at the time. I hope they have corrected this, because this approach to security has exactly the same shortcomings you would expect to find in an organization where everyone from the janitor to the president was given the master key to all the locks in the building. Nonetheless, the system had been certified to meet the 1990 voting system standard and adopted by several states at the time I discovered this!
While the new draft standards do set higher standards for security, they do nothing to encourage the use of open standards. I would strongly encourage wording that would require the use of open standards except where they can be shown to be insecure or in some other way inadequate. That is, the vendor should be required to make a case for the use of any proprietary standard incorporated into the voting system.
I believe that we cannot afford to allow the entrenchment of direct-recording electronic voting technology until we have incorporated solutions to the problems I have outlined above into the Voting System Standards. Specifically, as a compute programmer, I believe that we as a country cannot afford to risk putting our democracy in the hands of programmers, particularly when there are only weak standards for the auditing of their product and for the control of third party components they elect to use.
I believe that we must work to ensure that optical mark-sense voting remains an viable alternative to direct-recording electronic voting technology. To do this, we must encourage the development of technology to allow handicapped users to use mark-sense ballots, and we must provide the states with the tools they need to assess the often strange relationship between the mark-sense systems they buy and the laws they apply to these systems.
I am concerned that the Commission may defer consideration of these issues until a later revision of the Voting System Standard. I believe that doing so would be dangerous! The market share claimed by direct-recording electronic voting systems is growing very quickly, and if we defer the adoption appropriate regulations, we may be creating a situation where, ten years down the road, election to high office will depend more on what programmers have been bought than on how the voters responded.
In closing, I want to state emphatically that I oppose the use of remote site Internet voting until we have a much greater understanding of how to protect the voting application from the great variety of unaudited third party software that will be very likely to be present on a voter's personal computer.
In the above, I have made reference to the following material, all available on the web: