Re: Microsoft-backed Consortium, AeA, Opposing Open Voting Bill, AB 852

From: Alan Dechert <dechert_at_gmail_dot_com>
Date: Thu Apr 26 2007 - 12:52:59 CDT

Hamilton wrote,
> Suppose you undertake the most thorough possible review of a
> printerless DRE's code, and every flaw you discover is corrected.
> Would you then trust it to count the votes correctly? If so, then
> logically you should oppose the calls for OVC-style ballot printers.
No. This is not logically true. The main reason is that the transparency
imperative is multi-layered. We demand a hand-countable paper ballot
because that is what is easily understood.

Also, from a practical standpoint, your theoretically perfect DRE can't
exist -- at least for long. This is because electronic components tend to
remain current only for a short period. This means that review is
constantly needed. A "perfect" system could become un-perfect with a new
release of video sub-system.

Another factor is auditability. The vote count must always be able to stand
up to audit requirements. This is much more difficult to do for a DRE.
There are lots of ways we could devise for auditing DREs, but it is
difficult to do this without running into great expense, and/or compromising
voter privacy.

> If you (like me) believe that even after an exhaustive code review
> ballot printers would still be necessary, what would have been gained
> by the code review? Better code, presumably, but --strictly from the
> point of view of *knowing* that it counts votes correctly-- still not
> good enough.
Again, this "what's to gain" argument is irrelevant. What's to gain by
making legal code easily available to everyone? It doesn't mean the legal
code will be made perfect. Can you imagine what our legal code would look
like if only authorized people and select corporations could see it and
control it? I think there is a better chance that it will be improved, but
that's not the main point. It is, as Lillie pointed out, a requirement of
self governance.

> Note that I'm in no way opposing code reviews. They're great for
> improving code's quality. It's just that they can never deliver the
> assurance that all the bugs have been found, and without such an
> assurance the code can't be trusted.
Irrelevant. No one is making the claim that they ensure all the bugs will
be found and fixed.

> There's an ethical issue here. If we justify our demands for public
> disclosure by claiming that this will enable us to prevent
> vote-counting fraud, we're being just a tad dishonest.
Irrelevant. Security of the voting system requires a multi-layered
strategy. Open/disclosed source is only one key component of this strategy.

> There's also a practical issue. If public disclosure becomes law, how
> will we handle the argument, "OK, now you can inspect the code, stop
> bothering us about ballot printers. ... Oh? Ballot printers are still
> needed? Then what was all that fuss about public disclosure?"
We handle this as we handle the myriad of other specious complaints about
our project -- we've heard all these and more almost daily for some years
now. We walk through the explanations over and over.

About two years ago, I had a very interesting discussion with an executive
of one of the major vendors where this came up. It was almost as if he
wanted to cut a deal. [paraphrasing] "Hey, if we go for open source maybe
we can do away with this stupid paper trail requirement."

Transparency requirements and auditability requirements necessitate a paper
ballot. I don't rule out the possibility that a paperless system could be
sufficiently trustable in the future. Clearly, we don't know how to do this
right now.

The hardware would need to be of a public design before we could even begin
to talk about such a system, imo. I note that in Irwin Mann's 1993 paper on
"Open Voting Systems" he says, "no proprietary parts." But he still
specifies paper ballots.

Alan D.

OVC-discuss mailing list
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Mon Apr 30 23:17:14 2007

This archive was generated by hypermail 2.1.8 : Mon Apr 30 2007 - 23:17:16 CDT