Voting Project Needs Python People

[Harry George]

"Andrew Dalke" <adalke at mindspring.com> writes:

> Harry George:
> > Is the intent to do opensource all the way to commodity chips?  Else a
> > proprietary BIOS could be the weak link.
> 
> In which way?  There resulting code should be runnable on a wide number
> of platforms, so there isn't a single source issue, and the actual vote is
> on voter verifiable paper, so corruption of the BIOS won't be able to
> affect anything other than the number of "something's wrong - this isn't
> what I voted for" complaints.
> 
> Perhaps you were thinking of a pure electronic version?
> 

This is getting a bit off-topic, but is relevant to
Python-as-open-source-scripting-tool.

Yes, paper audit trail is essential.  But I'm pretty sure that
conflicts between paper and electronic will result in court cases,
with significant chunks of ballots in limbo or thrown out on one
pretext or another.  By choosing which precincts are thrown in limbo,
you can impact the overall results.

Here is a possible scenario:

1. Software chooses 1% of votes to change (big enough to have an
   effect, small enough to maybe go unnoticed).

2. Paper is correct.  Visual monitor is correct.  Electronic storage
   is changed.  Voter leaves happy.

3. Results are posted based on electronic storage.

4. Only if enough people suspect trouble do we go to the paper trail.
   At 1%, that may not happen.  Yet a 2% swing is pretty big in many
   settings.




>                     Andrew
>                     dalke at dalkescientific.com
> 
> 

-- 
harry.g.george at boeing.com
6-6M31 Knowledge Management
Phone: (425) 294-8757