Recent News

But is it Safe?

The Iowa Caucuses are one of the great curiosities of presidential politics.  Famous as much for their format as their results, these contests are notoriously difficult to report in realtime. Every cycle, media outlets and politicos race to share results as quickly and accurately as possible.  This year they had help from a party sponsored reporting application created by Interknowlogy in partnership with Microsoft.

Let’s be clear, this App is both useful and beautiful. For the first time in Caucus history the media and viewers could observe results in near realtime on an easily accessible platform.  Still, while there is no doubt that this technology is a big step forward we’ve found ourselves asking — “But is it safe?”

First, a little background.  The Iowa Caucuses consist of over 1,500 contests conducted in precincts throughout the state.  Unlike most elections (even in Iowa), these contests involve in-person participation and may require multiple votes to reach a decision.  The most important results, as you might expect, are the final votes.

The major parties have used a variety of systems to aggregate votes for the Caucuses. For example, until last year the Democrats were using an automated phone system that guided the reporting official through a series of prompts to secure relevant data (e.g., “Press 1 for ______(candidate), then enter the vote total…”).  That system remains in service today as a back up to the Inteknowlogy App and a relic of a bygone era.

So, how does this new technology change the Caucuses and where do we go from here?  Let’s take a look.

What it is: The Iowa Caucuses App is a digital tool used to report unofficial results from precincts on election night.  The application allows local representatives to use party specific instances of the app to instantly report results to the central office.  The official results, however, must be submitted in writing to each county party.  These paper results are used to elect delegates to the county conventions, who in turn elect delegates to the state conventions, who in turn elect delegates to the national conventions.

What it is not: In a word, official.  In another, secure.  This App has been designed to meet a real need, but it is not a security critical component of the election administration infrastructure.  There are few, if any, security consequences to the party if this application fails and end to end encryption is not required.  In fact, there is no requirement that this App meet a publicly mandated security standard. After all, if the official paper results are submitted correctly it should all work out in the end — right?

What this analysis fails to recognize is the important, albeit unofficial, role the Iowa Caucuses play in structuring the national political debate beyond Iowa.  Unofficial election night results play a central role in shaping the public perception of candidates. They can have an existential impact on these campaigns. The existence of an informal reporting system in addition to the official results process has always presented a very real vulnerability for our democracy.  In this respect the new system is no different than the old system and but still short of some critical features.

In 2012, this issue was clearly demonstrated by the Republican party when the results from several precincts were temporarily lost.  Under pressure from the media the Republican state party reported results prematurely, declaring Mitt Romney the winner by 8 votes. When the votes from the missing precincts were found the final result was corrected to reflect Rick Santorum’s victory.

With that in mind, I still hope the 2020 presidential election sees widespread adoption of this type of technology with two key additions.  

  • First, data can and should be reported in the federally approved election results common data format overseen by the National Institute of Standard and Technology (NIST.) If a government or partner organization is going present election night results they should also share the raw data for public consumption. In short, if we have the data we should publish the data.
  • Second, through the implementation of this technology the official and unofficial reporting processes should be brought together to provide an accurate and timely accounting of the results.

I think we can all applaud the work of the Interknowlogy team and the success of their application in the Iowa Caucuses.  However, while this exercise marks a step towards modernizing our election reporting infrastructure, we still have work to do.

The stakes of presidential elections are too high for even the smallest margin of error.  We have to get it right and we will.

Announcing the Launch of VoteStream Beta

Over the past three years we have used this space to document our efforts to create a truly open source, standards based election reporting solution: VoteStream.  At each step we have been guided by the needs of election professional and the ideals of the OSET Foundation: that a critical democracy infrastructure should be verifiable, accurate, secure, and transparent (in process).

Today we are excited to take the next step in that process.  In partnership with the Knight Foundation, the TrustTheVote project is launching a round of beta testing for the next version of VoteStream.  This round will continue to focus on the requirements of local election officials and solicit feedback from academics, journalists, and other stakeholders.

In past tests we demonstrated the ability of VoteStream to publish election results in an easily accessible format.  This round will demonstrate the process of converting raw election data to the standard format published by the National Institute of Standards and Technology.

The beta round will be lead by Iain Padley, our new Director of Election Professional Stakeholder Engagement.  Iain comes to OSET with experience in community and political organizing with a special emphasis on education issues.  He has spent much of the past three years working with local and state election officials to leverage public data to drive increased civic engagement among educators.

If you would like to apply for a spot in this beta round please fill out an application form or email Iain directly at

Here’s How to Link Driving Records and Voting Records

Kudos to Wendy Underhill and Katy Owens Hubler for their excellent explanation in the latest NCSL newsletter of an important problem: the need in many states to complete implementation of “motor voter”. Let me recap it these steps, and refer you to the NCSL article for the whole story.

My addition to the story, today, is that the PCEA-suggested solution is ALMOST a reality in some states, because it is the inverse of online voter registration with a driver’s license.


Here is where the situation starts:

  1. You have a driver’s license in your state, and you are registered to vote in that state.
  2. You change your address to some new address in state.
  3. You go to the DMV to change your address and get a new driver’s license.
  4. While there, the DMV is obligated (by the Federal law known as NVRA) to enable you to also change address with your voter registration.

That’s the scenario. Now, the problem is that the last step is handled in different ways in different states, in some cases barely at all (for example, DMV person gives you a blank voter registration paper form). The new solution approach was defined by the PCEA, which recommended that

States should seamlessly integrate voter data acquired through Departments of Motor Vehicles with their statewide voter registration lists

and that’s a great idea. One way of doing this is a new step 4:

4a. As DMV’s IT systems process your change of address, they also automate the change of address with your voter registration.

How does that happen? By the DMV systems sending to the state VR system the data about you, your old address, your new address, and your driver’s license number.

Whoa! Take a Look at OVR

Whoa! I am hearing already from some readers … it is easy to SAY “DMV sends XYZ to VR system” but that is a major project to put into place! Right? Well, no, actually, at least in many of the states that have already implemented paperless online voter registration (OVR) for citizens with a driver’s license.

To see why, let’s take a look at how OVR works, when you’re already registered to vote, you have a driver’s license, and you have changed address.

  • You go to your state’s OVR web site (or portal), identify yourself as an already-registered voter, provide your driver’s license number, and your new address.
  • Portal sends to your online request to a backend VR system.
  • VR system sends a request to the the DMV system, with your DLN and personal info, requesting DMV to confirm a match between the DLN, your name, address, and whatever else the DMV system needs.
  • DMV system replies with a match
  • VR system queues your change-of-address request for your local election officials (LEO) to review.
  • VR system returns to Portal a success indication
  • Portal tells you that your voter registration change-of-address application has been filed, paperless, and your should expect to hear from LEO.

That’s how it works today, in some similar form, as we’ve seem it inside the IT bubble in our work in the states of VA and CA.

Check the PCEA Recommendation Checklist

With both those recaps in mind, let’s look at what PCEA’s recommendation needs for implementation, in the excellent summary in the NCSL article:

  • “shared data structure”check. In a paperless OVR state, the VR sytem and the DMV system already have a way of exchanging info about you. And in some states, that uses a standard common data format, which makes it easier of other states to adopt.
  • “the right programming”check. In a paperless OVR state, there is already an application programming interface (API) and programming on both sides to use it, to send a notification of your change-of-address request.
  • “intergovernmental collaboration and legislation to allow data to be shared within a state”check … maybe. Enabling legislation for OVR may be already in place, but it may or may not be enough for the last step, below. And the collaboration that happened to set up OVR may or may not be easy to repeat for that last step.

The Last Step (or Two)

OK. So with many of those ingredients in place, what is the last step to, as the PCEA reports says: “… allow a registration application completed at a DMV to be electronically transmitted to the appropriate registration official.” First, let’s refine that a bit. This is an application for change of address of an existing registered voter, automatically created when you change your address at the DMV. The last step is the DMV system doing the REVERSE of the exchange that already happens in OVR. That is:

  • The DMV system sends to the VR system your name, old address, new address, DLN.

The exchange uses exactly the same data format and communication method as OVR. The VR system acts pretty much the same as in the OVR case where is asked the DMV system to confirm a match of pretty much the same information.

So how to put this in place? It is essentially a re-do of the previous process that put paperless OVR into place. So the gating function really is the collaboration, not the technology. And even better, for a state that is just getting started with OVR, it is a great time to put in place both data exchanges, in the same project. And in that case, it is also the right time to put in place the last last step: a similar exchange of data from the DMV when you are not already registered to vote, and are getting a new DL or changing address, or renewing.

Code Causes Change – A Worked Example

And especially for those states that are just headed to OVR, or those headed toward implementing the PCEA recommendation about Motor-Voter … a public worked example may help the IT people in the scenario get very specific about the modest IT efforts required to set up the DMV/OVR data exchange.

That’s why we have a grant proposal in progress for funding to build on our Voter Services Portal and OVR system, to add example components of the whole backend process, with a worked example of the standard data formats and APIs, and wrappers around the existing legacy systems, so that those existing DMV and VR systems don’t need direct modification.

As “Code Causes Change” we’re hoping that this worked example of code would show IT folks exactly how to make the change needed to implement the PCEA recommendation highlighted in this month’s NCSL newsletter.