Part 4

When we last left the discussion in Part 3, we looked at the 5 big technical challenges to an adoptable, credible, and defensible iVoting system.  So let's set aside for the moment the resolution of those five elements that you'll recall are:

1. Strong authentication;

2. Digital enveloping;

3. Digital ballot box + server integrity;

4. Client (App) integrity; and

5. End-to-end verifiable ballots.

Notwithstanding all those necessary components, and accepting only what technology we have today, there are many different ways people might think of creating an iVoting system. One could imagine a system where voting runs as an App just like any other on your smartphone. Or you might imagine a system where voters vote on their local precinct’s web site. So how do we know which voting system we should try to design?

We at the OSET Institute believe that any form of iVoting system must be compatible with the policies and regulations of the current typical election system and processes. That is to say,  an adoptable and deploy-able iVoting system cannot require a complete overhaul of elections (e.g., Processes, Platform, and Policies).  It is unlikely that such a system would be accepted by election officials and legislators.

At the most basic level this means that a system only allows registered voters to cast ballots and that each registered voter only votes once. But there are additional restrictions to be considered.

So what kind of restrictions do we mean?

• A first example of a restriction, as discussed earlier, is that iVoting would only be one of many streams of voting. Voters would still have to be able to vote in-person at their local precinct or by mail. This means that any iVoting system design must have a digital ballot.  It cannot be immediately counted because if it were then it would be quite simple for a voter (either maliciously or by mistake) to cast a ballot twice as they could vote online and then also vote in-person. According to current rules and regulations that in-person vote is the one that should be counted, not the absentee vote, and so the Internet vote must wait to be counted until it can be cross-references with other voting channels. Election officials must be able to tally these digital ballots in a process that fits with other ballot casting streams so that results from the various voting methods can be easily combined and they must be verifiable (audit-ready) just as paper ballots are.

This digital ballot would also have to adhere to existing standards.  You see, ballots must conform with legal requirements and state-specific regulations.  Any digital ballot will have to match those requirements to be considered an authentic, authorized, certifiable, legal ballot.

• Another example: when ballots can be rejected. Imagine a system that uses iVoting and simply detects if a ballot has some sort of malware or virus on it and rejects it if such conditions are present. That way the integrity of the system, at least to the degree that malware can be detected, is assured. But a voting system can’t simply reject a ballot because it is too difficult to process. It is easy to imagine how this could lead to the disenfranchisement of voters. Paper ballots that can’t be read go through extensive visual examination, sometimes even being ironed out if they are too crumpled, in order to see if they can be (machine or visually) read before they are discarded. This same rigorous effort must be made for digital ballots.

In addition to these two example restrictive requirements, an iVoting system must assess whether a ballot can be counted. For traditional voting systems this is done via a physical or digital poll book that contains voter registration records and other information such as whether an individual has already voted. An iVoting system would have to integrate these voter records, and use strong authentication to ensure their legitimacy. As discussed in a previous blog installment this is easier said than done.

The Imposition of Other Requirements

As much as we at the OSET Institute believe that any future iVoting system must strive to conform with existing standards and policies, we recognize that there is likely some modification or accommodation of public policy that will be required. For example, the legal definition of a ballot or the ballot counting process pose genuine (Policy and Political) obstacles to iVoting and likely need to evolve.  A digital ballot would need to be accepted as a variant on the existing absentee ballot.  Other issues such as election officials’ complete custodianship and stewardship of ballots raise more difficult problems. And finally, we continue to point out that no legal consensus has been reached on what is an acceptable amount of ballot fraud (different from voter fraud) to allow for risk management of an iVoting system.  These are examples of legal, policy, and even political issues that must be resolved before any iVoting system could realistically be implemented for binding, legal, public elections.

While this blog post can’t go into detail about how exactly an iVoting system should be designed or developed (seriously, that would be an entire book involving much of the resolutions to the five challenges we laid out in Part 3); I hope this installment conveys a broader idea of how iVoting should be approached.  In short, it must be a system predicated on current election standards so as to have a hope of being implemented, recognizing there will already be plenty of push back against this kind of change.

These requirements may seem overly rigorous and perhaps even insurmountable, but the events of the 2016 election create a sense of urgency around election reform and make clear how real the threats are.  And building this kind of GovTech is very different than other types of CivicTech Apps.  CivicTech facilitates citizens interacting with their government. GovTech enables government to interact with its citizens. The membrane between the two types of technology is open public data and services to connect the two -- for instance the work of the Voting Information Project (VIP). However, GovTech and particularly election technology has several encumbrances: federal certification, federal standards, and local regulations.  Thus its one thing to offer a prototype for how the world might pajama vote or smartphone vote, but quite another to build a system that can legally be adopted, adapted, and deployed.

America's election and voting systems infrastructure is compelled to hold up against the ambitious, strongest, and sophisticated attacks imaginable--post 2016 election, its now a matter of working within the 1% doctrine. Thus any new innovative solution, including but not limited to iVoting, will need to prove that:

• it can administer and conduct elections with integrity;

• it can be realistically implemented, and that

• it can be secure.

The requirements for our elections systems are stringent by design, and they will no doubt be difficult to meet or exceed, but I do not believe I exaggerate when I say that, for our democracy, the stakes could not be higher. 

As always, I look forward to your comments and the continuing conversation. While you can continue to ping me directly, or on Twitter (@OSET), your comments here help catalyze the conversation without a 140 character restriction! ;-)
Sergio