For this first of several reports from the NIST/EAC Future of Voting Systems Symposium II, some readers of my recent report on standard work, may heave a sigh of relief that I’m not doing a long post that’s a laundry list of topics. However, I will be doing a series of posts on one part of the conference, a session held by some EAC who run the voting systems certification program, which relies on a “guidelines” document that is actually a complex set of standards that voting systems have to meet in order to get certified.
The reason that I am doing a series of posts is that the session was on a broad topic: if you were able to write a whole new requirements document from scratch, oriented to future voting systems, not required to support the existing certification program backwards-compatibly, then … what would you put in your hypothetical standards for each of several topics? Not surprisingly, I and my colleagues at TrustTheVote (and like minded folks in the election world more broadly) have some pretty clear views on many areas. As promised to the folks running this session, I’ll be using this blog to document more fully the recommendations we discussed, informed (with thanks) by the views of others at this conference. But I’ll be doing it in chunks over time, because I don’t think anybody wants tome here. 🙂
The Fork in the Road
The zeroth recommendation — that is, before getting to any of the topics requested! — is about the overall scope of a future standard. In the decade or so since the current one was developed (and even more years to the earlier versions), things have changed a lot in the election tech world, and change is accelerating. We are no longer in the stage of “wow that hanging chad fiasco was horrible, we need to replace them fast with computerized voting machines.” We’ve learned a lot. And one of the biggest learnings is that there is a huge fork in the road, which effects nearly all the requirements that one might make for voting systems. That’s what I want to explain today, in part because it was a good chunk of the discussions at the conference.
The fork in the road is this: you either have a voting system that supports evidence-based election results, or you don’t.
In this context, evidence-based means that the voting system produces evidence of its vote tallies that can be cross-checked by humans — and this is the important part — without having to trust or rely on software in any way. That’s important, because as we know, software is not and can never be perfect or trustworthy. In practice, what this means is that for each voter, there is a paper ballot that can be counted directly by people conducting a ballot audit. The typical practice is to take a statistically significant group of ballots for which we have machine count totals — typically a whole precinct in practice today — and manually count them to see if there is any significant variance between human and machine count that could indicate the machine count (or the human audit) had some errors. The process for resolving the rare variances is a larger topic, but the point here is that the process provides assurance of correct results without relying on computers working perfectly all the time.
That’s not the only way to build a voting system, and it’s not the only way to run an election. And in the U.S., our state and local election officials have choices. But many of them do want paper-based processes, to complement modern use of ballot marking devices for accessibility, ballot counters, ballot on demand, ballot readers for those with impaired vision, and a host of technical innovations emerging, including such things as on-boarding processes at polling places, interactive sample ballots for home use, and more. And for those election officials, the evidence-based voting systems have some important requirements.
The Harder Path
But let’s respect the other path as well, which includes a lot of paperless DRE voting machines still in use (and also some internet-voting schemes that several elections orgs are experimenting with). A lot of voters use these older systems. But there is a big difference in the requirements. Indeed, the bulk and complexity of the early requirements standard (and its larger 10-year-old successor) is due to trying to encompass early DRE based systems. Because these systems placed complete reliance on computers, the current requirements include an enormous amount of attention on security, risk management, software development practices, and more, all oriented to helping vendors build systems that would to the extent possible avoid creating a threat of “hacked elections.”
In fact, if you read it now, it looks like a time warp opened and a dropped through a doc from 2004 or so; and it reads pretty well as good advice for the time, on how to use then-current software and systems to — pardon me for the vernacular — “create a system that is not nearly as easily hacked as most stuff being made now.” (This was in windows XP days, recall.)
I suppose that some updated version of these requirements will be appropriate for future non-evidence-based voting systems. It will take a while to develop; it will be a bit dated by the time it is approved; and its use in voting system development, independent testing, and certification, will be about as burdensome as what we’ve seen in recent years. It has to be done, though, because the risks are greater now that ever, given that the expertise of cyber-adversaries continues to expand beyond the ability of the most sophisticated tech orgs to match.
The Road Not Taken?
So my 0th recommendation is do not apply these existing standards to evidence based voting systems. I’d almost like to see the new standard in two volumes – one for evidence based and one for others. It would just be a crazy waste of people’s time, effort, energy, and ingenuity to apply such burdensome requirements to evidence based systems, and ironic too: evidence based voting systems are specifically defined to entirely avoid many risks — in fact, the exact risks that the current requirements seek to mitigate! In fact, I would almost recommend further that the new version of the EAC start getting input on how to develop a new streamlined set of voting system requirements specifically for evidence-based systems. I say “almost” because I started to see exactly that starting to glimmer at the NIST/EAC conf this week. And that was super encouraging!
So, my specific recommendations will be entirely focused on what such new requirements should be for evidence-based voting systems. For the other fork in the road, the current standards set a pretty good direction. More soon …