- by Paul Murphy, -
The US Federal Election Assistance Commission under chairman DeForest Soaries has the unenviable job of recommending standards and procedures for electronic voting in time for use in the 2004 federal election. The commission's freedom of action is obviously time constrained but, less obviously and more importantly, it's also constrained by available technologies, jurisdictional issues, and popular assumptions about what the right technology should look like. Realistically, therefore, the commission can be expected to issue some best practices guidelines about things like the need for audit trails and thus leave local election officials across the country pretty much on their own first with the election and then with the lawsuits afterwards.
It doesn't have to be that way; in fact this column and next week's are devoted to the presentation of an alternative vision for election technology and thus an escape from failure for the commission.
At present the whole electronic voting process is a mess. Neither voters nor election officials have the experience and training needed to use the technologies; audit trails are functionally non existent; the processes of vote accumulation across states or even precincts are easy to corrupt, and the majority of voting machines use absurdly vulnerable Microsoft technologies.
Diebold, for example, relies on precinct level use of Microsoft Access for both vote tallies and the electronic audit trail - meaning that anyone with physical access to a database host anywhere in the accumulation process can rather easily rewrite both the election results and the matching audit trail.
As many people have pointed out, the reliance on buyer naivete underlying the typical Direct Recording Electronic voting Machine [DRE] design is almost unbelievable. For example, here's what noted security expert Aviel Rubin had to say to the commission:
My primary concerns with today's DREs are:
- There is no way for voters to verify that their votes were recorded correctly.
- There is no way to publicly count the votes.
- In the case of a controversial election, meaningful recounts are impossible.
- The machines must be completely trusted. They must be trusted not to fail, not to have been programmed maliciously, and not to have been tampered with at any point prior to or during the election. We have techniques for building secure systems, and they are not being utilised.
- With respect to the Diebold Accuvote TS and TSx, we found gross design and programming errors, as outlined in our attached report. The current certification process resulted in these machines being approved for use and being used in elections.
- We do not know if the machines from other vendors are as bad as the Diebold ones because they have not made their systems available for analysis.
With objections like this, going ahead with electronic voting should be considered criminally stupid and there are several organizations, like the verified voting foundation started by Stanford's David Dill, dedicated to making this obvious to electoral officials. Unfortunately most of those don't read web sites like his and seem largely unaware either of the extent of the problem or that other options exist.
When you think about it, however, the requirements for a successful electronic voting system are really very simple:
This, by the way, is an artifact of time stamped audit trails and something that all of the currently available commercial systems I've looked at do because the party representatives at the polling place need only record the time people leave the booth to have a good chance of correctly matching individuals to votes afterwards, and thus do away with the fundamental protections offered by the secret ballot.
Note that this piece of the voting process is similar to one suggested by the Open Voting Consortium. That group, led by Alan Dechert, is focused on developing an open source software solution for touch screen voting based on the use of "less expensive" PCs and thus shares my commitment to the open source philosophy but has a radically different view of the appropriate technology on which to implement it.
It's not hard to design a system to do this. In fact, the rest of this column will sketch the hardware component of such a solution while next week's will look more closely at the software and controls needed. That's backwards, of course, since it's more usual to sketch the requirements first, then the software, and lastly the hardware. I reversed the order here for several reasons: first because you need to understand the hardware architecture to understand what software is needed - and, more importantly, isn't needed - and, secondly because almost all of the software will all be freely available open source stuff with deployment, but not licensing, costs.
In this case the architecture is conceptualised as a heirarchial network laid out using Sunray smart displays in the voting booth, local Sun servers to run the Sunrays, with state and national database accumulators to provide totals. Notice that I cite Sun hardware and compatible software everywhere but, in reality, everything except the local server/smart display combinations can come from other competitors without significantly affecting overall operations.
From a process perspective the key steps would be:
There are some interesting issues about limiting voters to one vote and recovering from voter error here that need to be resolved in the software. For now, however, lets just assume that the actual electronic submission is triggered by print completion, not the "submit vote" button triggering printing.
As part of the audit process some voters may be asked, as they deposit this ballot, to verify that the choices shown are correct. Note too that some current or pending state legislation contemplates leaving a record in the hands of the voters. If this applies somewhere, a visually differentiated second version could be printed.
As noted in next week's column on the software for this, serialisation will replace the timestamp for audit purposes in order to break the link between the time the voter leaves the booth and the voting record compiled at the state level.
So what would all this cost? About 60% less than using Diebold or similar technologies.
According to the Maryland Gazette Maryland paid about $73 million for a Diebold system with 16,000 terminals or just over $4,500 each -and that was before an anticipated additional $20 million or so to add printers. Similarly a story in the Daily Journal shows that Indiana's Johnson County paid $2.42 million, or $5,307 per unit, for 456 iVotronic machines from Election Systems & Software.
Blow those numbers up to the national scale and you get a low end estimate of around four billion dollars without printed audit trails and a high estimate well north of $5.5 billion with printing.
In contrast a Sun system would not have any of the security, reliability, audit, or usability problems that go with machines like Diebold's while its capital costs, as we'll see below, wouldn't reach two billion nation wide.
The technology for this is straightforward, but the politics involved make it difficult to see how such a system could be made to happen.
One idea that would greatly faciliate things if implemented would find a use for the technology during non election days by installing it in schools and thereby make it available for educational use. Thus all polls would need to be placed inside, or physically very near, schools.
Of the 140,000 or so polling places nationwide in 2000 something over half were in schools so consolidation, either to schools or to temporary facilities placed adjacent to school grounds (i.e.within cable reach) should be possible for the majority of jurisdictions. Most schools, of course, either have or can get via existing independent federal and state programs, reasonably fast internet access of the type needed to connect the vote collection system to the vote tabulation system. In general, therefore, school placement of polling stations kills two birds with one stone: reducing communications complexity on election day while ensuring the usefulness of the system between elections.
This is impossible within current administrative realities at local, state, and federal levels. However, the combination of federal legislation giving the electoral commission itself responsibility for the system during elections and passing control to local educational authorities during the remaining 99.5+% of the system's lifetime with, admittedly unprecedented, local co-operation could make it possible and thereby create a significant win for everyone involved - especially the taxpayer.
Here's what an implementation would take from a hardware perspective:
On average, this would give each of the estimated 70,000 polling places ten regular displays, one handicapped access station, and one training and control display. That works out, on average, to one display per 300 registered voters or one per 176 actual voters if turnout hits 60%. At peak times, if two thirds of the voters show up during a total of three hours, each voter would have about 90 seconds before line-ups started to build.
Since these machines would just run the database for very simple add transactions they can be quite small despite having to be configured to handle relatively high peak volumes. States with two million or fewer expected voters can be expected to produce momentary peak rates on the order of perhaps 300 updates per second while bigger states, particularly California, could easily hit 15,000 transactions per second.
Those numbers may seem large, but the transactions are trivial and most of the hardware burden will be on communications rather than transaction processing. As a result these loads translate to hardware requirements ranging from a V440 (4 US3i CPUS) in small states to a Sun 6900 (20 USIV CPUs) in California. For our estimate we can assume, therefore, an average cost in the range of a loaded V880 (8 US3 CPUs) with dual 3310 SCSI arrays at about $140,000 each or roughly $160 million nation-wide.
Interestingly, Sun's forthcoming Niagara eight way CPU with hardware TCP/IP and SSL offloads promises the ability to handle loads like California's on $40K machines with one CPU assembly. That type of throughput oriented technology will also cut smart display support costs dramatically, but won't be available this year - although it will probably be in wide use by 2008.
These numbers suggest a rough total in the range of $1.65 billion before volume discounts and connection, training, or configuration services. Add the net cost of services and the higher costs incurred to make the system work in places where something doesn't fit the mold - say a polling place at a school or other site without a pre-existing internet connection - and a two billion dollar total, or about half the amount authorised under 2002's federal Help America Vote Act, might be realistic.
Of course there will be some areas where traditional methods have to be used as well as some, particularly for military and overseas voting, where other federal programs claim priority. On the whole, however, this idea offers three tremendous advantages over Windows based alternatives like Diebold's:
As we'll see in next week's column on the processes, software, and controls needed, training school IT administrators to work with these systems both during elections and during regular school schedules is a big issue. Once that's done, however, there is another enormous potential advantage here for the taxpayer, because the Unix business architecture - Sun servers with Sunrays - runs about twenty cents on the PC dollar for equivalent or better services.