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.

[Pobeka]

1. Conflicts of interest

scottxyz, I don't have time to flesh this out, have to run to a school function. But it occurred to me today, that we tend to trust complex computer programs from people we don't know, because we can more or less assume their interest is in line with ours. They have no motive for making the software fail, or be biased, because we'll notice, and will not buy their software anymore.

When it comes to a single source provider for voting software, the conflicts of interest can be HUGE. We can quite literally be talking about the ability to control the election outcomes, and gain enormous power and wealth by rigging that process. I think this is a core issue that many people don't understand.

See what I'm getting at?

gotta run...

[gristy]

3. I agree

No amount of certification (or even proper design and design methodologies, as you wisely advocate) can assure the average voter that their vote is going to be accurately recorded. Only a simple process such as one based on paper ballots can assure the electorate that the vote-counting process is accurate and correct. This system includes rules for signing in and verifying voters, handling ballots before, during and after the election, counting votes, counting total ballots and comparing to # of voters, etc.

You have argued very well the methods of proper software design. But with a good paper-based system, you don't need to verify ANY software.

[gristy]

2. here's two comments

instead of 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.

try this: the fact that they didn't switch on Access's built-in referential integrity in their voting software indicates incompetence, malfeasance, or both.

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

I'd very, very much like to see the advocation of the voter-verified paper ballot (as the ballot of record in any recount) in this section. You mention it in the first couple paragraphs, but not after that.

[scottxyz]

4. Good point

If I could edit the message now - I would.

I wish DU had a "wiki" so we could refine some of our statements.