Since Diebold has turned software over in CA, why are they resistant to the idea in NC?
That's easy. The law says (pretty clearly) that vendors have to turn over "all" source code and the names of all developers who worked on any of that source code for everything relevant to the voting system. As written, that appears to include everything from the operating system up... including everything from Windows, to the 3rd-party printer drivers you might use if you ever print any reports, to third-party libraries that might be used by the voting system application. If Acrobat's free PDF viewer is used to view generated reports, the source code for
that has to be provided. You get the idea. And the penalties for non-compliance include both civil (monetary) and criminal charges.
Diebold went to court to seek clarification on the law (which is new and untested). They claimed that they can't comply with it, because they can't provide all the source code to Windows, or Acrobat, or third-party printer drivers, or any number of other things that are technically encompassed by a strict interpretation of the law as written. It's been misreported that they refused to hand over their
own source code, but that's mostly because Diebold sucks at doing PR. Diebold (and every other vendor) hands over their source code all the time, to pretty much any customer that asks for it, and even to some
prospective customers. The NC case was problematic because of the provision for criminal penalties... they didn't want to deal with the negative fallout of "Diebold executives indicted in NC" headlines when some activist managed to sue in that state because Diebold didn't comply with the law (because they can't provide everything the law requires). No
other vendor can actually comply either, but they mostly chose to ignore the issue and use the (probably correct) interpretation that the people who drafted the legislation didn't actually intend for vendors to supply source code for all those third-party components. But it's easier for other companies to
take that risk, because a) they've been under less fire than Diebold, and b) they're privately held, and as such don't have the same responsibilities and obligations that Diebold does towards protecting their shareholders.
Anyway, it's a pretty stupid story, especially when Diebold opted to just bite the bullet and proceed in NC. A smart person would ask "if you were just going to go ahead regardless, why even
bother with the lawsuit in the first place? All it buys you is a bunch of unnecessary negative publicity and the inevitable mis-reporting of 'Diebold refuses to turn over its software'." Of course the
answer is "because Diebold's PR department is incompetent."
I read the report from the June test. I thought it did lose votes, but perhaps I got it wrong. I don't mind an unprecedented volume test, either.
No, no votes were lost in the test. They had a handful of paper jams and a handful of software crashes due to a problem that made it through their internal testing, but neither problem caused any loss of votes.
The volume test is fine. My only issue with it is the barrier to entry that it poses for smaller vendors. AccuPoll, for example, will never pass such a test in California because they can't afford to build 100 machines, ship them to California, pay 100 temp workers to come in for a day, etc. with no guarantee that the state will certify the system even if you pass. Maybe if the state were to absorb the costs associated with any volume testing it'd be less onerous, but right now they make the vendor pay.
The "failure rate" interpretation that states it as 20% would seem warranted considering how adversely an afflicted precinct would be by the loss of 1 out of 5 machines, depending upon when it had to removed from service.
Like I said, it's all a matter of interpretation. Twenty machines had a problem so you can interpret that as a 20% failure rate, which is clearly an unacceptable number. On the other hand you're possibly misinterpreting how adversely affected a precinct would actually be by the problems that were observed in the testing: in none of the cases would a machine have to be taken out of service. In the case of the paper jams, a pollworker had to clear the jam. In the case of the software problem, rebooting the machine was sufficient to "resolve" the issue in all cases. Like I said, it's all a matter of interpretation. Either way, Diebold made hardware changes to address the problem of printer jams and they fixed the software bug that was found; both fixes were verified by a successful repeat of the volume test. And despite the claims of "20% failure rate", no significant problems of either sort were reported when the same system was used in Utah and Ohio in real elections (a real-world failure rate of 20% would hit the news almost instantly). So... you can take it all for whatever it's all worth. Clearly there were two problems detected via testing, which were subsequently fixed by Diebold. And that's a good thing. But clearly the
impact of those two issues was greatly overstated, since they didn't actually cause any noticeable problems when the units were run in the real world. *shrug*
That Diebold has done work on the machine to improve it's performance begs recertification of the software by an ITA, though. No?
Yes. All modifications to the voting system's hardware or software require recertification by an ITA. Diebold acquired ITA certification for the changes (in version 4.6.4 of their DRE firmware -- version 4.6.3 was the version that was used in the
first volume test.) The only issue left in California is
state certification, i.e. blessing by the secretary of state.
I share your sense of Bev's CA roll, and wonder if Leon County is a similiar event. I didn't quite follow the OpScan angle, though. Was to test units already in service?
I don't actually have a "sense" of Bev's CA role, I have concrete information directly from sources on the ground. The secretary of state decided to eliminate Bev Harris and BBV from the California test after her silly grandstanding, self-promotion, and ridiculous list of demands. The state's been dealing directly with Mr. Hursti on the issue instead. Bev is pretending that she's still in the loop, she's posting threatening letters from her lawyers (real shocker there), and she's still attempting to "negotiate" conditions for the test. But nobody's responded to her for weeks, because nobody's interested in her or her antics.
Here's an interesting question for anyone familiar with Bev Harris and her role in the California test. California invited BBV to come and test the equipment and software being considered for certification in California. Bev Harris refused, and demanded that she be allowed to test the
older software instead, i.e. the same software they tried in Leon County. Her reasoning was that she was worried about the possibility that Diebold might have "gamed the system" and made it impossible for BBV to perpetrate their attack.
Question:
isn't that the actual goal? That is, isn't the goal to get the system modified so that they can't hack it? Bev Harris should
want Diebold to have "gamed the system" so that her (and anyone else's) attack will fail.
Bev Harris isn't interested in improvements to system security, she's actually
afraid there might be some because that would lower her chances of scamming some more money in another fraudulent false claims suit.
Of course, everyone is free to draw their own conclusions about Bev Harris and her motives but I think that all but the most brainwashed of her crew will see through her latest transparent scheme. ;)
Neil