Tagged voting system

Voter registration problems in Maryland signal larger vulnerabilities for upcoming elections

Binary data disappears in a dark hole

Voter registration data lost in Maryland

This Monday, state officials in Maryland acknowledged that problems with their “motor voter” systems are more significant than originally described:

[A]s many as 80,000 voters — nearly quadruple the original estimate — will have to file provisional ballots Tuesday because the state Motor Vehicle Administration failed to transmit updated voter information to the state Board of Elections.

— Up to 80,000 Maryland voters will have to file provisional ballots, state says (Washington Post. 6/25/18)

This announcement, made only hours before the polls opened for Maryland’s Tuesday primary, will mean more than just a minor inconvenience for the tens of thousands of voters affected. Sen. Joan Carter Conway (D-Baltimore City), chairwoman of the Senate Education, Health and Environment Committee, said that this situation will “confuse voters, suppress turnout, and disenfranchise thousands of Marylanders.”

Yet the significance of this programming error is broader still. Sen. Richard S. Madaleno Jr. (D-Montgomery), who is also running for governor of Maryland, called the incorrect registration of thousands of voters a “catastrophic failure.” In his statement, he continued, “The chaos being created by this failure subjects real harm to our most cherished democratic values,”

Is this election season hyperbole? Not at all, says John Sebes, Chief Technology Officer of the OSET Institute (the organization that runs the Trust The Vote project). In his recent article, Maryland Voter Registration Glitch: A Teachable Snafu, Mr. Sebes identifies the wide-ranging problems that will follow from these kind of disruptions at a larger scale:

If a foreign adversary can use cyber-operations to maliciously create a similar situation at large scale, then they can be sure of preventing many voters from casting a ballot.  With that disruption, the adversary can fuel information operations to discredit the election because of the large number of voters obstructed.

— John Sebes, OSET Institute

It is, in fact, the credibility of the entire election itself that is at stake. These kinds of technical problems don’t need to be the result of nefarious interference in the election process. Mr. Sebes continues,

The alleged system failure (hack, glitch, or whatever) doesn’t even need to be true!  If this accidental glitch had occurred a couple of days before the November election, and came on the heels of considerable conversation and media coverage about election hacking, rigging, or tampering then it would be an ideal opportunity for a claimed cyber-attack as the cause, with adversaries owning the disruptive effects and using information operations to the same effect as if it were an actual attack.

—  Maryland Voter Registration Glitch: A Teachable Snafu by John Sebes

Maryland is clearly vulnerable to this kind of attack on the credibility of their electoral process. Already, some are sounding the alarm that these voter registration problems weren’t identified quickly — plus, there’s no way to verify the process itself:

Damon Effingham, acting director of the Maryland chapter of Common Cause, said it was “preposterous” that it took MVA officials four days to figure out the extent of the problem and that there is no system to ensure that its system is working properly.

— Up to 80,000 Maryland voters will have to file provisional ballots, state says (Washington Post. 6/25/18)

What’s the solution?

John Sebes and the Trust The Vote project have spent years developing open source election software and systems to address these issues. But that alone isn’t sufficient. Mr. Sebes identifies the steps that election officials can take now to prevent the kind of problems that Maryland is experiencing this week:

  • “It’s partly a technology effort to re-engineer election systems to be less fragile from errors and less vulnerable to attack.”
  • “How to ensure the correctness and integrity of poll books[?] … that depends on emerging open data standards and the question of certification of poll books.”
  • “Given the great importance of public credibility … election officials must also plan for proactive public communication.”

Mr. Sebes concludes:

The Maryland glitch is not so much about failed integration of disparate data systems, but much more about unintentional catalyzing of opportunities to mount “credibility attacks” on elections and the need for a different kind of preparation.

Read the full article, Maryland Voter Registration Glitch: A Teachable Snafu by John Sebes, on the OSET Institute website.

The OSET Institute runs the TrustTheVote Project, a real alternative to nearly obsolete, proprietary voting technology. TrustTheVote is building an open, adaptable, flexible, full-featured and innovative elections operating system called ElectOS. It supports all aspects of elections administration and voting including creating, marking, casting, and counting ballots, as well as managing all back-office functions. Check out this overview of the TrustTheVote Project to learn more. If you’re involved in the election process, as an election official, or an academic or researcher, join the TrustTheVote Project as a stakeholder to help develop and deploy open, secure, reliable, and credible election technologies. If you’re concerned about the health of our election systems, you can donate or volunteer. If you have any questions about the TrustTheVote Project, contact us today.

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 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.

Read more

Election Standards – Part Two

Last time I reported on the first segment of the annual meeting of the Voting Systems Standards Group (VSSC) of the IEEE. Most of that segment was about the soon-to-be-standard for election definition and election results (called VSSC.2). I recapped some of the benefits of data standards, using that as an example.  Much of the rest of day one was related to that standard in a number of ways. First, we got an update on the handful of major comments submitted during the earlier review periods, and provided input on how to resolve these finalize the standard document. Second, we reviewed suggestions for other standards that might be good follow-on efforts.

What’s in a Name?

One example of the comments concerned the issue that I mentioned previously (concerning aggregation), that the object identifiers in one VSSC.2 dataset might have no resemblance to identifiers in another dataset, even though the two datasets were referring to some of the same real-world items described by the objects. We discussed a couple existing object naming standards for election data, FIPS and OCD-IDs. FIPs is a federal standard for numeric identification for states, counties, townships, municipalities, and related minor civil divisions (as well as many other things not related to elections).

That’s useful because those types of real-world entities are important objects in election definitions, and it’s very handy to have standard identifiers for them. However, FIPS is not so useful because there loads of other kinds of real-world entities that are electoral districts, but not covered by FIPS. In fact, there are so many of them and in such variety, that no one really knows all of the types districts in use in the U.S. So we really don’t have a finished standard naming scheme for U.S. electoral districts. We also discussed the work of the Open Civic Data project, specifically their identifier scheme and repository, abbreviated as OCD-IDs.

More on that in the report from Day 2, but to make a long story short, the consensus was that the VSSC.2 standard was just fine without a unique ID scheme, and that a new standard specifically for standardized IDs was not a large need now.

Supporting Audits

That’s one possible new standard, related to the .2 standard, that we considered and deferred. Two others got the thumbs up, at least at the level of agreement to form a study group, which is the first step. One case was pretty limited: a standard for cast-vote records (CVRs) to support ballot audits with an interoperable data standard. To only slightly simplify, one common definition of a CVR is a record of exactly what a ballot-counting device recorded from a specific ballot, the votes of which are included in a vote tally created by the device. Particularly helpful is the inclusion of a recorded image of the ballot. With that, a person who is part of a typical ballot audit can go though a batch of ballots (typically all from the same precinct) and decide whether their human judgment agrees with the machine’s interpretation, based on the human’s understanding of relevant state election law.

Support for audits with CVRs is a fundamental requirement for voting systems, so this standard is pretty important. It’s scope is limited enough that I hope we can get it done relatively quickly.

More to Come

The other study group will be looking at the rather large issue of standardizing an election definition, beyond the level of the .2 standard. That standard is very useful for a number of purposes (including election result reporting) but intentionally limited to not try to be a comprehensive standard. The study group will be looking at some use cases that might guide the definition of a smaller scope, that could be a timely a right-sized step from .2 toward a truly comprehensive standard. My personal goal, which I think many share, is to look at the question of what else, besides what we already have in .2, is needed for an election definition that could support ballot layout at least at the level of sample ballots. I like that of course, because we already documented the TrustTheVote requirements for that when we developed the sample-ballot feature of the Voter Services Portal.

Onward to day 2!

— EJS

PS: For more on the Voter Services Portal …  production version of VSP in Virginia is at https://www.vote.virginia.gov and the demo version is described at PCEA’s web site http://www.supportthevoter.gov and http://web.mit.edu/vtp/ovr3.html with an interactive version at http://va-demo.voterportal.trustthevote.org

Comments Prepared for Tonight’s Elections Technology Roundtable

This evening at 5:00pm members of the TrustTheVote Project have been invited to attend an elections technology round table discussion in advance of a public hearing in Sacramento, CA scheduled for tomorrow at 2:00pm PST on new regulations governing Voting System Certification to be contained in Division 7 of Title 2 of the California Code of Regulations.

Due to the level of activity, only our CTO, John Sebes is able to participate.

We were asked if John could be prepared to make some brief remarks regarding our view of the impact of SB-360 and its potential to catalyze innovation in voting systems.  These types of events are always dynamic and fluid, and so we decided to publish our remarks below just in advance of this meeting.

Roundtable Meeting Remarks from the OSDV Foundation | TrustTheVote Project

We appreciate an opportunity to participate in this important discussion.  We want to take about 2 minutes to comment on 3 considerations from our point of view at the TrustTheVote Project.

1. Certification

For SB-360 to succeed, we believe any effort to create a high-integrity certification process requires re-thinking how certification has been done to this point.  Current federal certification, for example, takes a monolithic approach; that is, a voting system is certified based on a complete all-inclusive single closed system model.  This is a very 20th century approach that makes assumptions about software, hardware, and systems that are out of touch with today’s dynamic technology environment, where the lifetime of commodity hardware is months.

We are collaborating with NIST on a way to update this outdated model with a “component-ized” approach; that is, a unit-level testing method, such that if a component needs to be changed, the only re-certification required would be of that discrete element, and not the entire system.  There are enormous potential benefits including lowering costs, speeding certification, and removing a bar to innovation.

We’re glad to talk more about this proposed updated certification model, as it might inform any certification processes to be implemented in California.  Regardless, elections officials should consider that in order to reap the benefits of SB-360, the non-profit TrustTheVote Project believes a new certification process, component-ized as we describe it, is essential.

2. Standards

2nd, there is a prerequisite for component-level certification that until recently wasn’t available: common open data format standards that enable components to communicate with one another; for example, a format for a ballot-counter’s output of vote tally data, that also serves as input to a tabulator component.  Without common data formats elections officials have to acquire a whole integrated product suite that communicates in a proprietary manner.  With common data formats, you can mix and match; and perhaps more importantly, incrementally replace units over time, rather than doing what we like to refer to as “forklift upgrades” or “fleet replacements.”

The good news is the scope for ballot casting and counting is sufficiently focused to avoid distraction from the many other standards elements of the entire elections ecosystem.  And there is more goodness because standards bodies are working on this right now, with participation by several state and local election officials, as well as vendors present today, and non-profit projects like TrustTheVote.  They deserve congratulations for reaching this imperative state of data standards détente.  It’s not finished, but the effort and momentum is there.

So, elections officials should bear in mind that benefits of SB-360 also rest on the existence of common open elections data standards.

3. Commercial Revitalization

Finally, this may be the opportunity to realize a vision we have that open data standards, a new certification process, and lowered bars to innovation through open sourcing, will reinvigorate a stagnant voting technology industry.  Because the passage of SB-360 can fortify these three developments, there can (and should) be renewed commercial enthusiasm for innovation.  Such should bring about new vendors, new solutions, and new empowerment of elections officials themselves to choose how they want to raise their voting systems to a higher grade of performance, reliability, fault tolerance, and integrity.

One compelling example is the potential for commodity commercial off-the-shelf hardware to fully meet the needs of voting and elections machinery.  To that point, let us offer an important clarification and dispel a misconception about rolling your own.  This does not mean that elections officials are about to be left to self-vend.  And by that we mean self-construct and support their open, standard, commodity voting system components.  A few jurisdictions may consider it, but in the vast majority of cases, the Foundation forecasts that this will simply introduce more choice rather than forcing you to become a do-it-yourself type.  Some may choose to contract with a systems integrator to deploy a new system integrating commodity hardware and open source software.  Others may choose vendors who offer out-of-the-box open source solutions in pre-packaged hardware.

Choice is good: it’s an awesome self-correcting market regulator and it ensures opportunity for innovation.  To the latter point, we believe initiatives underway like STAR-vote in Travis County, TX, and the TrustTheVote Project will catalyze that innovation in an open source manner, thereby lowering costs, improving transparency, and ultimately improving the quality of what we consider critical democracy infrastructure.

In short, we think SB-360 can help inject new vitality in voting systems technology (at least in the State of California), so long as we can realize the benefits of open standards and drive the modernization of certification.

 

EDITORIAL NOTES:
There was chatter earlier this Fall about the extent to which SB-360 allegedly makes unverified non-certified voting systems a possibility in California.  We don’t read SB-360 that way at all.  We encourage you to read the text of the legislation as passed into law for yourself, and start with this meeting notice digest.  In fact, to realize the kind of vision that leading jurisdictions imagine, we cannot, nor should not alleviate certification, and we think charges that this is what will happen are misinformed.  We simply need to modernize how certification works to enable this kind of innovation.  We think our comments today bear that out.

Moreover, have a look at the Agenda for tomorrow’s hearing on implementation of SB-360.  In sum and substance the agenda is to discuss:

  1. Establishing the specifications for voting machines, voting devices, vote tabulating devices, and any software used for each, including the programs and procedures for vote tabulating and testing. (The proposed regulations would implement, interpret and make specific Section 19205 of the California Elections Code.);
  2. Clarifying the requirements imposed by recently chaptered Senate Bill 360, Chapter 602, Statutes 2013, which amended California Elections Code Division 19 regarding the certification of voting systems; and
  3. Clarifying the newly defined voting system certification process, as prescribed in Senate Bill 360.

Finally, there has been an additional charge that SB-360 is intended to “empower” LA County, such that what LA County may build they (or someone on their behalf) will sell the resulting voting systems to other jurisdictions.  We think this allegation is also misinformed for two reasons: [1] assuming LA County builds their system on open source, there is a question as to what specifically would/could be offered for sale; and [2] notwithstanding offering open source for sale (which technically can be done… technically) it seems to us that if such a system is built with public dollars, then it is in fact, publicly owned.  From what we understand, a government agency cannot offer for sale their assets developed with public dollars, but they can give it away.  And indeed, this is what we’ve witnessed over the years in other jurisdictions.

Onward.

“Why is There a Voting Tech Logjam in Washington

“Why is There a Voting Tech Logjam?” — that’s a good question! A full answer has several aspects, but one of them is the acitivty (or in-activity) at the Federal level, that leads to very limited options in election tech. For a nice pithy explanation of that aspect, check out the current issue of the newsletter of the National Conference of State Legislators, on page 4.

One really important theme addressed here is the opportunity for state lawmakers to make their decisions about what standards to use, to enable the state’s local election officials make their decisions about what technology to make or adopt — including purchase, in-house build, and (of course) adoption and adaptation of open-source election technology.

— EJS

TrustTheVote on HuffPost

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 votingno 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.

— EJS

PS: If you catch us on HP online, please let us know what you thought!

Voting System (De)Certification, Reloaded (Part 3 of 2)

Thanks to some excellent recent presentations by EAC folks, we have today a pleasant surprise of an update to our recent blogs Voting System Decertification: A Way Forward (in Part 1 and Part 2). As you might imagine with a government-run test and certification program, there is an enormous amount of detail (much of it publicly available on the EAC web site!) but Greg and I have boiled it down to a handful of point/counterpoints. Very short version: EAC seems to be doing a fine job, both in the test/certification/monitoring roles, and in public communication about it. At the risk of oversimplifying down to 3 points, here goes:

1. Perverse Incentive

Concern: ES&S’s Unity 3.2.0.0 would be de-certified as a result of EAC’s investigation into functional irregularities documented in Cuyahoga County, Ohio, by erstwhile elections direction Jane Platten (Kudos to Cuyahoga). With the more recent product 3.2.1.0 just certified, the “fix” might be for customers of 3.2.0.0 to upgrade to the latest version, with unexpected time and unbudgeted upgrade expense to customers, including license fees. If so, then the product defect, combined with de-certification, would actually benefit the vendor by acting to spur customers toward paid upgrades.

Update: Diligent work at EAC and ES&S has resulted in in ES&S providing an in-place fix to its 3.2.0.0 product, so that EAC doesn’t have to de-certify the product, and customers don’t have to upgrade. In fact, one recent result of EAC’s work with Cuyahoga County, the county was able to get money back from the vendor because of the issues identified.

Next Steps: We’ll be waiting to hear whether the fix is provided at ES&S’s expense (or at least no cost to customers), as it appears may be the case. We’ll also be watching with interest the process in which version 3.2.0.0+ fix goes through the test and certification process to get legal for real use in elections. As longtime readers know, we’ve stressed the importance of the emergence of a timely re-certification process for products that have been certified, need a field update, and need the previously used test lab to test the updated system with testing that is as rigorous as the first time, but less costly and more timely.

2. Broken Market

Concern: This situation may be an illustration of the untenable nature of of a market that would require vendors to pay for expensive testing and certification efforts, and to also have to forego revenue when otherwise for-pay upgrades are required because of defects in software.

Update: By working with the vendor and their test lab on both the earlier and current versions of the product, all customers will be able to obtain a no-fee update of their existing product version, rather than being required to do a for-fee upgrade to a later product version. Therefore, the “who pays for the upgrade?” question applies only to those customers who actually want to to pay for the latest version.

Next Steps: Thanks to the EAC’s new process of publishing timelines for all product evaluation versions, it should be possible to compare the timeframe for the original 3.2.0.0 testing, the more recent 3.2.1.0 testing, and the testing of the bug fixed version of 3.2.0.0. We can hope that this case demonstrates that a re-certification process can indeed be equally rigorous, less costly, and more timely.

ES&S Evaluation Timeline

ES&S Evaluation Timeline

3. Lengthy Testing and Certfication

Concern: The whole certification testing process costs millions and takes years for these huge voting system products of several components and dozens of modules of software. How could a re-test really work at a tiny fraction of a fraction of that time and cost?

Update: Again, thanks to publishing those timelines, and with experience of recent certification tests, we can see the progress that EAC is making towards their goal that an end-to-end testing campaign of a system to be less than 9 months and a million dollars, perhaps even quarter or a third less. The key, of course, is that a system be ready for testing. As we’ve seen with some of the older systems that simply weren’t designed to meet current standards, and weren’t engineered with a rigorous and documented Q&A process that could be disclosed to a test lab to build on, well, it can be a lengthy process — or even one that a vendor withdraws from in order to go back and do some re-engineering before trying again.

Next Steps: A key part of this time/cost reduction is EAC’s guidance to vendors on readiness for testing. That guidance is another relatively recent improvement by EAC. We can hope for some public information in future about how the readiness assessment has worked, and how it helped a test process get started right. But even better, EAC folks have again repeated a further goal for time/cost reduction, but moving to voting system component certification, rather than certifying the whole enchilada – or perhaps I should say, a whole enchilada, rather than the whole plato gordo of enchilada, quesadillas, and chile relleno, together with the the EMS for it all with its many parts – rice, frijoles, pico de gallo, fresh guacamole … (I detect an over-indlugence in metaphor here!)

One More Thing: As we’ve said before, we think that component level testing and re-testing is the Big Step to get whole certification scheme into a shape that really serves its real customers – election officials and the voting public. And we’re proud to jump in and try it out ourselves — work with EAC, use the readiness assessment ourselves, do a pilot test cycle, and see what can be learned about how that Big Step might actually work in the future.

— EJS

Introducing the TrustTheVote Tabulator

Taking a break from news and commentary on election operations issues, I thought it would be an appropriate time to talk about current TrustTheVote project efforts that are very relevant to the activities of many election officials right now: tabulating election results, as part of the process of certifying results and finishing the operations for the 2 Nov. election.

First of all, what is “tabulation”? The word can mean several things in the election context, but we use it to describe the final step of gathering vote data. At the end of election day, there are a number of counting devices that have counted votes on ballots, for example, optical scan counting machines that recorded votes from paper ballots, or DREs that directly recorded votes cast on a computer. Each of these devices has a blob of data that includes what some call “tallies” — that is, for each ballot candidate or referendum choice, the total number of votes cast for that choice on that counting device. (Confusingly, some vendors call these counting machines “Tabulators” as well.)

“Tabulation” is the process of aggregating all that tally data, checking it for completeness and correctness, andcombining it into a larger tally of all votes cast in the election jurisdiction. In some cases, like a county commissioner contest, that combined tally represents the election results, the total number of votes for each candidate in the contest. In state and Federal contests and questions, the jurisdictional tally is only part of a total, e.g. one county’s totals for a state or Federal Senate contest, that is then used by state level officials when they aggregate several count totals to create state-level election results.

With that in mind, the next question is: how is tabulation performed? Well, in the TTV system that we’re building, tabulation is done by a dedicated system called (boringly enough) the “Tabulator” that does nothing but tabulation. However, in the proprietary voting systems in use today, there is no Tabulator per se. Tabulation is done as one of many functions of a larger body of software. Here are two examples.

  • For some of the older DRE systems, one DRE can serve as an “aggregator” for a group of DREs. Election officials remove magnetic storage media from each DRE, to get the tally data out of the DRE; then one by one they insert the media into the aggregator, which combines all the tally data and writes it out to another storage media. Not a bad idea, aggregation, but not such a good idea for the aggregator to be one function of a device whose main job in life is sensing voters’ fingers on a touch screen.
  • For more recent voting systems, tabulation is one among many functions of a voting system component that is sometimes called the “election management system” or EMS. One definition of an EMS is: a software system that implements every voting system function that isn’t done by a separate voting machine. Tabulation is just one of those functions, along with keeping a database of precincts, districts, splits, polling places, counting devices, candidates, contests, questions, ballot contest order, ballot candidate order, candidate rotations, ballot configurations, actual ballot documents, and of course lots of software and user interface for managing all of this election management data and generating reports from it.

Why is this a bad idea? Tabulation is among the most important functions of a voting system, and if the tabulation software doesn’t work right, then the election results can be wrong. Lumping tabulation software in with a bunch of other related software means that errors elsewhere in the lump can effect tabulation; and every time the software in the lump is changed, it could effect the tabulation software even if the tabulation software hasn’t changed. And worse, in today’s proprietary closed system, it is just not feasible to know whether tabulation software has been effected by any other element of the total system.

And even worse, tabulation is so simple and so important that the software for it should rarely need modification at all! And further still, the larger and more complex you make a lump of software, the greater the odds that a bug somewhere in the lump (and all software has bugs) will effect the correct operation of one or more parts of the lump. In software engineering-speak, large monolithic systems, with code changes accreted over years, are much more likely to fail than a composite system of separate modules, each of which is largely insulated from changes to and errors in other modules.

Introducing the TTV Tabulator: a completely separate, hardened, single-purpose computing device for doing nothing but tabulation, and doing it in a completely transparent way where people can feasibly check on the correct operation of the software. We’re at work now on getting the Tabulator ready for outside testing, so the timing of this introduction is doubly timely. In future breaks from other blog streams, I’ll be saying more about this deceptively simple computing device, how it works, why it works that way, and how it delivers on the needed transparency and accountability.

— EJS

NY Times: Hanging Chad in New York?

NYT reported on the continuing counting in some New York elections, with the control of the NY state house (and hence redistricting) hanging in the balance. The article is mostly apt, but the reference to “hanging chad” is not quite right. FL 2000’s hanging chad drama was mainly about the ridiculous extreme that FL went to in trying to regularize the hand re-counting rules for paper ballots, while each time a ballot was touched, the rule could change because the chad moved.

In this NY election, the problem is not a re-count, but a slow count; not problems with the paper ballots per se, but with the opscan counting system; and not a fundamental problem with the ballot counting method, but several problems arising from poll-worker and election officials’ unfamiliarity with the system, being used for the first time in this election. Best quote:

Reginald A. LaFayette, the Democratic chairman of the Board of Elections in Westchester, said older poll workers had trouble reading the vote tallies printed out by the machines. “You take the average age of an inspector, it’s maybe about 65, and so you put a new product out with them, and the change has been overwhelming to some of them,” he said.

It’s another example of the of situation I recently described in North Carolina. These voting systems were built for time-to-market, rather than designed, engineered, and tested for usability and reliability — much less designed for simplicity of the process of combining tallies into election results.

The recent experience in New York is nothing truly new – but rather an example of the usability issues manifested in an election organization that, unlike those elsewhere using similar voting system products, has not yet learned by experience how to use these quirky systems with greater speed and transparency than the first time around. Of course, it is a shame that this type learning-by-doing in real elections is necessary at all, to get to a reasonably transparent election process. But that’s what the vendors served up the market, and that’s what TTV is working to improve on.

— EJS

San Francisco Voting Task Force Public Hearing

Tomorrow night starting at 4:30PM the San Francisco Voting Systems Task Force is holding a Public Hearing to intake testimony and public comment on its draft prospective recommendations topics.  [Disclosure: I am a member of this Task Force, appointed by the S.F. City & County Board of Supervisors.]

We encourage everyone who can make it to attend and give us your input on these draft proposed recommendations.  This is an early stage document and does not represent any final recommendations of the VSTF.  The Agenda and description can be found here.  The location of the meeting is:

SFCitySeal1 Dr. Carlton B. Goodlett Place,
Room 34 Lower Level

San Francisco, California

If you can’t make it in person, no worries as we’re accepting written input through the 24th of February, which you can submit digitally if you wish to: voting.systems.task.force@sfgov.org or by U.S. Mails (address details on site here).

For those interested in some details; I submitted a letter to the Task Force Chair with some comments of my own on our Draft recommendations under consideration document, and you may wish to have a look at them here.

Cheers
GAM|out