Re: code validation?

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Wed Feb 23 2005 - 12:50:12 CST

On Feb 23, 2005, at 12:03 PM, Ron Crane wrote:
> Nonetheless states increasingly are choosing to allow widespread
> absentee voting, and, as noted, Oregon conducts all its elections by
> mail. Obviously they don't see vote buying as a significant problem
> relative to the benefits of widespread absentee/mail-in voting.
> Thus...

Well... if we adopted a purely Hegelian "The Real is the Rational"
approach, we could equally note that:

   "States are increasingly choosing unauditable, proprietary DREs.
(Georgia conducts all its...)"

Hopefully the 'increasingly' part isn't true any more. But in general,
I don't think we can make a direct deduction from what states *are*
doing to what they *should be* doing.

> I'm afraid I don't see EEVV's "numerous new vulnerabilities". It's the
> exact same vulnerability as widespread absentee/mail-in voting, no
> more and no less.

An absentee ballot must be verified by the buyer/coercer at the moment
it is sealed in the envelope. A receipt for votes may be verified at
ANY time after it is issued (or at least after its code is posted
publicly).

Just one scenario:

(1) Thug/Crime boss goes around to all the houses in the neighborhood,
and tells each resident that he would "really appreciate" a vote for
him as mayor (what a pretty family they have too). He suggests they
can further discuss their votes later.

(2a) Absentee system: Voter seals ballot in envelope at time (election
minus N). If no assistant thug is watching them, they will perhaps
vote for Ms. Honesty-Integrity instead. In subsequent conversation,
they can *tell* Mr. Crime-Boss they voted for him (need good poker
face, maybe).

(2b) Vote receipt system: Voter votes at polls and takes home magic
code number. No assistant thug is watching. At some (any) subsequent
time, Mr. Crime-Boss visits voter and says he would be very curious to
see voters receipt.

The latter system provides much greater scheduling convenience for vote
coercers (or buyers who want proof too).

> Eek! Such a proliferation of vendors will fragment the open-source
> review community and thereby make it much more likely that there won't
> be enough interested people available to know about and review every
> change.

A vendor need not modify the code necessarily.

It's not really an issue of forking, but of service provision: when
will the CDs and hardware be delivered? Who can elections workers call
in cases of problems?

There's apparently some interest in states about finding a definition
of "Public Software" to write into law... and states want concrete (and
perhaps local) vendors to qualify for service provision. Troy Davis is
one of the people working on this definition (apologies, Troy, for not
getting back to you yet with comments and the language).

One of the things Troy sent me is at:

   http://www.omidyar.net/group/openvoting/news/4/

I think it gives some sense of why this is desirable to states; and how
states think about "vendors."

> And law is often a remarkably weak tool to enforce compliance with
> complex procedures. How would you write a statute requiring a vendor
> to incorporate all significant security fixes? How would the
> enforcement clause read? Could you get a TRO (temporary restraining
> order) forcing the inclusion of a fix? Is a judge going to understand
> what the hell you're talking about, or will she refuse the TRO and let
> the case go to trial behind 2 years' worth of criminal docket?
> Speaking of which, will there be criminal penalties? Will they really
> be enforced?

Law is complicated; we have a number of excellent lawyer on this group
who can attest to that.

But at a certain level, some details are of necessity regulatory rather
than statutory. But this is nothing new, as such: Certification of
elections system is already a complex system (and different between
states)--it may not work to the standards we would like, but that's not
because it's too *simple* to do so.

Ideally, a SoS (or whatever office a particular state delegates this
to) would certify a particular software version by hash. That is: If
its SHA-1 is 0xa3902cf..., it is certified. Otherwise, it is not
certified (and illegal to use in elections).

Now, yeah... laws can still be broken. And judges--who are, as a rule,
quite smart people--still need to weigh facts, and make decisions.
Whether a TRO is an appropriate remedy is very fact driven by a
particular circumstance: I can't categorically say "always/never issue
TROs."

Significant violation of law, as a rule, should indeed be met with
criminal penalties, IMO.

> Many of these violations are felonies under Ohio law, but I haven't
> heard a peep about prosecutions.

Sure. Laws are not always well or uniformly enforced. That's bad; but
I'm still not quite willing to give up the system of law just yet.
What else have we got?!

> Basically you have to trust the vendor to incorporate suggested
> changes.

No. You trust a certifying agency (e.g. the Secretary of State's
Elections Committee). If particular changes are not incorporated, the
result does not have the requisite hash to qualify as legal elections
software.

Again: Yes, committees can do a bad job, accept bribes, be lax, be
ignorant, etc. Vendors can disobey the law, run illegal software,
forge documents, etc. That's the world we live in. Checks and
balances (and procedures) help, but there's no panacea.

_______________________________________________
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to arthur@openvotingconsortium.org
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sun Feb 27 17:17:11 2005

This archive was generated by hypermail 2.1.8 : Sun Feb 27 2005 - 17:17:13 CST