Alaska will allow absentee voters to submit their ballot via a "secure online voting solution", aka e-mail. We're holding our breath.
Viewing entries tagged
Disruptions. Glitches. Delays. Oh My! We make our predictions for the voting snags you should expect on Election Day.
The TrustTheVote Project Core Team has been hard at work on the Alpha version ofVoteStream, our election results reporting technology. They recently wrapped up a prototype phase funded by the Knight Foundation, and then forged ahead a bit, to incorporate data from additional counties, provided by by participating state or local election officials after the official wrap-up.
Along the way, there have been a series of postings here that together tell a story about the VoteStream prototype project. They start with a basic description of the project in Towards Standardized Election Results Data Reporting and Election Results Reload: the Time is Right. Then there was a series of posts about the project’s assumptions about data, about software (part one and part two), and about standards and converters (part one and part two).
Of course, the information wouldn’t be complete without a description of the open-source software prototype itself, provided Not Just Election Night: VoteStream.
Actually the project was as much about data, standards, and tools, as software. On the data front, there is a general introduction to a major part of the project’s work in “data wrangling” in VoteStream: Data-Wrangling of Election Results Data. After that were more posts on data wrangling, quite deep in the data-head shed — but still important, because each one is about the work required to take real election data and real election result data from disparate counties across the country, and fit into a common data format and common online user experience. The deep data-heads can find quite a bit of detail in three postings about data wrangling, in Ramsey County MN, in Travis County TX, and in Los Angeles CountyCA.
Today, there is a VoteStream project web site with VoteStream itself and the latest set of multi-county election results, but also with some additional explanatory material, including the election results data for each of these counties. Of course, you can get that from the VoteStream API or data feed, but there may be some interest in the actual source data. For more on those developments, stay tuned!
If you've read some of the ongoing thread about our VoteStream effort, it's been a lot about data and standards. Today is more of the same, but first with a nod that the software development is going fine, as well. We've come up with a preliminary data model, gotten real results data from Ramsey County, Minnesota, and developed most of the key features in the VoteStream prototype, using the TrustTheVote Project's Election Results Reporting Platform. I'll have plenty to say about the data-wrangling as we move through several different counties' data. But today I want to focus on a key structuring principle that works both for data and for the work that real local election officials (LEOS) do, before an election, during election night, and thereafter.
Put simply, the basic structuring principle is that the election definition comes first, and the election results come later and refer to the election definition. This principle matches the work that LEOs do, using their election management system to define each contest in an upcoming election, define each candidate, and do on. The result of that work is a data set that both serves as an election definition, and also provides the context for the election by defining the jurisdiction in which the election will be held. The jurisdiction is typically a set of electoral districts (e.g. a congressional district, or a city council seat), and a county divided into precincts, each of which votes on a specific set of contests in the election.
Our shorthand term for this dataset is JEDI (jurisdiction election data interchange), which is all the data about an election that an independent system would need to know. Most current voting system products have an Election Management System (EMS) product that can produce a JEDI in a proprietary format, for use in reporting, or ballot counting devices. Several states and localities have already adopted the VIP standard for publishing a similar set of information.
We've adopted the VIP format as the standard that that we'll be using on the TrustTheVote Project. And we're developing a few modest extensions to it, that are needed to represent a full JEDI that meets the needs of VoteStream, or really any system that consumes and displays election results. All extensions are optional and backwards compatible, and we'll be submitting them as suggestions, when we think we got a full set. So far, it's pretty basic: the inclusion of geographic data that describes a precinct's boundaries; a use of existing meta-data to note whether a district is a federal, state, or local district.
So far, this is working well, and we expect to be able to construct a VIP-standard JEDI for each county in our VoteStream project, based on the extant source data that we have. The next step, which may be a bit more hairy, is a similar standard for election results with the detailed information that we want to present via VoteStream.
PS: If you want to look at a small artificial JEDI, it's right here: Arden County, a fictional county that has just 3 precincts, about a dozen districts, and Nov/2012 election. It's short enough that you can page through it and get a feel for what kinds of data are required.
Last time, I explained how our VoteStream work depends on the 3rd of 3 assumptions: loosely, that there might be a good way to get election results data (and other related data) out of their current hiding places, and into some useful software, connected by an election data standard that encompasses results data. But what are we actually doing about it? Answer: we are building prototypes of that connection, and the lynchpin is an election data standard that can express everything about the information that VoteStream needs. We've found that the VIP format is an existing, widely adopted standard that provides a good starting point. More details on that later, but for now the key words are "converters" and "connectors". We're developing technology that proves the concept that anyone with basic data modeling and software development skills can create a connector, or data converter, that transforms election data (including but most certainly not limited to vote counts) from one of a variety of existing formats, to the format of the election data standard.
And this is the central concept to prove -- because as we've been saying in various ways for some time, the data exists but is locked up in a variety of legacy and/or proprietary formats. These existing formats differ from one another quite a bit, and contain varying amounts of information beyond basic vote counts. There is good reason to be skeptical, to suppose that is a hard problem to take these different shapes and sizes of square data pegs (and pentagonal, octahedral, and many other shaped pegs!) and put them in a single round hole.
But what we're learning -- and the jury is still out, promising as our experience is so far -- that all these existing data sets have basically similar elements, that correspond to a single standard, and that it's not hard to develop prototype software that uses those correspondence to convert to a single format. We'll get a better understanding of the tricky bits, as we go along making 3 or 4 prototype converters.
Much of this feasibility rests on a structuring principle that we've adopted, which runs parallel to the existing data standard that we've adopted. Much more on that principle, the standard, its evolution, and so on … yet to come. As we get more experience with data-wrangling and converter-creation, there will certainly be a lot more to say.
It's time to finish -- in two parts -- the long-ish explanation of the assumptions behind our current "VoteStream" prototype stage of the TrustTheVote Project's Election Result Reporting Platform (ENRS) project. As I said before, it is an exercise in validating some key assumptions, and discovering their limits. Previously, I've described our assumptions about election results data, and the software that can present it. Today, I'll explain the 3rd of three basic assumptions, which in a nutshell is this:
- If the data has the characteristics that we assumed, and
- if the software (to present that data) is as feasible and useful as we assumed;
- then there is a method for getting the data from its source to the reporting software, and
- that method is practical for real-world elections organization, scalable, and feasible to be adopted widely.
So, where are we today? Well, as previous postings have described, we made a good start on validating the first 2 assumptions during the previous design phase. And since starting this prototype phase, we've improved the designs and put them into action. So far so good: the data is richer than we assumed; the software is actually significantly more flexible than before, and effectively presents the data. We're pretty confident that our assumptions were valid on those two points.
But where did the 2012 election results data come from, and how did it get into the ENRS prototype? Invented elections, or small transcribed subsets of real results, were fine for design; but in this phase it needs to be real data, complete data, from real election officials, used in a regular and repeated way. That's the kind of connection between data source and ENRS software that we've been assuming.
Having stated this third of three assumptions, the next point is about what we're doing to prove that assumption, and assess it limits. That will be part two of two, of this last segment of my account of our assumptions and progress to date.
A rose by any other name would smell as sweet, but if you want people to understand what a software package does, it needs a good name. In our Election Night Reporting System project, we've learned that it's not just about election night, and it's not just about reporting either. Even before election night, a system can convey a great deal of information about an upcoming election and the places and people that will be voting in it. To take a simple example: we've learned that in some jurisdictions, a wealth of voter registration information is available and ready to be reported alongside election results data that will start streaming in on election night from precincts and counties all over.
It's not a "system" either. The technology that we've been building can be used to build a variety of useful systems. It's better perhaps to think of it as a platform for "Election Result Reporting" systems of various kinds. Perhaps the simplest and most useful system to build on this platform is a system that election officials can load with data in a standard format, and which then publishes the aggregated data as an "election results and participation data feed". No web pages, no API, just a data feed, like the widely used (in election land) data feed technique using the Voting Information Project and their data format.
In fact, one of the recent lessons learned, is that the VIP data standard is a really good candidate for an election data standard as well, including:
- election definitions (it is that already),
- election results that reference an election definition (needs a little work to get there), and
- election participation data (a modest extension to election results).
As a result (no pun intended) we're starting work on defining requirements for how to use VIP format in our prototype of the "Election Results Reporting Platform" (ERRP).
But the prototype needs to be a lot more than the ERRP software packaged in to a data feed. It needs to also provide a web services API to the data, and it needs to have a web user interface for ordinary people to use. So we've decided to give the prototype a better name, which for now is "VoteStream".
Our VoteStream prototype shows how ERRP technology can be packaged to create a system that's operated by local election officials (LEOs) to publish election results -- including but not limited to publishing unofficial results data on election night, as the precincts report in. Then, later, the LEOs can expand the data beyond vote counts that say who won or lost. That timely access on election night is important, but just as important is the additional information that can be added during the work in which the total story on election results is put together -- and even more added data after the completion of that "canvass" process.
That's VoteStream. Some other simpler ERRP-based system might be different: perhaps VoteFeed, operated by a state elections organization to collate LEO's data and publish to data hounds, but not to the general public and their browsers. Who knows? We don't, not yet anyhow. We're building the platform (ERRP), and building a prototype (VoteStream) of an LEO-oriented system on the platform.
The obvious next question is: what is all that additional data beyond the winner/loser numbers on election night? We're still learning the answers to that question, and will share more as we go along.
Today, I'll be concluding my description of one area of assumptions in our Election Night Reporting System project -- our assumptions about software. In my last post, I said that our assumptions about software were based on two things: our assumptions about election results data (which I described previously), and the results of the previous, design-centric phase of our ENRS work. Those results consist of two seemingly disparate parts:
- the UX design itself, that enables people to ask ENRS questions, and
- a web service interface definition, that enable to software to ask ENRS questions.
In case (1), the answer is web pages delivered by a web app. In case (2) the answers are data delivered via an application programming interface (API).
Exhibit A is our ENRS design website http://design.enrs.trustthevote.org which shows a preliminary UX design for a map-based visualization and navigation of the election results data for the November 2010 election in Travis County, Texas. The basic idea was to present a modest but useful variety way to slice and dice the data, that would be meaningful to ordinary voters and observers of elections. The options include slicing the data at the county level, or the individual precinct level, or in-between, and to filter by one of various different kinds of election results or contests or referenda. Though preliminary, the UX design well received, and it's the basis for current work to do a more complete UX that also provides features for power users (data-heads) without impacting the view of ordinary observers.
Exhibit B is the application programming interface (API), or for now just one example of it:
That does not look like a very exciting web page (click it now if you don't believe me!), and a full answer of "what's an API" can wait for another day.
But the point here is that the URL is a way for software to request a very specific slice through a large set of data, and get it in a software-centric digestable way. The URL (which you can see above in the address bar) is the question, and the answer is what you above as the page view. Now, imagine something like your favorite NBA or NFL scoreboard app for your phone, periodically getting updates on how your favorite candidate is doing, and alerting you in a similar way that you get alerts about your favorite sports team. That app asks questions of ENRS, and gets answers, in exactly the way you see above, but of course it is all "under the hood" of the app's user interface.
So, finally, we can re-state the software assumption of our ENRS project:
- if one can get sufficiently rich election data, unlocked from the source, in a standard format,
- then one can feasibly develop a lightweight modern cloud-oriented web app, including a web service, that enables election officials to both:
- help ordinary people understand complex election results data, and
- help independent software navigate that data, and present it to the public in many ways, far beyond the responsibilities of election officials.
We're trying to prove that assumption, by developing the software -- in our usual open source methodology of course -- in a way that (we hope) provides a model for any tech organization to similarly leverage the same data formats and APIs.
As frequent readers will note, Internet voting as a discussion topic is one we increasingly tire of -- there is so much else to do! that unlike Internet Voting, can actually be done today! Let's talk instead about what tech innovations can do speed up the long lines at polling places, for example. But nevertheless, today, esteemed colleagues were asking for a "definitive statement" on i-voting, having been asked for such by folks who work for legislators interested in the topic. So I thought I'd share what I like to say when legislators, staffers, etc. ask for "definitive". Basically 3 steps.
Look to the National Institute of Standards and Technology (NIST), the U.S. government's top authority on technology issues. They've studied the use of the Internet for everything in elections, including voting.
- Read their conclusion on top half of page 69 of NIST's "Threat Analysis of Voting Systems" (here), supported by analysis in pages 42-46.
- Also briefly flip through NIST's 36 pages of "Information System Security Best Practices" (here) for Internet-connected election support systems.
- Think about whether state or local election officials would have the funding to comply with NIST guidelines, even for the lower bar of distributing blank ballots, much less the higher bar of Internet Voting.
That's pretty much it.
PS: While we're on the topic, my thanks to Jeremy Epstein for tackling another topic on i-voting (botnets, one among several i-voting topics that I am happy to leave to Jeremy and other colleagues in the security world), and for letting me put my 2 cents in for his Freedom To Tinker blog today. Thanks Jeremy, for doing the $0.98, and keep up the good work ! -- ejs
Many thanks to the engaged audience for OSDVer Anne O'Flaherty's presentation yesterday at National Institute of Standards and Technology (NIST), which hosted a workshop on Common Data Formats (CDFs) and standards for data interchange of election data. We had plenty to say, based on our 2012 work with Virginia State Board of Elections (SBE), because that collaboration depends critically on CDFs. Anne and colleagues did a rather surprising amount of data wrangling over many weeks to get things all hooked up right, and the lessons learned are important for continuing work in the standards body, both NIST and the IEEE group working on CDF standards.
As requested by the attendees, here are online versions of the poster and the slides for the presentation "Bringing Transparency to Voter Registration and Absentee Voting."
An esteemed colleague noted the news of the USPS stopping weekend delivery, as part of a trend of slow demise of the USPS, and asked: will we get to the point where vote-by-mail is vote-by-Fedex? And would that be bad, having a for-profit entity acting as the custodian for a large chunk of the ballots in an election? The more I thought about it, the more flummoxed I was. I had to take off the geek hat and dust off the philosopher hat, looking at the question from a viewpoint of values, rather than (as would be my wont) requirements analysis or risk analysis. I goes like this ...
I think that Phil's question is based on assumption of some shared values among voters -- all voters, not just those that vote by mail -- that make postal voting acceptable because ballots are a "government things" and so is postal service. Voting is in part an act of faith in government to be making a good faith effort to do the job right, and keep the operations above a minimum acceptable level of sanity. It "feels OK" to hand a marked ballot to my regular neighborhood post(wo)man, but not to some stranger dropping off a box from a delivery truck. Translate from value to feeling to expectation: it's implied that we expect USPS staff to know that they have a special government duty in delivering ballots, and to work to honor that duty, regarding the integrity of those special envelopes as a particular trust, as well as their timely delivery.
- Having re-read all that, it sounds so very 20th century, almost as antique as lever machines for voting.
I don't really think that USPS is "the government" anymore, not in the sense that the journey of a VBM ballot is end-to-end inside a government operation. I'm not sure that Fedex or UPS are inherently more or less trustworthy. In fact they all work for each other now! And certainly in some circumstances the for-profit operations may to some voters feel more trustworthy -- whether because of bad experiences with USPS, or because of living overseas in a country that surveils US citizens and operates the postal service.
Lastly, I think that many people do share the values behind Phil's question -- I know I do. The idea makes me wobbly. I think it comes down to this:
- If you're wobbly on for-profit VBM, then get back into the voting booth, start volunteering to help your local election officials, and if they are effectively outsourcing any election operations to for-profit voting system vendors, help them stop doing so.
- If you not wobbly, then you're part of trend to trusting -- and often doing -- remote voting with significant involvement from for-profit entities - and we know where that is headed.
The issue with USPS shows that in the 21st century, any form of remote voting will involve for-profits, whether it is Fedex for VBM, or Amazon cloud services for i-voting. My personal conclusions:
- Remote voting is lower integrity no matter what, but gets more people voting because in-person voting can be such a pain.
- I need to my redouble efforts to fix the tech so that in-person voting is not only not a pain, but actually more desirable than remote voting.
Much as I admire everybody at the New York Times, I have to disagree with Nick Bilton on his piece Disruptions: Casting a Ballot by Smartphone. I have to say I don't blame him though, especially given the broad range of coverage of the many many kinds election dysfunction that occurred and are still occurring now during state canvassing....
I've spent a fair bit of time over the last few days digesting a broad range of media responses to last week's election's operation, much it reaction to President Obama's "we've got to fix that" comment in his acceptance speech. There's a lot of complaining about the long lines, for example, demands for explanation of them, or ideas for preventing them in te future -- and similar for the difficulty that some states and counties face for finishing the process of counting the ballots. It's a healthy discussion for the most part, but one that makes me sad because it mostly misses the main point: the root cause of most election dysfunction. I can explain that briefly from my viewpoint, and back that up with several recent events. The plain unvarnished truth is that U.S. local election officials, taken all together as the collective group that operates U.S. federal and state elections, simply do not have the resources and infrastructure to conduct elections that
- have large turnout and close margins, preceded by much voter registration activity;
- are performed with transparency that supports public trust in the integrity of the election being accessible, fair, and accurate.
There are longstanding gaps in the resources needed, ranging from ongoing budget for sufficient staff, to inadequate technology for election administration, voting, counting, and reporting.
Of course in any given election, there are local elections operations that proceed smoothly, with adequate resources and physical and technical infrastructure. But we've seen again and again, that in every "big" election, there is a shifting cast of distressed states or localities (and a few regulars), where adminstrative snafus, technology glitches, resource limits, and other factors get magnified as a result of high participation and close margins. Recent remarks by Broward County, FL, election officials -- among those with the most experience in these matters -- really crystalized it for me. When asked about the cause of the long lines, their response (my paraphrase) is that when the election is important, people are very interested in the election, and show up in large numbers to vote.
That may sound like a trivial or obvious response, but consider it just a moment more. Another way of saying it is that their resources, infrastructure, and practices have been designed to be sufficient only for the majority of elections that have less than 50% turnout and few if any state or federal contests that are close. When those "normal parameters" are exceeded, the whole machinery of elections starts grinding down to a snail's pace. The result: an election that is, or appears to be, not what we expect in terms of being visibily fair, accessible, accurate, and therefore trustworthy.
In other words, we just haven't given our thousands of localities of election officials what they really need to collectively conduct a larger-than-usual, hotly contested election, with the excellence that they are required to deliver, but are not able to. Election excellence is, as much as any of several other important factors, a matter of resources and infrastructure. If we could somehow fill this gap in infrastructure, and provide sufficient funding and staff to use it, then there would be enormous public benefits: elections that are high-integrity and demonstrably trustworthy, despite being large-scale and close.
That's my opinion anyway, but let me try to back it up with some specific and recent observations about specific parts of the infrastructure gap, and then how each might be bridged.
- One type of infrastructure is voter record systems. This year in Ohio, the state voter record system poorly served many LEOs who searched for but didn't find many many registered absentee voters to whom they should have mailed absentee ballots. The result was a quarter million voters forced into provisional voting -- where unlike casting a ballot in a polling place, there is no guarantee that the ballot will be counted -- and many long days of effort for LEOs to sort through them all. If the early, absentee, and election night presidential voting in Ohio had been closer, we would still be waiting to hear from Ohio.
- Another type of infrastucture is pollbooks -- both paper, and electronic -- and the systems that prepare them for an election. As usual in any big election, we have lots of media anecdotes about people who had been on these voter rolls, but weren't on election day (that includes me by the way). Every one of these instances slows down the line, causes provisional voting (which also takes extra time compared to regular voting), and contributes to long lines.
- Then there are the voting machines. For the set of places where voting depends on electronic voting machines, there are always some places where the machines don't start, take too long get started, break, or don't work right. By now you've probably seen the viral youtube video of the touch screen that just wouldn't record the right vote. That's just emblematic of the larger situation of unreliable, aging voting systems, used by LEOs who are stuck with what they've got, and no funding to try to get anything better. The result: late poll opening, insufficient machines, long lines.
- And for some types of voting machines -- those that are completely paperless -- there is simply no way to do a recount, if one is required.
- In other places, paper ballots and optical scanners are the norm, but they have problems too. This year in Florida, some ballots were huge! six pages in many cases. The older scanning machines physically couldn't handle the increased volume. That's bad but not terrible; at least people can vote. However, there are still integrity requirements -- for example, the voters needs to put their unscanned ballots in an emergency ballot box, rather than entrust a marked ballot to a poll worker. But those crazy huge ballots, combined with the frequent scanner malfunction, created overstuffed full emergency ballot boxes, and poll workers trying to improvise a way store them. Result: more delays in the time each voter required, and a real threat to the secret ballot and to every ballot being counted.
Really, I could go on for more and more of the infrastructure elements that in this election had many examples of dysfunction. But I expect that you've seen plenty already. But why, you ask, why is the infrastructure so inadequate to the task of a big, complicated, close election conducted with accessibility, accuracy, security, transparency, and earning public trust? Isn't there something better?
The sad answer, for the most part, is not at present. Thought leaders among local election officials -- in Los Angeles and Austin just to name a couple -- are on record that current voting system offerings just don't meet their needs. And the vendors of these systems don't have the ability to innovate and meet those needs. The vendors are struggling to keep up a decent business, and don't see the type of large market with ample budgets that would be a business justification for new systems and the burdensome regulatory process to get them to market.
In other cases, most notably with voter records systems, there simply aren't products anymore, and many localities and states are stuck with expensive-to-maintain legacy systems that were built years ago by big system integrators, that have no flexibility to adapt to changes in election administration, law, or regulation, and that are too expensive to replace.
So much complaining! Can't we do anything about it? Yes. Every one of those and other parts of election infrastructure breakdowns or gaps can be improved, and could, if taken together, provide immense public benefit if state and local election officials could use those improvements. But where can they come from? Especially if the current market hasn't provided, despite a decade of efforts and much federal funding? Longtime readers know the answer: by election technology development that is outside of the current market, breaks the mold, and leverages recent changes in information technology, and the business of information technology. Our blog in the coming weeks will have several examples of what we've done to help, and what we're planning next.
But for today, let me be brief with one example, and details on it later. We've worked with state of Virginia to build one part of new infrastructure for voter registration, and voter record lookup, and reporting, that meets existing needs and offers needed additions that the older systems don't have. The VA state board of elections (SBE) doesn't pay any licensing fees to use this technology -- that's part of what open source is about. The don't have to acquire the software and deploy it in their datacenter, and pay additional (and expensive) fees to their legacy datacenter operator, a government systems integrator. They don't have to go back to the vendor of the old system to pay for expensive but small and important upgrades in functionality to meet new election laws or regulations.
Instead, the SBE contracts with a cloud services provider, who can -- for a fraction of the costs in a legacy in-house government datacenter operated by a GSI -- obtain the open-source software, integrate it with the hosting provider's standard hosting systems, test, deploy, operate, and monitor the system. And the SBE can also contract with anyone they choose, to create new extensions to the system, with competition for who can provide the best service to create them. The public benefits because people anywhere and anytime can check if they are registered to vote, or should get an absentee ballot, and not wait like in Ohio until election day to find out that they are one in a quarter million people with a problem.
And then the finale, of course, is that other states can also adopt this new voter records public portal, by doing a similar engagement with that same cloud hosting provider, or any other provider of their choice that supports similar cloud technology. Virginia's investment in this new election technology is fine for Virginia, but can also be leveraged by other states and localities.
After many months of work on this and other new election technologies put into practical use, we have many more stories to tell, and more detail to provide. But I think that if you follow along and see the steps so far, you may just see a path towards these election infrastructure gaps getting bridged, and flexibly enough to stay bridged. It's not a short path, but the benefits could be great: elections where LEOs have the infrastructure to work with excellence in demanding situations, and can tangibly show the public that they can trust the election as having been accessible to all who are eligible to vote, performed with integrity, and yielding an accurate result.
We'll be live on HuffPost online today at 8pm eastern:
- @HuffPostLive http://huff.lv/Uhokgr or live.huffingtonpost.com
and I thought we should share our talking points for the question:
- How do you compare old-school paper ballots vs. e-voting?
I thought the answers would be particularly relevant to today's NYT editorial on the election which concluded with this quote:
That the race came down to a relatively small number of voters in a relatively small number of states did not speak well for a national election apparatus that is so dependent on badly engineered and badly managed voting systems around the country. The delays and breakdowns in voting machines were inexcusable.
I don't disagree, and indeed would extend from flaky voting machines to election technology in general, including clunky voter record systems that lead to many of the lines and delays in polling places.
So the HuffPost question is apposite to that point, but still not quite right. It's not an either/or but rather a comparison of:
- old-school paper ballots and 19th century election fraud;
- old-school machine voting and 20th century lost ballots;
- old-school combo system of paper ballots machine counting and botched re-counting;
- new-fangled machine voting (e-voting) and 21st century lost ballots;
- newer combo system of paper ballots and machine counting (not voting).
Here are the talking points:
- Old-school paper ballots where cast by hand and counted by hand, where the counters could change the ballot, for example a candidate Smith partisan could invalidate a vote for Jones by adding a mark for Smith.
- These and other paper ballot frauds in the 19th century drove adoption in the early 20th century of machine voting, on the big clunky "level machines" with the satisfying ka-thunk-swish of the level recording the votes and opening the privacy curtain.
- However, big problem with machine voting -- no ballots! Once that lever is pulled, all that's left is a bunch of dials and counters on the backside being increased by one. In a close election that requires a re-count, there are no ballots to examine! Instead the best you could do is re-read each machine's totals and re-run the process of adding them all up in case there was an arithmetic error.
- Also, the dials themselves, after election day but before a recount, were a tempting target for twiddling, for the types of bad actors who in the 19th century fiddled with ballot boxes.
- Later in the 20th century, we saw a move to a combo system of paper ballots and machine counting, with the intent that the machine counts were more accurate than human counts and more resistant to human meddling, yet the paper ballots remaining for recounts, and for audits of the accuracyof machinery of counting.
- Problem: these were the punch ballots of the infamous hanging chad.
- Early 21st century: run from hanging chad to electronic voting machines.
- Problem: no ballots! Same as before, only this time, the machins are smaller and much easier to fiddle with. That's "e-voting" but wihout ballots.
- Since then, a flimsy paper record was bolted on to most of these systems to support recount and audit.
- But the trend has been to go back to the combo system, this time with durable paper ballots and optical-scanning machinery for counting.
- Is that e-voting? well, it is certainly computerized counting. And the next wave is computer-assisted marking of paper ballots -- particularly for voters with disabilities -- but with these machine-created ballots counted the same as hand-marked ballots.
Bottom line: whether or not you call it e-voting, so long as there are both computers and human-countable durable paper ballots involved, the combo provides the best assurance that niether humans nor computers are mis-counting or interfering with voters casting ballots.
PS: If you catch us on HP online, please let us know what you thought!
There's plenty of activity in the NY/NJ area reacting to voters' difficulties because of Super-Storm Sandy, including being displaced from their homes or otherwise unable to get to polling places. As always, the role of technology captured my attention. But first, the more important points. Some displaced people are having trouble even finding a place to shelter temporarily, so extra special kudos to those that manage to vote, whatever the method of voting they use. Likewise, extra praise for NJ and NY election officials putting in the extra extra-hours to be available to voters in advance of the election, inform them about changed polling places, and equip them to get the word out to their neighbors. The amount of effort on both sides is a great indicator of how seriously people take this most important form of civic activity.
Next, the technology, and then the policy. On the technology front, Gov. Christie of NJ announced an emergency (and I hope temporary) form of voting for displaced voters: sending an absentee ballot via email. That's a bad idea in the best of circumstances -- for several reasons including the vulnerability of the email data in transit and at rest, and the control of the e-ballot by people who are not election officials -- and these are not the best of circumstances. For example, I doubt that in every county elections office in NJ, somebody has a complete list of the people with access to the email server and the ability to view and modify data on it. But while you can see that Christie's heart in the right place, there are several issues beyond these, as described in a NJ news report here.
And this is only one of the emergency measures. In both NJ and NY people can cast a provisional ballot at any polling location -- see NJ's announcement here, and if you have the similar one for NY, please provide it as a comment!
Finally, on the policy side, it's not even clear what these ballots represent, and that's the policy problem. My legal and policy colleagues here at TTV, and in the legal side of the election integrity community, certainly know more, but I don't! Are the provisional ballots cast under these emergency rules required to be processed exactly the same as non-emergency provisional ballots? Are the e-mailed ballots provisional ballots or absentee ballots? If so, what serves as the affadavit? Do the email ballots have to be followed up with the paper hardcopy that the voter scanned and faxed? (The NJ Lt. Gov. office has issued some seemingly inconsistent statements on that.) If not, what happens in a recount? If so, why email the ballot at all, rather than just emailing a "my ballot is coming soon" message?
I could go on and on, but I think you get the idea. The general issue is that in the case of a close election (most likely a local election, but state house or congress, you never know!) there will be some of these not-exactly-your-regular ballots involved, and the potential for real disputes -- starting with concerns over dis-enfranchisement of people mis-informed about how to do a "displaced vote", and going all the way to dispute about whether counted ballots should have been counted, and whether uncounted ballots should be counted. But let's hope that it does not in fact get that messy in NY and NJ, and that every voter is able to make the extra efforts for their ballot to be cast and counted.
Tomorrow is Election Day 2012, and with many people experiencing pre-election angst, perhaps now is not the time to start telling our patient readers what the heck we've been doing in technology land for the last several months. Right now, we're in a bit of a breather, as election officials and other partners have been focusing solely on the final slog to election day, and readying for a couple intense weeks of work post-election. So instead, I'll be focusing on sharing with you a technology spin on current election news, and get around to our own accomplishments a little later. The news of the moment I want to share is this: there is a good chance that Ohio's state and federal election results won't be available on Election Night or even the next day, and root of the problem is technology. To continue the tree analogy, the trunk is process, the branches are people, the leaves are provisional ballots, and the possible storm blowing through the tree is litigation about the ballots. The technology root is balky; the trunk process of finding absentee voters is tricky; election officials didn't do the process correctly; thousands of absentee voters will instead vote provisionally; the delay in counting those ballots can create the opportunity for a storm.
As a result, there is Florida-2000-style election meltdown looming in Ohio. Due to problems with Ohio's voter records database, perhaps as many as 100,000 Ohioans will vote on provisional ballots, a huge number when you consider that every one of them requires human decisions about whether to count it. And those decisions must be monitored and recorded, because if the decision is "yes" then it is irrevocable. Once a provisional ballot is separated from the voter's affidavit (explaining why they are entitled to vote even if the poll worker didn't think so) and counted, then you can't un-count it. Likewise, the "no" decisions lead to a pile of uncounted ballots, which can be the focus of litigation.
"How does a voter records system lead to this?" you might well ask, thinking of a voter registration system that mainly handles new voter registration (creating a new voter record), and updates or re-registration (e.g. changing the address in an existing voter record). Technology glitches could disenfranchise a voter, but create an election integrity meltdown? Yes - and that's because we're not talking about a voter registration system or database, but rather a voter records system that local election officials use for many purposes. And in this case, it's the hinge for absentee voting.
Here's how it works. An Ohio voter requests absentee status via a voter registration form, either a new registration or an update of an existing record. If that request is granted, the voter record's absentee status is updated. Later on, 50-something days before the election, local election officials use the system to find all the people in their county who will be voting absentee, and send each of them their absentee ballot via U.S. Post. But what if the "find all the absentee voters" part doesn't work? Then some people don't get an absentee ballot, and many of them will try to vote in person, and hit a snag, because:
- The find-the-absentee-voters part is tricky to do with the voter-records system, and many county officials were not given the correct instructions for the lookup. As result, many absentee voters didn't get an absentee ballot.
- What does seem to work OK is preparing the pollbooks for in-person voting, where the poll books indicate for each voter whether they have absentee status. As a result, you get voters with absentee status -- but no absentee ballot -- showing up on Election Day, and being told that they already have a ballot.
Then what? Well, if a voter is persistent and/or the poll workers well-trained and not swamped, then a poll worker will help the voter understand how to vote provisionally -- mark a ballot that does not go into the ballot box, but rather into an envelope with the voter's info. After the election, all these provisional ballot envelopes go to county election HQ, where election officials have to process each envelope, to decide whether the ballot inside should be counted.
Now, the 100,000 estimate kicks in. In a small county with thousands of provisional ballots, or a large county with tens of thousands, the provisional ballot processing can easily go all night and into the next day, because it can't even begin until all absentee ballots have been centrally counted, folded into the results from precincts, and tabulated as preliminary election results. Now suppose that statewide, the margin of victory for the presidential election is only tens of thousands of votes, and statewide there are 100,000+ provisional ballots that are yet to be counted?
In that case, provisional ballot processing is going to receive a lot of scrutiny, and every one of those non-counted ballots is going to be subjected to the type of controversy we saw in Minnesota 4 years ago with the Franken-Coleman senate contest that took weeks to resolve. And this is the situation that has many Ohio election officials (and me) praying that whatever the election result is, the margin is wider than the number of provisional ballots.
This situation is rooted in a voter records system that's too complicated and clunky for harried, under-funded, under-staffed, hard-working election officials to use reliably. So if you doubted that ordinary information technology could create a possible election meltdown just as easily as flaky proprietary voting systems, well, now you know. And that's just one reason why we've been hard at work on registration-related technology -- try to help create the public benefit of an election that is and can be seen to have been administered correctly, before the ballot counting even begins.
Keep those fingers crossed …
For those of you who have been following the recount saga in Wisconsin, here is a bit of news, and a reflection on that. So, the news from a couple of days ago (I'm just catching up) is that the process of re-counting is complete, but the resolution of that close election may not be. The re-counting did not change which candidate is leading, and apparently expanded the margin slightly.
Trailing candidate Joanne Kloppenburg explains her motivation for the recount in a newspaper letter to the editor, building on the old but true assertion that, "One may be entitled to their own opinions, but they are not entitled to their own facts."
We steer clear of political food fights, and I have no opinion on her motivation. But we are all about transparency and transparency should not have any political agenda attached.
To that end, what Kloppenburg does point about some of the irregularities, problems, and issues with the re-counting process (which are not the same as the problems with the original count), including lack of physical security on ballots, and uncertainty as to whether the re-counted ballots were the same ballots as the originally counted ones -- are reasonable questions about transparency. More importantly, Kloppenburg offers some reflections about the re-count that are important and correctly apolitical:
When races are this close, there is a significant public interest established both by statute and by common sense in determining that votes were counted and counted accurately.
This election was close, and there were many who have expressed doubts about whether it was clean. The right to vote is fundamental. It is a right that courageous people fight and die for every day. In America, that right carries with it a promise: that elections are fair and open, that election results are untainted by deceit or fraud, and that the electoral process provides every eligible voter with an equal opportunity to privately and independently cast a ballot.
In order to make that promise real, there are appropriate and established steps that help make sure the outcome of elections, when in doubt, can withstand scrutiny. That, no more and no less, is exactly why this recount is so important.
That is, in fact, a fine description of the purpose of a recount.
It's unfortunate that in this particular case, the re-count process seems to have a similar or greater level of problems that cast doubt on the result. We can only hope that the full scope of the process, warts and all, becomes transparent to the public.
For me, I find that regardless of candidate or political preferences, there is a point couched in the last two sentences excerpted from her letter that matters most:
...there are appropriate and established steps that help make sure the outcome of elections, when in doubt, can withstand scrutiny
Transparency in process. There should be nothing political about that.
Continuing our Bedrock election story (see parts one, two, and three if you need to catch up), we find the County of Bedrock Board of Elections staff, including design guru Dana Chisel, in the "ballot design studio," a dusty back room of the BBoE. Chisels in hand, staffers ponder the blank slate, or rather sandstone, of sample ballot slabs on easels. With the candidate and referendum filing periods closed and the election only a couple weeks away, it's time to make the ballots.
Now, you might think that the ballot consists of the 3 items we know of - the race for Mayor, the race for Quarry Commission, and the question on the quarry fee. However, recall that each precinct in Bedrock County has a distinct set of districts. In this election, each precinct has a distinct ballot with a distinct set of contests corresponding to the districts that the precinct is part of. At a first cut, the contests by precinct are:
- Downtown-001: the contest for mayor, and the referendum on quarry fees;
- Quarrytown-002: the contests for mayor and quarry commissioner, and the referendum on quarry fees;
- QuarryCounty-003: the contest for quarry commissioner, and the referendum on quarry fees;
- County-004: the referendum on quarry fees.
You'll note that only Town residents -- in Precincts 1 or 2 -- are entitled to vote for mayor, while residents of the Mineral District -- in Precincts 2 or 4 -- are the only voters entitled to for Quarry Commissioner. Last, all voters in the county are eligible to vote on county revenue issues such as taxes and fees imposed by the county.
That, plus the list of candidates and the text of the referendum, comprise what might be called the content of each of the 4 ballots, or the ballot configuration. But the ballots themselves need to be designed: the ballot items have to appear in some order, and the candidates likewise; the ballot items have to be arranged in some visual design, vertically or horizontally, with sufficient space between each, fitting the size of ballot slates that they will be etched on … and so on.
So, armed with chisels, the proverbial blank slate, and several tablets stating the legal requirements for contest and candidate order, design guru Dana Chisel marks out a prototype ballot containing all the requisite ballot content, laid out according to usability principles known since the Stone Age (left justified text, instructions separate from content, instructions with simple words along with pictures, and more). After a few tries and consultation with their boss Rocky, they have a design model for each of the 4 ballots. The next step are usability testing with volunteer voters, and using the results to create the final slabs that serve as the model for each ballot style. Then they're ready for mass reproduction of ballots for the upcoming election -- get those duplidactylsaurs into action!
Now, you might think that they're ready for election day, but wait there's more, including the preparation of pollbooks, and then early voting, and then eventually election day operations.
Next time: Pollbooks and Early Voting
At the end of our last visit to the fictional Town of Bedrock, we left Fred as he applied to run for mayor. Now we'll continue the story, but with a focus on Bedrock itself, in order to continue building up a detailed, yet simplified, account of actual U.S. election practice. The focus is on Bedrock rather than its colorful denizens, because the answer to the current question -- can Fred be a candidate for mayor in the upcoming election? -- lies partly in the details of Cobblestone County and Town of Bedrock, how they are structured and administered for elections. At a first glance of the Bedrock County map, you'll see that the Town of Bedrock is entirely in Cobblestone County, dividing the county into two regions, the part that is incorporated in the Town, and the unincorporated portion.
Look a bit more closely though, and you'll see the Mineral District -- not a town but a political division called an electoral district (in some states in the U.S., called a jurisdiction rather than a district). The Mineral District in the part of the county that's affected by quarrying operations at the Bedrock Quarry, and the Bedrockites who live there get to elect the Quarry Commission to regulate the Quarry. Look a bit more carefully and you'll notice that part of the Mineral District is in the Town of Bedrock, and the rest is in the unincorporated county.
To keep our Election Tale simple, that's almost all of the electoral structure of Cobblestone County that is the jurisdiction of the Bedrock BoE. The remaining part may be a bit more familiar: the precincts. Each precinct is a region in which all of the voters are entitled to vote on exactly the same ballot items; put another way, in one precinct all of the voters reside in exact same set of electoral districts. So in Bedrock County, there are 4 precincts:
- The "Downtown-001" precinct, part of two districts: the district of the Town of Bedrock, and the district for Bedrock County;
- The "Quarrytown-002" precinct, part of those same two districts, plus the Mineral District;
- The "QuarryCounty-003" precinct, part of the Mineral District and the County;
- The "County-004" precinct, part of just the district for the County.
Looking a little more carefully, you'll notice the Flintstone residence is in the QuarryTown-002 precinct, which means the Flintstones (or at least those of them that are registered voters) are eligible to run for offices in either the Town or the Quarry District. To say that more generally, in order to be eligible to run for an office, you have to reside in the district that the office is part of. Fred wants to run for Mayor of the Town of Bedrock, so he has to reside in the Town of Bedrock.
Back at the BBoE, Rocky has completed the eligibility check for Fred, having ensured that:
- he resides in the Town of Bedrock,
- he is registered to vote,
- his current address matches the address in his voter record,
- he is not serving jail time,
and perhaps some other eligibility requirements in Stone Age election law that we are not aware of. Fred is satisfied to find that on the Bedrock slab-site's Upcoming Election slab, he is listed as a candidate for mayor. However, there is also a bit of a surprise: his neighbor Betty Rubble is running against him! And also Barney Rubble is running for Fred's old Quarry Commission seat. Also, the commission's clerical errors seem to have been resolved, and the quarry fee referendum will be on the ballot. With a few more days of filing time left, an irritated Fred ponders who lives in the Mineral District, that might be convinced to run against Barney.
Next Time: it's time for ballot design - get out your Chisel!
Yesterday, judges in New York state were hearing calls for hand recount, while elsewhere other vote counts were being factored into the totals, and on the other side of the Atlantic, the same question "where are the election results?" was getting very serious. In the Ivory Coast, like in some places in the U.S., there is a very close election that still isn't decided. There, it's gotten serious, as the military closed off all points of entry into the country as a security measure related to unrest about the close election and lack of a winner. Such distrust and unrest, we are lucky to have avoided here; despite the relatively low levels of trust in U.S. electoral processes (less than half of eligible people vote, and of voters polled in years past a third to a half were negative or neutral), we are content to let courts and the election finalization process wind on for weeks. OK, so maybe not content, maybe extremely irate and litigious in some cases, but not burning cars in streets.
That's why I think it is particularly important that Americans better understand the election finalization process -- which of course like almost everything in U.S. elections varies by state or even locality. But the news from Queens NY (New York Times, "A Month After Elections, 200,000 Votes Found") though it sounds awful in headline, is actually enormously instructive -- especially about our hunger for instant results.
It's not awful; it's complicated. As the news story outlines, there is a complicated process on election night, with lots of room for human error after a 16 hour day. The finalization process is conducted over days or weeks to aggregate vote data and produce election results carefully, catching errors, though usually not changing preliminary election-night results. As Douglas A. Kellner, co-chairman of the State Board of Elections, said:
The unofficial election night returns reported by the press always have huge discrepancies — which is why neither the candidates or the election officials ever rely on them.
That's particularly true as NY has moved to paper optical scan voting from lever machines, and the finalization process has changed. But in the old days, it was possible to misplace one or a few lever machine's worth of vote totals with human errors in the paper process of reading dials, writing numbers on reporting form sheets, transporting the sheets, etc. Then, add to that the computer factor for human error, and you get your 80,000 vote variance in Queens.
Bottom line -- when an election is close, of course we want the accurate answer, and getting it right takes time. Using computerized voting systems certainly helps with getting quicker answers for contests that aren't close and won't change in the final count. And certainly they can help by enabling audits and recounts that lever machines could not. But for close calls, it's back to elbow grease and getting out the i-dotters and t-crossers -- and being thankful for their efforts.