Not Quite a Blog

A group of California voters[1] filed suit today against the California Secretary of State and all State election officials[2] that plan on using DESI's DRE and optical scan voting machines in upcoming elections. Here is the complaint.

A first glance leads me to think that this lawsuit is going nowhere. I'll have more to say after dinner.

My Take on the Arguments

So the essential arguments in this case are:

1. Using DESI's equipment violates the Voters constitutional rights to vote, have their votes counted and equal protection.
2. The AccuBasic interpreted code is contrary to the federal standards which are adopted by law in California.
3. The CA SoS's imposition of "conditions" on the certification of DESI's equipment was done improperly and illegally (without a public hearing or public scrutiny).
4. The DESI TSx system's VVPAT has not been tested for the 1% manual audit and therefore does not use an "auditable" paper trail as required by CA law.
5. The TSx does not read back the contents of the VVPAT, so it is not an Accessible VVPAT (AVVPAT) as required by CA Law.
6. The TSx does not abide by section 301 of HAVA as it does not incorporate jelly buttons or a sip-and-puff device for people with manual dexterity impairments.
7. The CA SoS improperly shifted liability and delegated his duties for compliance to state and federal requirements to the voting system vendors by adding such language to his certification order.
8. They also throw in a claim related to the failure of local elections officials to properly do the 1% manual audit as required by the CA Election Code.

The only of these I think have a good chance of sticking are items 2, 5 and maybe 8 (although the last seems a bit out of scope for this action). The first two (2 and 5) are just right given the governing law (both systems do contain interpreted code which is forbidden and the TSx does not yet read back the contents of the paper record). However, in the first case, many of us think the standards are just plain wrong. That is, it's not "interpreted code" that we want to prohibit. We want to make sure that the code that is inspected by the ITAs and state evaluators doesn't change from the point at which it is evaluated to the point at which it is used on election day. In that spirit, the section that they site of the 2002 FEC VSS bans dynamically written code and things like that which would be impossible to ensure that they do a single, well-determined operation and don't do something unpredicted on election day.

As for point 5, there's not really a way around it. I know of no vendor's DRE equipment that now reads printer signals or uses optical character recognition to read the contents of the VVPAT back to a voter with sight impairment (a few ballot marking devices such as the AutoMark and Populex systems do this to varying degrees). This, it turns out, is just a hard thing for the vendors to do. As a forthcoming paper of mine highlights, this was even supposed to be accomplished with "open source" software, however that requirement was dropped along with the reading back of paper record contents when the vendors complained loudly enough.

As for the other claims, I just don't think they'll survive very long. I don't think that DESI's equipment will significantly impair people's right to vote if they are used according to the procedures set out by the CA SoS. I think it's perfectly fine for the CA SoS to put conditions on his certification in order to balance the needs of election officials and the defects that all of these systems have. There is no specific language in statutes that require the SoS to test the audit capacity of the VVPAT of voting systems (there probably should be). The TSx allows voters with manual dexterity impairments to use a keypad with large buttons to navigate and vote; of course, a voter that has no use of her hands would need a sip-and-puff device but being "accessible" (according to the DoJ) does not mean accommodating every disability. Finally, it seems reasonable that the SoS would want to indemnify himself by requiring that vendors take responsibility for compliance with federal and state law as a condition of doing business in California.

So why do I think that this lawsuit will go nowhere? Despite the items above which pose serious issues, I think that the practical approach that these systems can be used safely in the short term and their flaws rectified in the long term will be very attractive to any judge that hears this case. I can't imagine a judge granting all the relief they request given the on-the-ground consequences of such an action.

Some other Interesting Features of the Complaint

The complaint claims (page 2, 29 and 37) the VSTAAB team that recommended the mitigation strategies and procedures for the flaws it found doesn't know anything about election procedures and physical security procedures (the language on page 37, for example says, "[T]here is no indication that the VSTAAB panel, made of computer scientists with no demonstrated experience with the actual behavior of poll workers during elections, was qualified to make recommendations on physical and procedural, as opposed to programming, elections safeguards."). While I'm not certain (they cannot comment on pending litigation), I believe their backgrounds in computer security include quite a bit about physical security of computerized systems as that's frequently the only way to compromise highly secure systems. I'm fairly certain that it cannot be claimed that David Jefferson doesn't know anything about physical security and election procedures as he is employed in the field of parallel computing at Lawrence Livermore National Laboratory (a very high security facility) and has been drafting, revising and refining election procedures for many years. They also claim that the VSTAAB report was inadequate as they didn't have access to an entire system and only looked at a very narrow part of the code; however, that was the charge of the study handed down from the SoS.

Further, it appears that paragraph 110 (page 24) is simply wrong as it is taken out of context. The VSTAAB team had full access to the OS and TSx code base and used it accordingly. In addition, they had a stubbed-out version of the code with which they were able to verify that at least one of their bugs would be present in the working system (see below for a discussion of what stubbed-out code is). I suppose a correct version of that paragraph would read something like this:

The VSTAAB Report's authors "did not have access to a genuine running system." Id at 8. Their analysis was based on the complete source code, and they were able to "get a stubbed-out version of the code running on a PC, and were able to confirm that one of the attacks [they] discovered (the only one tried) actually works."

An aside: What is stubbed-out code? Well, if you don't have access to the specific machinery on which a chunk of source code is meant to be built for and run on, it can be difficult to simulate what the actual running environment is. Usually, you have the source code for an application, but you don't have the source or binary of the operating system, libraries used, etc. What can you do to simulate the operating environment? You can stub the code which refers to writing additional code that will mimic the operating system and necessary libraries. This is how they were able to confirm that at least one of the vulnerabilities that they found would be present in a working, running system.

The complaint also claims (page 2-3, 29, 39) that "the code on the AV-TSx memory cards can be manipulated even when [the cards] are inserted and sealed into AV-TSx terminals because those terminals have several access points". If this is true, they need to detail what they know and quick as this could be a major security vulnerability if the memory card's contents are changeable by anyone with physical access, a laptop and a serial cable. This could be related to what the Black Box Voting crew has recently found in testing in Price, UT of the TSx. We're still waiting for BBV to write that test up and notify the proper authorities about the vulnerabilities they found.

In the section where they list their causes of action they repeatedly claim that "Issuance of [writ, relief, etc.] barring the use of the AV-TSx will not substantially interfere with future elections." I can't see any way that barring the use of this equipment would not substantially interfere. The counties that were planning on buying this equipment or that have bought this equipment will be greatly inconvenienced as they would have to re-negotiate with another vendor. I'm not certain (although I'll check) that the standard contracts between counties and vendors allows for some refund of the equipment if barred by a court of law; they'll need this to get other accessible equipment in place by the June 6 primary.

Some nit-picks: On page 19 in paragraphs 89-91, the term "executable code" should probably be "interpreted code"; all computerized systems contain executable code (binary software) of some sort. Page 33, the complaint says the compiler for AccuBasic is resident on the machines. That would be silly in terms of system security and I think a quick check with anyone (Freeman, Wagner, Bishop or Jefferson) would clarify this.

(The thoughts I express here do not represent the position of any research unit with which I am affiliated.)

[1] Joseph Holder, Peter Cantisani, Dolores Huerta, Judy Bertelsen, Charles L. Krugman, David Hague Goggin, Alyce E. Fretland, Helen Acosta, Mary C. Kennedy, Charles Fox, Marty Krasney, Mitch Clogg, Ben P. Van Meter, Nancy Tilcock, Charles O. Lowery, Jr., Lillian Ritt, Harold C. Case, Susan J. Case, Kenneth Martin Stevenson, Larry Marks, Harry John Rapf, Merrilee Davies, Bernice M. Kandarian, Victoria Post, and Veronica Elsea

[2] Bruce McPherson (CA SoS), Elaine Ginnold (Alameda), Victor E. Salazar (Fresno), Carolyn Wilson Crnich (Humboldt), Ann Barnett (Kern), Theresa Nagel (Lassen), Conny McCormack (Los Angeles), Michael Smith (Marin), Marsha Wharff (Mendocino), Maxine Madison (Modoc), Jim McCauley (Placer), Mikel Hass (San Diego), Debbie Hench (San Joaquin), Julie Rodewald (San Luis Obispo), Joseph E. Holland (Santa Barbara), Colleen Baker (Siskiyou), Dero Forslund (Trinity), Jerry T. Messinger (Tulare) and Does 1-50 (These Does encompass basically anyone who is planning on doing business with Diebold Election Systems Inc. to purchase either the AccuVote-TSx (DRE) or AccuVote-OS (optical scan))

UPDATE [2006-03-22T12:29:38]: Changed "nuclear research" to "parallel computing" as David Jefferson's field and added a note about the level of security at LLNL. Of course, this doesn't mean he's an expert in physical security control, but it does mean that he's lived with it quite a bit. Other VSTAAB members cannot comment on pending litigation.

UPDATE [2006-03-23T11:42:23]: Added the three paragraphs about stubbed-out code.