[TriLUG] OT: OpenVote

[Rick DeNatale]

On 1/4/06, Cristobal Palmer <cristobalpalmer at gmail.com> wrote:

>
> The weak point of the system you describe is the tabulator, which,
> incidentally, is exactly what was flawed in the Diebold system. It was
> an optical scan system.

Which is not a DRE, it's of the same ilk as punch-card ballots, the 
exploit relies on the ballots not being recounted independently of the
process first used to count them.  Most electoral laws make manual
recounts of electronically counted elections rare. The manual recounts
in Florida in 2000 came about because of a lack of repeatability
between multiple re-reads of the punched cards.

The weak point of DREs is that the capture of the voters intent
becomes ephemeral immediately.  Even paper "audit trails" are one step
removed from the vote.

> I think there's no question but that an open
> source implementation there is not only feasable but very desirable.

Sure it's feasible technically, but it's only one small facet of
verifying the trustworthiness of the overall system.

> "Given enough eyeballs, all bugs are shallow." --ES. Raymond

Actually, the full quote, in context is:

    "Given a large enough beta-tester and co-developer base, almost
     every problem will be characterized quickly and the fix obvious to
      someone.

     Or, less formally, ``Given enough eyeballs, all bugs are shallow.''
     I dub this: ``Linus's Law''."

     "My original formulation was that every problem ``will be transparent to
      somebody''. Linus demurred that the person who understands and fixes
      the problem is not necessarily or even usually the person who first
      characterizes it. ``Somebody finds the problem,'' he says, ``and
      somebody else understands it. And I'll go on record as saying that
      finding it is the bigger challenge.''

So, it's not just eyes on the source code that is important in finding
and fixing cases where the software doesn't seem to do what it should
be doing. Another important aspect is people TESTING the code.

My experience, gained through 30+ years as a professional software
developer, is that testing is FAR more important than code inspection
as a way of flushing out software problems.

> I think we can restate that here, since what's important is that we
> get eyeballs of all political stripes, leanings, persuasions, etc.
> You're right that _most_ people aren't going to know what to look for
> in the source code, but that's hardly necessary if what you're talking
> about is the software that runs the tabulator.

I would think that this is exactly where it's necessary, and insufficient.

Back in the 1970s there was a lot of faith in formula like "structured
programming" and "code inspection" as as way to ensure that software
worked correctly. IT DIDN"T WORK.  Nothing replaces testing, and
testing can be done against black boxes.  Access to the source code
only really comes into it's own when the bug has been detected and the
goal is to eradicate it.

> Also, there has to be a
> way to provide assurance of the version of the software used in the
> tabulator. How are you going to trust _any_ kind of automated
> tabulator if you don't know what it's running?

It's not just the version of the software, but the versions of and
trust in all of the tools in the chain from compilation through
execution.  One of the problem with voting software is that it might
not be wise to  trust the developers of the products which capture and
count the vote.  This is slightly different from the problem of
protecting from attacks from the outside.  We need to think about all
of the ways in which a determined political operative working in one
of the vendors of voting equipment might provide for obfuscated back
doors.

> Besides, Security through Obscurity is a _joke_, and definitely not
> one we should be telling around election day. Instead we should take
> the spectacular failures on the part of Diebold and its underlying
> proprietary core as a challenge to come up with an alternative.

One thing which should give anyone who is thinking seriously about
protecting the validity of elections pause, is what kind of failures
Diebold's systems really were.

Were they failures because the systems were trying to protect the
integrity of the electoral process and failed, or were they failures
because the systems were trying to hide a corruption of the electoral
process but provided evidence of that corruption.

I'm not sure which one it was. This dilemma SHOULD be a bi-partisan concern.

> Why
> couldn't we, an open source community, come up with a viable design?
> An open-source 2006 election wouldn't happen, but 2007 would be
> doable, and since it's the counties that do the buying, it wouldn't
> have to be everywhere. If we got a system working and demonstrably
> secure, other counties would likely switch down the road.

I'm not saying that this is a bad idea. However I think that it's MUCH
harder, both technologically and politically than it appears on the
surface.

--
Rick DeNatale

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/