Re: code validation?

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Tue Feb 22 2005 - 22:52:46 CST

> I more or less buy what you're saying so far. But we need to document
> the procedures thoroughly.

Yeah.

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

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.

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

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

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

At the least though, open source makes it easier to quantify and
perform forensic analysis of bugs experienced in an actual election.
Obviously, it's infinitely better not to have them in the first place;
but the best you can do is the best you can do (and a paper ballot that
is both voter verifiable and countable by humans during a recount
answers a large slice of all the possible software bugs).

_______________________________________________
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