The DC voting mess continues

Way back before the financial market collapsed (say, last month), the District of Columbia held a primary election. For reasons still unexplained, there were some very strange preliminary results - huge numbers of overvotes in one part of the city. The vendor, Sequoia Election Systems, has alternately blamed the problem on static electricity, errors by the Board of Elections, and reporting the results too quickly - but at all times have denied that it was due to a problem in their hardware or software. The DC Council established an ad hoc committee to examine what happened and try to get to the bottom of the issue.

There's been lots of coverage of the problem in The Washington Post: here (Sep 11), here (Sep 12), here (Sep 12 again), here (Sep 22), here (Sep 25), here (Sep 26), here (Sep 30), here (Oct 2 editorial), and here (Oct 4).

The last of the above articles is coverage of a public hearing held by the special committee, where they heard from interested citizens, the vendor, and several voting system experts. I was honored to be one of the experts invited to testify, and my testimony can be found about 54 minutes into the video.

I made four basic points:

1. We shouldn’t blindly take the vendor’s word for what happened, because the vendor's explanations don't make sense. Sequoia hasn't been able to reproduce the problems that correspond to any of their explanations, be they static electricity or mistakes by the election officials.

2. We shouldn’t blindly take the vendor’s word for what happened – the explanations may be wrong. We’ve seen at least one case where a vendor example where a vendor’s initial claims were proven wrong. After the spring 2008 primary in Ohio, the vendor, Premier Election Systems, blamed election officials for incorrect results, where one precinct’s votes were lost. Later, the vendor changed their explanation, and blamed the anti-virus vendor for the error. Eventually, the vendor admitted that it was a bug in their software. Right now Sequoia is saying it’s not a software error – but that might change as the DC Council and Sequoia learn more.

3. We shouldn’t blindly take the vendor’s word for what happened – prior studies have indicated that the problem seen in DC was a possible problem. In particular, the California Top To Bottom Review, sponsored by the California Secretary of State, noted that Sequoia software “seems not to check whether vote counts stored on Memory Packs received from the MPR are consistent with the number of voters, so an erroneous Memory Pack will corrupt the final tally instead of being detected”. The California report then goes on to note that the Sequoia software does not perform any sanity checks to ensure that each Memory Pack only contains data from a single precinct – so a corrupted Memory Pack that is somehow corrupted can not only affect that precinct, but can cause the erroneous results to propagate into other precincts.

4. We shouldn’t blindly take the vendor’s word for what happened – we’ve seen similar failures before with Sequoia voting systems. In Alameda County California, the February 2008 primary election had a very similar failure, where a corrupted memory card registered an absurd number of votes in one precinct, and reprocessing the memory card caused it to give correct results.

I then recommended that the Council obtain an independent expert forensic study to figure out what went wrong, along the lines of the investigations of the 2006 Florida CD-13 election or the 2008 New Jersey primary.

I don't know what's going to happen next, but I hope the Council moves forward quickly, so there can be some preliminary answers before the election next month!