[EM] CORRECTING Black box voting repost re how HAVA imploded

[Brian Olson]

Ok, I was being too short and pedantic. I would actually be just fine with 
a software solution that was "good enough for banks" rather than "good 
enough for airplanes". I believe a lot of financial software runs on Java 
with little more than Sun's assurance that the Java compiler and JVM are 
legit. A lot of big money and important things are probably running on 
some vague notion of 'good enough' and informal assessment of trust.

My current favorite solution for practical elections is hand counted paper 
ballots with computer data entry (on common desktop PCs, not special 
machines). It would take a person 30-60 seconds to enter a ballot into the 
computer. Once all the data is in the count would be much faster overall. 
I've tried hand counting ballots into a Condorcet matrix and it isn't 
fast. I think at best I got down to around 30 seconds per ballot for a 
single 8 candidate race, and starting out was hard wrapping my brain 
around all the marks which needed to be made and it was more like 4 
minutes per ballot for the first few. Hiring temps at $10/hr to hand count 
condorcet ballots would be error prone and slow. It's much easier to read 
the ballot values straight into the computer and let it sort out the 
counting. IRV especially needs a computer count, otherwise w need to 
physically move potentially huge piles of ballots.

Brian Olson
http://bolson.org/

On Thu, 1 Feb 2007, Ka-Ping Yee wrote:

> On Thu, 1 Feb 2007, Brian Olson wrote:
>> But the problem is you didn't count the million lines of python
>> interpreter or the millions of lines of X11 or Linux you might run it on.
>>
>> If you're going to claim verification, you need verified building blocks
>> or build the whole thing yourself.
>
> Any attempt to verify something has to choose a level of abstraction to
> stop at.  Does security verification require verifying your C compiler?
> How about the CPU microcode, the CPU transistor layout, or the RAM?
> (Diebold's code uses MFC and runs on Windows CE -- also a lot of code.)
>
> You are correct that verifying the Python prototype alone does not amount
> to verifying everything.  The way i decided to draw the line there is
> that Python is widely deployed, mature open source software -- we have
> massive ongoing evidence that the language implementation doesn't contain
> serious bugs.  We don't have any such evidence about software written
> specifically for voting, so that's where verification is most needed.
>
> By the way, i'm not much in disagreement with you about paper ballots.
> There's no question that paper is currently a more reliable and
> accountable recording medium for votes than software.  However:
> (a) we're stuck with machines alas, so they'd better not suck; and
> (b) there are some pretty compelling arguments for richness in the UI,
> both in terms of better enfranchisement of voters with all types of
> disabilities or impairments, and it's an established fact that
> computers (when they actually work) can help voters detect and correct
> mistakes.
>
>
> -- ?!ng
>