Re: code validation?

From: Ron Crane <voting_at_lastland_dot_net>
Date: Wed Feb 23 2005 - 11:03:30 CST

>> However, at the very end, you say, "but the whole "vote receipt"
>> thing is a very bad idea. It doesn't add to, but detract from,
>> security." Apparently this refers to the end-to-end voter
>> verification ("EEVV") idea... I do recognize that EEVV open up
>> opportunities for vote buying, but it's no worse in that respect than
>> existing absentee ballot systems
>
> I don't really like the widespread use of absentee balloting in cases
> where a voter is not genuinely unable to make it to polling places.
> Especially mandatory absentee, where voters don't even have the
> decision to fully protect their anonymity.

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

> But even so, the vote-receipt thing DOES indeed add numerous new
> vulnerabilities related to vote buying, and especially related to vote
> coercion. It's a direction we don't want to go in.

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. And EEVV accepts that vulnerability for the very good
reason of increasing the voting system's security and transparency. Why
shouldn't any citizen be able to tabulate the election? It's the
ultimate in "open source" voting.

EEVV ought to be provided as a option for states that wish to use it.

>> There's a problem here. There must be a known set of vendors who have
>> earned trust via the review process you described. Let's posit that
>> OVC is the only such vendor initially
>
> Nah... OVC is more like a certifying standards body. Voting is very
> decentralized in the USA, and it's almost certain to be a lot of
> different vendors in different locales. Think of us like OASIS, IEEE,
> or W3C: we might provide a reference implementation--and vendors might
> even use our code (probably should do so to insure code quality and
> auditing)--but vendors can compete for a particular service contract.
>
> But certainly qualifying as a vendor of Public Software should be
> subject to laws (some OVC'ers are working on this in various states).

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. 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?

The question of legal enforceability is far from a theoretical issue.
During Ohio's presidential recount, local boards of elections violated
the recount statutes in numerous important ways, yet, because of
timing, the lack of appropriate enforcement provisions, and/or the lack
of certain public officials' will to enforce the law, nothing was done
about it. The result was that "randomly" (as in "randomly choose which
precinct to recount") was defined as "whichever one we choose",
"recount" was defined as "run through the tabulator as many times as is
necessary to get the result to match the election day total", "observe"
(as in "citizen observers") was defined as "be locked out of the
building where the tabulation occurred", etc. Many of these violations
are felonies under Ohio law, but I haven't heard a peep about
prosecutions.

Basically you have to trust the vendor to incorporate suggested
changes. And while I might trust OVC to do so or at least be able to
raise a stink if it doesn't I don't trust, can't check on, and can't
raise a stink about tens of vendors playing around with the software.

>> We need to determine the appropriate lead time.
>
> Yeah... or really it's lawmakers that do.
>
> But OVC perhaps should indeed have a position on
> procedural/administrative questions of this sort. This is one of few
> things about which I don't particularly have any fixed opinion. If
> other OVC'ers want to chime in with their feelings about timeframe
> issues, I'd be interested to read it.

The timeframe issues are integral to the security of the entire
platform. If we don't nail them down, the platform's security suffers,
perhaps greatly, thus compromising the core purpose of OVC's existence.

>
>> This is interesting. What if a show-stopper problem is discovered
>> close to (or dreadfully on) election day? I'd hasten to add that
>> this sort of thing has been far from rare in voting system history.
>
> That's bad... and possible. But finding bugs in software isn't really
> specific to OVC's model. Software has bugs, period. Open source has
> *fewer* bugs though.

So what do we do about it? We can't just punt. Elections officials are
on the line saying that the system doesn't work.

-Ron

_______________________________________________
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