I had hoped to spend today at the annual conference of the Election Verification Network (EVN) and in particular taking part in a panel on electronic pollbooks. Alas, I was unable to travel and the panel was canceled. However, one of of the other panelists blogged about what he would have said. I’ll post a rough draft of my own comments here and we’ll be well on our way to an online panel.
Electronic pollbooks have been proposed and deployed in order to serve a wide range of objectives. These varying objectives drive varying system architectures, which in turn have substantial implications for reliability, security, and verifiability. Thus, even though electronic pollbooks have already become routine in much of America and seem likely to become ubiquitous, we should beware of thinking of them as a single monolithic category.
The most basic objective is to avoid the time, expense, and risk of errors that stem from translating data from digital form to hardcopy and then back again. In particular, it is the return trip — the posting of voter history after the election — that seems to be the biggest concern. That’s one reason why an electronic pollbook may make sense even if a paper roster is still printed for backup purposes.
Another fundamental objective is to reduce the time spent checking in each voter and the risk of accidentally checking a voter in under an adjacent name. Saving time at the check-in station can translate to fewer stations and fewer poll workers, at least for large, busy polling places. Given the difficulty election administrators have in hiring enough poll workers, reduced staffing can be important even if the overall labor plus equipment costs roughly balance out, which seems to be the case.
These fundamental objectives can be met using an offline system architecture that closely parallels printed rosters. Each computer used at a polling place can operate entirely independently. Printing the roster in advance of the election is paralleled by loading data onto the computer’s storage device before it is deployed. Positing voter history after the election is paralleled by reading data back from the storage device once it is returned to election headquarters. Because the computers do not need to be networked, security considerations are simplified, though of course not eliminated. Reliability and verifiability concerns exist even with such a simple architecture. In fact, storing data on local devices can be rather risky from a reliability standpoint; that may be one consideration, along with support for additional objectives, that has driven electronic pollbooks to more sophisticated architectures. However, we shouldn’t lose sight of the reliability advantages of independent operation. Not only is the impact of any failure localized, but also the potential causes for failure are minimized — communication interruptions and server overloads are non-issues. Moreover, the system is comparatively straightforward to test and nothing is likely to change between the time of testing and Election Day. These advantages are substantial enough that we ought to think about the degree to which they can be maintained as we consider more sophisticated architectures. Architectures based on small-scale interconnection may be preferable to large-scale, and those that can continue operating even with intermittent connectivity may be preferable to those that require fully online operation.
Although an electronic pollbook system can be imagined that addresses only the previously mentioned objectives, I am not aware of any actual system development project that stopped at that point. (I will admit that my knowledge is quite limited and haphazard.) It seems that every electronic pollbook developer wants to address at least one more objective: eliminating the assignment of voters to specific check-in stations that are dedicated to individual portions of the alphabet. Allowing each voter to check in at the next available station can further reduce the number of poll workers. Also, there is a benefit for the voters, who no longer have to worry about being in a particularly long or slow-moving line or, worse yet, the wrong one.
Supporting this ability to check in at any station in the polling place requires some amount of networking. However, I have seen it done with a dedicated, wired network confined within the polling place — in some cases as little as a single crossover cable connecting two computers. That leaves the security, reliability, and testability advantages discussed previously largely intact. A wireless network within the polling place may increase flexibility and better accommodate tablet devices. However, it does substantially ratchet up the amount of care that needs to be taken with security. Whatever form of networking is used within the polling place, it can also help mitigate reliability problems if data is mirrored between the computers. That is, if a copy of the data resides on each computer, and voting history is updated on all of them no matter which computer a voter checks in at, then even the complete failure of a computer and its storage device will leave the remaining computers fully functional. Note that the existence of networking within a polling place does not in itself ensure that data will be mirrored. For example, in the Precinct Atlas system developed in Cerro Gordo County Iowa, the data is only stored on a single master computer in each polling place, with the other computers reliant upon it for continued operation. As I’ll discuss shortly, this system uses a different approach to protect against data loss, coupling it with verifiability and other functionality.
Even with each polling place operating independently, electronic pollbooks can, and do, support other election administration functions. One category is the handling of exceptional circumstances: voters who are at the wrong polling place, unregistered, or need to update their registration information. This was the motivation behind the development of the Precinct Atlas system and explains its name. The system was designed to guide poll workers through the sometimes labyrinthine process of selecting the appropriate form and ensuring it is properly filled out, whether for Election-Day registration, change of address, or provisional balloting. Because Iowa adopted Election-Day registration too recently to be exempted from the federal motor-voter and HAVA requirements, it faces a more complicated set of procedures than states with longstanding Election-Day registration or none at all. That complexity translates to greater stress on the poll workers and a greater risk of error. It was these issues, rather than saving cost or transforming the voting experience, that motivated the development of this system.
This context helps explain the Precinct Atlas’s unusually paper-centric design, which has important benefits for reliability, transparency, and verifiability. Every single transaction on a Precinct Atlas system results in a paper form. In the normal case of checking in a properly registered voter, the system prints a receipt which the voter signs and trades for a ballot, at which point the signed receipt is spindled. In cases where registration or change-of-address forms are needed, the system prints labels that are stuck onto standard pre-printed forms, covering up the blanks with the data that should go in those blanks. Under ordinary circumstances, with no system failure, the signed voter receipts are used only as an audit trail — the voter history is posted digitally, without requiring data entry. However, the other forms, which are much fewer in number, are still entered manually. The system developers apparently thought it was enough progress to provide the data-entry clerks with legible and correctly filled out forms, rather than trying to put those clerks out of business entirely.
Another area where even offline electronic pollbooks might support election administration is in the enhanced verification of voter identity. Note that I am not making any claim that in-person voter impersonation is a real problem. I’m simply pointing out that election administrators in many jurisdictions have needed to respond to this concern, and that electronic pollbooks may play a role. The Caltech/MIT Voting Technology Project’s recent report, “Voting: What Has Changed, What Hasn’t, & What Needs Improvement,” envisions a system in which “Instead of asking a voter to present government issued photo identification at the polling place, a voter’s identity could easily and quickly be confirmed by a pollworker who has access to an electronic pollbook that contains both the voter’s registration information and the current photographic identification that is on file with the state.” This same vision has been championed by the Minnesota and Nevada Secretaries of State, Mark Ritchie and Ross Miller.
The Caltech/MIT report also suggests that voters who don’t have photos already on file be photographed at the polling place. This is one area where policymakers ought to be cautious about the implications of policy decisions for system architecture. Mark Ritchie has suggested that polling place photos could be immediately sent from the polling place to a central server for real-time facial-recognition matching against the database, providing a safeguard against false identities and double voting. Although I understand the political pressures he faced at the time he made that suggestion, I would be very wary of any policy that presumes continuous high-bandwidth connection of each polling place to a central server. I would be much more comfortable with a policy that allowed photos to be uploaded and checked after the election was over, with immediate checking perhaps preserved as an option for those polling places that have connectivity that is functioning at the appropriate moment.
Intermittent, partial connectivity from polling places to a central server is already serving other objectives, for example in Cerro Gordo’s Precinct Atlas system. The original version of that system operated with no connection beyond the polling place during the course of the election. Later, the system was upgraded so that those precincts that were able to establish a connection to a central server could use that connection for extra functionality. (Except for one precinct located at the county government center, the connections are established using cellular modems and so depend upon the carrier’s areas of coverage.) Even those precincts that connect need not have continuously functioning connections, and indeed in my observation did not.
One important use of the county-scale networking is to reduce the labor involved in coordinating the records for in-precinct and absentee voting. This includes preventing someone from voting in the precinct who has cast an in-person absentee ballot the afternoon before the election at the county auditor’s office. Another objective achievable even with intermittent, partial networking is better tracking of how the election is going. Is some precinct overwhelmed with voters or in need of more ballots? In the Precinct Atlas system, this reporting functionality was taken beyond aggregate statistics to immediate posting of individual voter histories. The county auditor’s office makes this information available in real time to the political parties as an alternative to their traditional use of poll watchers.
My understanding is that this objective of supporting the parties’ get-out-the-vote efforts was the motivating force behind the precincts posting their voting history to the central server when and as they are able. However, it winds up having an impact on reliability as well. Part of that impact is negative, from increased complexity. However, part is salutary. In particular, if a precinct loses its locally stored record of voting activity, that record does not need to be entirely reconstructed from the spindled voter receipts. Instead, the most recent checkin with the central server can be used as a starting point, with the spindled receipts only used for the more recent activity — or in a rural precinct that had no connectivity.
All the objectives discussed heretofore are minor improvements on traditional precinct-based voting. By contrast, electronic pollbooks have also been seized upon as an enabling technology for Election-Day vote centers. Under this model, a county provides a limited number of large vote centers and allows each voter to freely vote at any vote center in the county. This approach was pioneered by Larimer County Colorado and has in the intervening decade spread to other counties both in Colorado and in other states, such as Indiana. Vote centers have been varyingly portrayed as increasing voter convenience, reducing costs, or easing compliance with HAVA’s accessibility requirements.
Because a voter can check in at any vote center but must be prevented from voting more than once, the obvious system architecture is to have each transaction processed online using a central server. All of the vote-center electronic pollbooks I am aware of take this approach, though the details vary. For example, the original Larimer County system used remote desktop software on the polling place computers to access a specialized user interface program hosted on servers, whereas the system deployed in Denver in 2006 required only standard web browsers. Regardless of the details, the security, reliability, and verifiability of such a system present considerable challenges. The prominent computer scientist Leslie Lamport defined a distributed system as being “one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” In the elections context, that means preventing voters from voting. Moreover, any system is most failure prone when first deployed. Election-Day systems pop up in locations that were serving a different function the day before; they also face particularly intense customer loads immediately upon opening in the morning. The one saving grace is that vote centers are typically few in number and can generally be furnished with better connectivity and more attention from technical staff than is possible at the precinct level.
The Denver experience in 2006 is a sobering example of what can go wrong. Consultants from Fujitsu were hired immediately after the election to conduct an assessment. Their report indicates that missteps “led to unacceptably long waiting times for voters and an abandonment rate estimated at 18,000-20,000 voters (approximately 20% of the anticipated physical turnout on Election Day).” That same report points to many of the underlying causes of that meltdown, which not unexpectedly are as much managerial as technical. I imagine that every election administrator would like to think themselves more competent than to stumble into such pitfalls. However, the Denver administration presumably thought the same. Some of the blame, as the report makes clear, lies with choosing an unnecessarily high-risk system architecture, so that both the chance of failure and the consequence of failure were magnified. To err is human, but to create a full-scale disaster, it helps to have a whole bunch of interdependent computer systems.
The Denver experience also serves as a reminder of the limited ability of contingency plans to mitigate failures, such as by falling back on a local copy of the rosters. Not only must these plans be well rehearsed and capable of scaling to realistic loads, they must also, most fundamentally, be put into play. It is all too common to continue trying to troubleshoot Plan A long after Plan B should have been deployed. In Denver, the consultants report, “The second line of defense, abandonment of the ePollBook in favor of a local poll book copy, was never executed, although circumstances arguably warranted that this drastic measure be taken.”
An interesting question is whether a vote-center system could be designed that would inherently retain some functionality in the face of intermittent connection. A study by Ball State University’s Bowen Center for Public Affairs shows that more than 80% of voters choose to vote at the vote center nearest their home. One can imagine a system architecture in which Election-Day information about a voter is maintained not on a central server, but rather at that voter’s predicted vote center. If the voter chooses to vote elsewhere, the system where they vote would need to communicate with their “home” system. However, voting at one’s predicted vote center wouldn’t require any communication. Any disruption to communication would have no impact on the large majority of voters, and the remainder could simply be told where to go vote. The reliability and performance of this architecture could also be enhanced by having vote centers mirror their data to a central server when they are able to.
Another suggested objective for electronic pollbook systems would require an even more ambitious architecture than vote centers do. In 2011, the Minnesota legislature passed a bill, subsequently vetoed by the governor, that would among other things have substantially tightened the eligibility checks performed at the polling place on Election-Day registrants and those checking in to vote. In order to support this, the bill as originally introduced would have required all but the smallest precincts to have electronic pollbooks that processed each transaction online with a statewide server. That is, the system architecture would have been similar to that used in vote-center counties, except that it would reach to thousands of individual precincts spanning an entire state.
Eventually the legislature became convinced that this plan was over-ambitious and scaled it back to traditional offline pollbooks augmented with a list of ineligible voters, such as Wisconsin has been using. For a harrowing period of time, though, this unprecedentedly ambitious scheme was justified by pointing to the success of small-scale, offline use of electronic pollbooks in one Minnesota city. This lesson I learned is that it is initially easy for policy makers to mistakenly lump all electronic pollbooks together, generalizing from experience with one system to another, quite different one. However, once they are educated about the connections between system requirements, system architecture, and risk, they can make more nuanced distinctions. In the MInnesota debate, fiscal considerations also played an important and more publicly visible role. However, my impression is that risk was a substantial consideration. I suspect that EVN members will work to ensure it plays a role in similar conversations across the country on how electronic pollbook systems ought to be designed and deployed.