BBV: Summary of tech points

[scottxyz]

It can be useful to periodically try to summarize what we see as the major technical aspects of the Black-Box Voting problem:

I guess my general tech points would be:

(1) The overall architecture of the voting system has never really has been debated - how many copies of what go where. The biggest thing missing from the architecture is a voter-verified paper ballot that always gets counted. If the voters want this, the voters should get this.

An all-digital or "no-ballot" system eliminates the possibility of small errors and petty fraud while enabling potentially massive errors and widespread fraud. The minor noisiness and messiness of hand recounts, hanging chads and other physical vote-tallying and -auditing methods is actually much better than the potentially wide-scale undetectable vote-hacking enabled by all-digital ("no-ballot") vote-casting and -tallying methods.

(2) Neither Rubin's report (which found lots of potential security holes in the system) nor the SAIC report (which proposed managerial steps that might or might not plug the holes) addressed the overriding architectural problem in (1) - you can't verify someting if there's nothing physically independent to verify it against.

(3) Certification of software (the so-called "Logic & Accuracy" testing) cannot be performed by merely executing the software, because a finite number of runs does not fully rule out the possibility of hidden partisan code that could be triggered on a later run. Software execution without code inspection cannot provide certification.

No argument can be made, nor does any law provide, that the algorithms used to total our votes (or our taxes, for that matter) should be treated as state or trade secrets. The design and validation of computer algorithms used to total votes (or our taxes) are and have always been a routine matter of public record.

My specific tech points (involving just Diebold's and the SAIC report) would be:

(1) Professional database programmers do not use Access or any other database language without switching on the built-in (declarative) referential integrity. Duped and dropped records often happen silently when referential integrity has not been switched on. Diebold developed the database systems for a lot of ATMs, so the fact that they didn't switch on Access's built-in referential integrity in their voting software indicates most likely not incompetence but outright malfeasance.

(2) Microsoft Access passwords are hackable. So how are we supposed to take the SAIC report seriously when it just recommends changing the passwords printed in the manuals? For that matter, how are we supposed to take a vendor seriously that prints the passwords in the manual in the first place anyways?

(3) Severe vulnerabilities were identified in the SAIC report, yet Diebold has attempted to spin identified vulnerabilities and vague "mitigation strategies" into a clean bill of health. The software is demonstrably unusable now; the vendor's qualifications and credibility have been called into question; the improvements the SAIC recommends do not go far enough to fix the existing vulnerabilities and they gloss over the biggest issue of all - the need for voters to have a way of physically verifying that their vote has indeed been indelibly cast before they leave the polling area.

(4) The very language of the SAIC report, focusing on "mitigation strategies" and "reduction of risks" is not applicable to programming tasks, where issues of technology and architecture need to be solved before any managerial steps can have any effect. The reassuring-sounding but ultimately vague and empty recommendations of the SAIC report mask the fact that the essentially managerial changes it recommends will not necessarily do anything to address the stubborn technological and architectural vulnerabilities identified by the Rubin report, and, given the possibly compromising associations of the SAIC itself, have led many to suspect the report may be nothing more than a whitewash.

My general pro-active ("do it right") tech points would be:

(1) The voting-casting and -tallying software and hardware design needs to be:

(a) publicly debated - to produce a formal needs and requirements document (in English) which complies with the letter and spirit of the law;

(b) publicly specified - to produce a formal specification (in a declarative programming language - saying WHAT the software does to satisfy (a)); and then

(c) publicly implemented - to produce an implementation (in a procedural programming language - saying HOW the software implements (b))

Note: this goes a LOT further than the normal open-source debate, which usually only calls for phase (c) in isolation, and fails to note that it is meaningless without (b) and (a).

Certification must consist of:

(2)(a) publicly verifying (by inspection and discussion) that the high-level specification (in a declarative programming language) satisfies the needs and requirements document (in English); and then

(2)(b) publicly verifying (by automated program-derivation and -validation tools) that the low-level implementation (in a procedural programming language) satisfies the high-level specification.

- Scott

If people want to edit this it would be great. I think we need a coherent set of "technology" talking points about (a) what's bad about the current system and (b) what a good system would look like.