Tagged tabulator

Vote Adding Machine Problems in FL — We Have to Fix That!

Despite today’s blog docket being for RockTheVote, I just can’t resist pointing out a recurring type of technology-triggered election dysfunction that is happening again, and is 100% preventable using election technology that we have already developed.

Here’s the scoop: in St. Lucie County, Florida, the LEOs are having trouble coming up with a county wide grand total of votes, because their adding machine (for totting up the the subtotals from dozens of voting machines) has a great feature for human error. The full details are bit complex in terms of handling of data sticks and error messages, but I’ve been told that in early voting in 94 precincts, 40 precincts weren’t counted at all, and 54 were counted twice. Thank goodness someone noticed afterwards! (Well, 108 precincts totaled out of 94 might have been a tip off.) Sure, human error was involved, but it is not a great situation where software allows this human error to get through.

We’re only talking about software that adds up columns of numbers here! A much better solution would be one where the software refuses to add in any sub-total more than once, and refuses to identify as a finished total anything where there is a sub-total missing. Of course! And I am sure that the vendor of St. Lucie’s GEMS system has a fix for this problem in some later version of the software or some successor product. But that’s just not relevant if an election official doesn’t have the time, budget, support contract, or procurement authority to test the better upgrade, and buy it if it works satisfactorily!

What’s sad is that it is completely preventable by using an alternative adding machine like the one we developed last year (OK, shameless plug) — which of course does all these cross-checks. The LEOs would need to translate that vendor-proprietary subtotal data into a standard format — and I know some volunteer programmers who I bet would do that for them. They’d need to use an ordinary PC to run the open source tabulation software — and I know people who would set it up for them as a public service.  And they’d have to spend less than half an hour using the system to get their totals, and comparing them to the totals that their GEMS system provided.

And maybe, in order for it to be kosher, it would have to be a “pilot effort” with oversight by the EAC; we’ve already discussed that with them and understand that the resource requirements are modest.  I bet we could find a FL philanthropist who would underwrite the costs without a 2nd thought other than how small the cost was compared to the public benefit of the result – that is, avoiding one more day of delay in a series that’s causing a State to not be done with the election, more than a week after election day.

It’s just one example of the many possible election integrity benefits that can be demonstrated using technology that, so far at any rate, only non-commercial technologists have been willing to develop for governments to use to do their job correctly — in this case, producing timely and accurate election results.


“Where Are the Vote Counts?” From New York to Ivory Coast

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.


Tabulator Troubles in Colorado

More tabulator troubles! In addition to the continuing saga in New York with the tabulator troubles I wrote about earlier, now there is another tabulator-related situation in Colorado. The news report from Saguache County CO is about:

a Nov. 5 “retabulation” of votes cast in the Nov. 2 election Friday by Myers and staff, with results reversing the outcome …

In brief, the situation is exactly about the “tabulation” part of election management, that I have been writing about. To recap:

  • In polling places, there are counting devices that count up votes from ballots, and spit out a list of vote-counts for each candidate in each contest, and each option in each referendum. This list is in the form of a vote-count dataset on some removable storage.
  • At county election HQ, there are counting devices that count up vote-by-mail ballots and provisional ballots, with the same kind of vote-counts.
  • At county election HQ, “tabulation” is the process aggregating these vote-counts and adding them up, to get county-wide vote totals.

In Saguache, election officials did a tabulation run on election night, but the results  didn’t look right. Then on the 5th, they did a re-run on the “same ballots” but the results were different, and it appears to some observers that some vote totals may be been overwritten. Then, on the 8th, with another re-try, a result somewhat like in NY:

… the disc would not load and sent an error message

What this boils down to for me is that current voting system products’ Tabulators are not up to correctly doing some seemingly simple tasks correctly, when operated by ordinary election officials. I am sure they work right in testing situations that include vendor staff; but they must also work right in real life with real users. The tasks include:

  • Import an election definition that specifies how many counting devices are being used for each precinct, and how many vote-count datasets are expect from them.
  • Import a bunch of vote-count datasets.
  • Cross-check to make sure that all expected vote-totals are present, and that there are no un-expected vote-counts.
  • Cross-check each vote-count dataset to make sure it is consistent with the election definition.
  • If everything cross-checks correctly, add up the counts to get totals, and generate some reports.

That’s not exactly dirt-simple, but it also sounds to me like something that could be implemented in well-designed software that is easy for election officials to use, and easy for observers to understand. And that understanding is critical, because without it, observers may suspect that the election has been compromised, and some election results are wrong. That is a terrible outcome that any election official would work hard to avoid — but it appears that’s what is unfolding in Saguache. Stay tuned …


PS: Hats off to the Valley Courier‘s Teresa L. Benns for a really truly excellent news article! I have only touched on some of the issues she covered. Her article has some of the best plain-language explanation of complicated election stuff, that I have ever read. Please take a minute to at least scan her work. – ejs

Tabulator Technology Troubles

In my last post, I recounted an incident from Erie County NY, but deferred to today an account of what the technology troubles were, that prevented the routine use of a Tabulator to create county-wide vote totals by combining count data from each of the opscan paper ballot counting devices. The details are worth considering as a counter-example of technology that is not transparent, but should be.

As I understand the incident, it wasn’t the opscan counting systems that malfunctioned, but rather the portion of the voting system that tabulates the county-wide vote totals. As I described in an earlier post, the ES&S system has no tabulator per se, but rather some aggregation software that is part of the larger body of Election Management System (EMS) software that runs on an ordinary Windows PC. Each opscan devices writes data to a USB stick, and election officials aggregate the data by feeding each stick into the EMS. The EMS is supposed to store all the data on the stick, and add up all the opscan machines’ vote counts into a vote total for each contest.

Last week, though, when Erie County officials tried to do so, the EMS rejected the data sticks. Election officials had no way to use the sticks to corroborate the vote totals that they had made by visually examining the election-night paper-tapes from the 130 opscan devices. Sensible questions: Did the devices’ software err in writing the data to the sticks? If so, might the tapes be incorrect as well? Is the data still there? It turns out that the case was a bug in EMS software, not the devices, and in fact the data on the sticks was just fine. With a workaround on the EMS, the data was extracted from the sticks and used as planned. Further, the workaround did not require a bug fix to the software, which would have been illegal. Instead, some careful hand-crafting of EMS data enabled the software to stop choking on the data from the sticks.

Now, I am not feeling 100% great about the need for such hand-crafting, or indeed about the correctness of the totals produced by a voting system operating outside of its tested ordinary usage. But some canny readers are probably wondering about a simpler question. If the data was on the sticks, why not simply copy the files off the stick using a typical PC, and examine the contents of the files directly? With 40-odd contests countywide and a 100-odd sticks and paper tapes, it’s not that much work to just look at the them to whether the numbers on each stick match those on the tapes. Answer: the voting system software is set up to prevent direct examination, that’s why! The vote data can only be seen via the software in the EMS. And when that software glitches, you have to wonder about what you’re seeing.

This is at least one area where better software design can lead to higher confidence system: write-once media for storing each counting device’s tallies; use of public standard data formats so that anyone examine the data; use of human-usable formats so that anyone can understand the data; use of a separate, single-purpose tabulator device that operates autonomously from the rest of the voting system; publication of the tally data and the tabulator’s output data, so that anyone can check the correct results either manually or with their choice of software. At least that’s the TrustTheVote approach that we’re working out now.


Tabulator Troubles in New York

Behind the election news in Buffalo, NY, there is a cautionary tale about voting system complexity and confidence. The story is about a very close race for the state Senate’s 60th district. One news article includes a reference to “software problems with the new electronic voting machines in Erie County.”

The fundamental issue here is whether to trust the vote count numbers, in a case where the race is very close and where the voting system malfunctioned at least once, because of a software bug later identified by the vendor. If one part of the system malfunctioned, shouldn’t we also be concerned that another part may also have malfunctioned? An error on even one of the over a 100 paper-ballot-counting devices could easily swamp the very small margin between the top two candidates.

Those are good questions, and as frequent readers will already know, the typical answer is “audit”, that is, hand-counting a portion of the paper ballots to ensure that the hand-counts match the machine counts, using statistical science to guide how many ballots to hand count to achieve confidence that the overall election results are valid. That’s what the state of Connecticut — another recent adopter of paper ballots over lever machines — is doing with a manual count of ballots from 73 of the 734 precincts statewide.

But that’s not happening in Buffalo (as far as I can tell), where instead there is wrangling over doing a full re-count, with confusion over the voting system malfunction muddying the waters. And that’s a shame, because election technology properly used (including routine audits) should not cause this kind of legal activity over the validity of an election result — in this case an important one that could influence party control in the state Senate, with re-districting on the horizon.

But some of the finger-point goes to the technology too. What actually malfunctioned? Could the glitch have effect the election result? What can we learn from the incident? Questions for next time …


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.