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:
- You have a driver’s license in your state, and you are registered to vote in that state.
- You change your address to some new address in state.
- You go to the DMV to change your address and get a new driver’s license.
- 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.
Future of Voting Systems: Future Requirements (Part 2)
At the recent NIST/EACG Future of Voting Systems Workshop II, EAC folks asked participants for input on possible future requirements for future voting systems. I subsequently blogged here some suggestions based on the experience of the TrustTheVote Project. Today, I’ll continue that theme, but first briefly revisit my prior remarks.
Evidence-Based, Component-Based, Modular
Let me say first that all of these suggestions are intended to be about voting systems that enable “evidence based elections.” As I said earlier:
- Evidence based voting systems are a category of voting systems for which demand is increasing.
- Requirements for them should be different from requirements for other types of voting systems, with completely different properties.
- Requirements should support testing and certification of individual voting system components.
- Requirements should be modular, or chunked, with chunks that can applied (or not) to different types of voting systems, and especially, to individual components.
One recommended net result of all these recommendations is that individual states could choose which requirement-chunks to apply to testing of individual components of evidence-based voting systems, so that the state election officials’ choices can drive a test and certification process that best fits the needs of the individual state.
Two Out of Nine
Lastly, of the 9 areas of future requirements that the EAC folks solicited suggestions, I previously wrote about 2 of them. For future requirements for evidence based voting systems …
Auditability: Yes, yes, and yes. The standards should embody the definition of evidence-based elections and the already well-agreed-to features to support them. For details of those features, see my earlier post.
Software Security: no. There should not be be specific requirements for specific types of coding standards, software quality, quality assurance, software configuration management, and so on. Rationale is in my earlier post, but suffice it to say that a voting system provider needs to rigorously document their own standards for software development issues, in order for a test lab to be able to reproduce the provider’s tests that demonstrate compliance to functional requirements.
This form of “self-attestation“, independently validated by a test lab, should be sufficient for state election officials to decide whether to not certify a system based on inadequacies in software assurance. Hobbling providers with pages of specific requirements — not necessary, and makes the whole process much more burdensome for all parties.
And Now, Three More
Risk Management: yes, but. Yes, voting system providers must document the threat model that they claim a voting system is designed for. However, much of the threat model should already be defined, in 2 forms: the definition of an evidence based system; and the functional requirements of specific voting system components. So really it is a matter of defining the threat model largely by reference, defining threat-relevant features also largely by reference, and documenting specific claims (that a test lab can test for) that the required functionality is there.
However, a formal risk assessment process is not something that a voting system provider should do — it’s not likely that every provider would even have the expertise in house. Instead, documenting a threat model, and functionality needed to operate within that model, is another form of self-attestation that (a) a test lab can validate, and (b) state election officials decide whether the model fits the needs of the state, and whether the validation was sufficient.
If a state wants to retain real software risk assessment experts to audit voting system source code and build procedures, they certainly can do so, but remember: the whole point of evidence based systems is that the election integrity does not depend on correctness of software. We certainly don’t want to rely on low-quality software, and there may well be a limited role for software proofs and other high assurance software techniques. However, a test and certification process (for evidence based systems) also need not require investment in stringent review or proof of correctness of every part of every component of a voting system.
Self-attestation about software quality (see above), with independent validation of attested claims, should be sufficient.
Communication Security: no. Consider a component-based future, with definitions of individual components of evidence based voting systems. No individual component should need to be doing network-based communication at all. Hence no need for communication security requirements other than this one: don’t do network based communication.
Physical Security: yes! But again, this is largely a matter of self-attestation, and also documentation. The voting system provider must define the recommended procedures for using an individual component, and where physical security related activities are required. Future voting system requirements might provide some examples of types of physical security issues to be addressed, such as access ports, locks, tamper-evident seals.
However, voting system providers need to define the component-specific physical controls. Test labs will need to test that when following the recommended practices for the component, the attested physical security measures are adequate, and that no other physical security issues were un-addressed.
But again, remember, perfectly physically secure systems, like perfectly secure software, is not possible. And the whole point of evidence based voting systems is to not have to require super-high physical security. We certainly don’t want easily tamperable components, but they don’t need to mini Fort Knoxes either.
Five Down, Five to Go
In the next and perhaps last installment, we’ll tackle the 4 remaining areas of requirements that EAC solicited input on: Access Control, Data Security, Monitoring and Logging, Documentation, plus Human Factors (Usability and Accessibility) which wasn’t one of the solicited topics, but is a very important part of existing voting system requirements.
The RDCV for all of those is “yes!” and the details consist of where existing standards or other ongoing work is relevant.
State Certification of Future Voting Systems — 3 Points of Departure
In advance of this week’s EVN Conference, we’ve been talking frequently with colleagues at several election oriented groups (Brennan Center, National Conference of State Legislatures, EAC, NIST, and others) about the way forward from the current voting system certification regime. One of the topics for the EVN conference is a shared goal for many of us: how to move toward a near future certification regime that can much better serve state election officials in states that want to have more control, customization, and tailoring of the certification process, to better serve the needs of their local election officials.
As readers will have noticed, I am already in the process of laying out several recommendations for certification reform, in response to the open discussion on that issue, broadly, at the recent NIST/EAC Symposium. However, for the road towards new state certification programs, I can relatively briefly make 3 main points. If progress on all 3 is rapid — and I believe that it is possible — then we could see a lot more flexibility for states, without any dilution of the fundamental controls that certification is for. The 3 points are: process simplification, voting system components, and (for lack of a better term) chunking of requirements.
The biggest single way to simplify certification is to reduce the scope of testing, by focusing on those requirements that are essential to evidence-based voting systems, and dropping those requirements that don’t fit them. That doesn’t work for every voting system, but it does fit the desires of most if not all states that are currently looking at more localization of certification, and new voting systems that are evidence-based. But what’s that all about? Details already provided here, this previous post.
So, if you first focus on evidence-based voting systems, then limit the requirements appropriately, then you can look at not the whole of current voting system products, but rather individual components. A state may not want to certify a election management system product (EMS), because in its definition of evidence-based systems, and EMS doesn’t create evidence, and doesn’t cast or count ballots. But such a state may want to require a vendor to work with a test lab on testing a specific component like a ballot marking device or a ballot counting device.
With the smaller scope of testing enabled by simplification, a focus on individual components can take an even bigger step to creating smaller, more manageable test and certification, more amenable to state adjustment, than the current monolithic multi-year scheme.
But what would component certification amount to in practice? What are “components,” how would they work together; and what are the requirements and standards? Many questions, but also at least the beginning of some answers in recent posts like this one.
For lack of a better word, “chunking” of voting system requirements is the term that I use for how states could use future voting system requirements and testing guidelines that have been simplified and focused on voting system components in the way I refer to above. Requirements could be composed of related but separable chunks, where some chunks can be used independent of others, in the context of one state’s process of certifying a single component, based on testing of it, using the state’s selection of chunks.
For example, a state may wish to certify a ballot marking device (BMD). They may require a test lab to test the BMD using chunks of requirements from a larger set of (future, perhaps federal) voting systems requirements. They might direct the BMD’s provider, and a test lab, to focus testing on usability/accessibility, and reliability, but not other sets of requirements that might apply to (say) ballot counting devices but not BMDs.
Well, that’s the broad vision anyway. The first 2 of the 3 steps are in progress or in reach. My personal belief is these efforts might go faster if we also incorporated the idea of having future voting system requirements that, because of simplification and componentization, are much more amenable to States being able to pick and choose the chunks that are the most helpful to their objectives.