Problem (was: Re: need help with tool requirement)

[Travis Roy]

I always wondered about this sudden desire to audit the voting system. 
Not that it shouldn't be done, but why hasn't it been done in the past. 
Hand counting ballots is rather rare now unless the election is very 
close. Most ballots are counted electronically. In Goffstown and 
Manchester they use the "complete the arrow" method where you just draw 
a line to complete an arrow and then you slide the ballot into an 
electronic counter thing and it counts the vote and sucks it in. If it 
detects an error then it gets punched in by the attendant at a later time.

Who's to say these are not rigged in any way? Are there any audit's done 
on these machines to see if they are tampered with or not? Some people 
might say that they are very simple and don't need to be, but that's 
just the thought of the people that might mess with it.. "They'll never 
suspect, it's to simple for them to think it could be rigged"

I like the idea of electronic voting, and I think it should be checked 
over and made sure that it's safe, secure, anonymous, and tamper proof 
(well, as much as possible) but I also think that current systems are 
also able to be "fixed".

I also don't think that any company that is writing software for these 
electronic voting machines is going to try to fix the elections.. The 
risk is far to great for the companies and the people running the 
companies. That's not to say an outside party won't try.

bmcculley at rcn.com wrote:
> Here's the real problem description.
> 
> Electronic voting machines are feared to be vulnerable to
> hidden malicious code ("Easter eggs") that could subvert voter
> intentions and deliver votes to the wrong candidates.  One
> proposed solution is to require paper ballots be produced by
> electronic voting machines, but this creates other problems. 
> There is also a practical constraint that retrofitting
> existing systems for paper output will not be feasible in the
> timeframe required for the upcoming election, for a variety of
> reasons (simple installed base logistics among them).  Thus
> there is a strong desire and motivation to be able to validate
> the software for systems that are already in the field (it is
> an acceptable constraint to require updating deployed systems
> to a new validated software version).
> 
> It seems that the ideal solution would allow retrospective as
> well as prospective validation (i.e. validate copies of
> software obtained from deployed systems as well as validating
> pre-release software).  For one thing this could be a strong
> anti-fraud deterrent.  This is not an absolute requirement
> however.
> 
> As an alternative, assume that source code is available for
> review and compilation.  Since the code is proprietary it will
>  need to be handled according to NDAs, which seems not a
> serious restriction.  
> 
> What approach would provide sufficient assurance that the code
> does not contain any "Easter eggs" or trap doors to allow
> future egg-laying?
> 
> THANKS!
> 
> -lbm
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss