The memo to council about the upcoming municipal election says (6B, Page 3) that the manual tally audit after the recent recount caught a "human error, not machine error" in the recount. That is not true. I was there and it was clearly a "system error" rooted in a faulty recommendation by the machine and a terrible user interface. Blaming it on the resolution team is more than rude. And the estimate for how long it took is also very misleading. Below are the details. A manual tally, or at least a proper manual tally audit (as required, e.g. by California), must be part of any election in order for it to inspire confidence. But the current Hart system cannot support the independent selection of a random sample for a proper audit - it must be told ahead of time which votes are going to be audited and they have to be counted using several different "mobile ballot boxes". Resolving errors when they occur is terribly time consuming. To date, despite a request from the Canvass Board which was in charge of the recount, the Boulder County elections division has not provided access to the information necessary to improve this situation. I urge council to either require a fully manual tally, as e.g. used in Switzerland, or to at least require that Hart and the county provide a system that can be independently audited. I would like to be appointed to be involved in doing a proper audit, based on having extensive experience with the Logic and Accuracy Test for this system, the manual tally, the selection process and input from concerned citizens, and my experience as a professional in Computer Security (including 22 years with Bell Labs). Thank you, Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60 303-494-6493 On December 7th in Boulder there was a manual tally (hand count) of a small sample of ballots to audit the results of the Hart InterCivic BallotNow vote counting system during the recount of the St. Vrain School District Ballot Issue 3a race. The sample was apparently chosen the previous Friday afternoon by grabbing some of the few batches that had not yet been scanned. The count was off by one. The manual tally for batch "C126" was 47 "yes", 49 "no", and 1 "undervote". But the BallotNow count was 47 "yes", 48 "no", and 2 "undervote". For the other two batches, the manual tally matched the BallotNow tally. A total of 287 ballots were tallied manually. Subsequent investigation identified a vote in precinct 4171107002 on ballot 656372 which was clearly marked on the ballot as a "No" vote (the box was completely filled in), but was recorded via BallotNow as an undervote (as if the voter had voted neither yes nor no). The BallotNow audit log noted an "Auto Resolve UnderVote" for the St. Vrain race on that ballot, along with "Autoresolve damaged contest". The barcodes on the 4 pages of this particular ballot were significantly different in length. E.g. the barcode of the serial number ranged from 41 mm to 43.5 mm long. BallotNow uses the bar codes to help it locate where the boxes are on the ballot, and it identified this ballot as "damaged". The ballot was rescanned as a new batch of 1, and brought up on the screen for resolution. The St Vrain race was highlighted as "damaged". When the race was popped up in its own window (a narrow window, as usual), the title of the window read "Unresolved dama", i.e. the whole title wasn't visible. Opening the window up wider revealed the whole title which said "Unresolved damaged undervoted contest". So before manual intervention, BallotNow had identified the race as needing resolution, but incorrectly interpreted it by default as an undervote. Next came the human resolution process. Interpreting the audit log is difficult. There are two theories for how the race could have been resolved as an undervote. One theory is that the ballot was simply not shown to the resolution judges. During the recount, the teams were only resolving the St Vrain race, and the normal user interface cues were less helpful than normal in helping the team identify all races needing resolution. Next, a subsequent "autoresolve" process preserved the mistaken, automatic "undervote" interpretation. Another theory is that since the user interface is confusing, and the word "undervoted" in the title bar may not have been visible, the resolution team may have seen the clear "No" vote and clicked on "confirm". In this case that would place the text "Confirm User" over both the yes and no boxes, which again is confusing, and a hint that the system is about to confirm both votes as absent, but not all resolution teams fully understood the hints that the system provides. The upcoming City Council election is a rare opportunity to improve the process for future elections in Boulder County and elsewhere. A complete analysis of the audit logs from the original count and the recount should be done. That could be done by writing them out as normal pdf files, using the Unix "pdftotext" command to convert them to text, and processing that text to see how each ballot was resolved for this race. I've already written some software to help with this analysis. The canvass board directed that I be given the pdf audit logs for the Logic and Accuracy Tests so I can improve it, but the county hasn't provided them yet. Your attention to these matters, and your help, would be much appreciated. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
Attachment:
pgp00000.pgp
Description: PGP signature