Using Tech To Fix Elections
May 27, 2004 6:00 AM PT
The U.S. 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, thus leaving local election officials across the country pretty much on their own, first with the election and then with the lawsuits afterward.
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 entire 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 nonexistent. 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 both for vote tallies and for the electronic audit trail -- meaning 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.
Electronic Voting: Criminally Stupid?
As many people have pointed out, the reliance on buyer naiveté underlying the typical direct recording electronic (DRE) voting machine 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 utilized.
- 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. There are several organizations, such as the Verified Voting Foundation started by Stanford's David Dill, dedicated to making this obvious to electoral officials. Unfortunately, most of those officials don't read Web sites like his and seem largely unaware either of the extent of the problem or that other options exist.
It's Really Very Simple
When you think about it, however, the requirements for a successful electronic voting system are really very simple:
- The eligibility verification process must not combine with the electronic voting record to reveal the choices made by individual voters. The existence of such a connection, by the way, is an artifact of time-stamped audit trails -- but all of the currently available commercial systems I've looked at still allow this to occur. 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 afterward, and thus do away with the fundamental protections offered by the secret ballot.
- The electronic system must produce a paper record that the voter can verify on the spot and then deposit in a traditional ballot box for use in traditional hand-counting processes. 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.
- The vote-accumulation process must be fast, accurate and manually verifiable without allowing illegal access anywhere in the process.
It's not hard to design a system to do this. In fact, the rest of this column will sketch out the hardware component of such a solution, while next week's column will look more closely at the software and controls needed. That's backward, of course, because 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, you need to understand the hardware architecture to understand what software is needed -- and, more importantly, what isn't needed. Second, almost all of the software will be freely available open-source stuff with deployment, but not licensing, costs.
The Process Perspective
In this case, the architecture is conceptualized as a hierarchical network laid out using Sunray smart displays in the voting booth. Local Sun servers 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 and smart-display combinations can come from other competitors without significantly affecting overall operations.
From a process perspective, the key steps would be:
- The voter sees a Web page, makes choices using a touch screen (or voice for some handicapped displays), receives a printed card documenting the vote, and deposits that card in a standard ballot box on the way out. 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, let's just assume 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.
- In preparation for the election, officials would prepare ballots as ordinary text files for automatic processing into the Web pages voters see. That process would ensure ballot correctness, standardization and the inclusion of national and state items while allowing local officials maximum freedom to make easily understood changes and updates right up to the last minute.
- Each polling place would have one or more voting stations, plus at least one training station with someone available to help voters understand and use the process.
- Election officials at the polling place login each smart display using an assigned ID that identifies the device. Both the Sunray and local Web services are handled by a nearby server, but ballot submissions are automatically routed to state servers, where they are added to transaction tables defined by unique ballots. As will be noted in next week's column on the software for this, serialization will replace the timestamp for audit purposes to break the link between the time the voter leaves the booth and the voting record compiled at the state level.
- Recounts, disputes and audits are all handled in the traditional way using the paper ballot -- and, of course, local authorities wishing to do so can use these as the basis for official results.
So, what would all this cost? About 60 percent less than using Diebold or similar technologies.
According to The Maryland Gazette, Maryland paid about US$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 up those numbers to the national scale, and you get a low-end estimate of about $4 billion without printed audit trails and a high-end estimate well north of $5.5 billion with printing.
A Win for Everyone
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 $2 billion nationwide. 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 facilitate things -- if implemented -- would be finding a use for the technology during nonelection days by installing it in schools and making 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 the year 2000, more than half were in schools, so consolidation, either to schools or to temporary facilities placed adjacent to school grounds, should be possible in 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 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-plus percent of the system's lifetime with local cooperation could make it possible, thereby creating a significant win for everyone involved -- especially the taxpayer.
Here's what an implementation would take from a hardware perspective. First, we'd need 750,000 combination Sunrays with card printers. Assuming the printers are custom-produced at $400 each, the base 17-inch touch-screen-equipped Sunrays come in at $650 each, and the one machine in 10 equipped for handicapped access has double the base cost, the total for the displays would come in at just under $950 million.
On average, this would give each of the estimated 70,000 polling places 10 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 percent. At peak times, if two-thirds of the voters show up during a span of three hours, each voter would have about 90 seconds before lines started to build.
The training and control unit would come equipped with an attached XVGA-class wall projector. This would be used to show about a two-minute video introduction to the voting technology on a continuous loop. At current prices, 70,000 midrange units would add about $60 million to the cost.
The database add-transactions triggered by a ballot submission need to happen at the highest level consistent with vote tabulation requirements. Ideally, therefore, database servers would map to the state level, with county and similar smaller-jurisdiction results produced as reports drawn from the main database. We might reasonably, therefore, think in terms of 50 local data-processing centers and two national centers, each with dual, independently administered ballot transaction systems.
Since these machines would just run the database for very simple add transactions, they could be quite small, despite having to be configured to handle relatively high peak volumes. States with 2 million or fewer expected voters could 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 might 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.
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 $40,000 machines with one CPU assembly. That type of throughput-oriented technology also will cut smart-display support costs dramatically, but it won't be available this year -- although it will probably be in wide use by 2008.
The server capacity needed to run the Sunrays and local Web servers is far larger, with the actual number and sizes to be determined by the scale and telecommunications requirements associated with polling locations and collocations. From a cost perspective, the worst case would require an independent server for each of the 70,000 polling locations. In that case, each server would be limited to an average of 12 devices -- meaning we'd need 70,000 Sun V240s at $6,600 each, including a small UPS and local cabling, for a total cost in the range of about $460 million.
Twenty Cents on the PC Dollar
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 preexisting internet connection -- and a $2 billion total, or about half the amount authorized 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:
- Use of the Sunray as the primary collection device, coupled with the duplicate paper ballot, secure communications and the built-in audit processes, ensures that this system can be made trustworthy, vote counts can be independently verified, and the inevitable lawsuits can be settled on the basis of fact rather than supposition.
- From a capital-cost perspective, the complete system costs about 60 percent less than major alternatives such as those from Diebold. In addition, training and utilization costs are significantly lower, while election-day emergencies are relatively unlikely to occur.
- Systems like those from Diebold gather dust between elections. In contrast, the Sun-based system suggested here should be used in schools both to provide services directly and to ensure that installations are fully debugged and ready to go for local, state or national elections.
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 20 cents on the PC dollar for equivalent or better services.
Paul Murphy, a LinuxInsider columnist, wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry, specializing in Unix and Unix-related management issues.