Possible use of Python for a voting machine demo project -- your feedback requested

[Ian Bicking]

On Sun, 2003-07-20 at 17:35, Andrew Dalke wrote:
> Heh.  I read "CLEAR CHOICES" as a command "the choices are clear".

I made that same mistake (and I thought it was odd for the UI to assert
its clarity :).

> > 8) The printout is intended to come from a personal laser printer located
> in
> > the voting booth.  For the demo, we'll probably use the HP Laserjet 5L.
> 
> I approve of the Mercuri system (I think that's what it's called when a
> paper ballot is generated from an electronic ballot - the all-electronic one
> I use now is scary).  I was just thinking though.  Suppose I wanted to rig
> the elections by paying for votes.  If I know the format of the ballot, I
> could generate them myself on specially marked paper then give that
> to the people who I've payed for the vote, who go through the process
> of voting but use the paper I gave them instead of the printout..  Later, I
> or my cronies get access to the ballots (eg, "I'm a reporter and I want to
> verify the votes") and can see if my special ballots are included, and
> reward/punish as appropriate.

You could make sure that ballots were not brought in by signing the
ballot with some key that is unknown in advance, potentially a key that
is generated by each machine when it is started up (then somehow
recorded so the key can be verified -- written to hard disk and printed
out to be collected at the end of the voting period?).  That way you'd
have to corrupt the actual election officials, and once you've done that
it's all pretty hopeless.

> > The
> > selections will be bar coded in a strip on the left edge.  Probably,
> > write-in candidate names will be in a separate bar code.  The printout
> will
> > list the voter's selections in text that can be easily read by humans and
> > scanners.
> 
> The phrase "bar code" scares me in that the bar code and the human
> readable text may differ.  Why not just have everything in text?

It should be quite easy to audit bar codes.  The advantage is that they
are more easily machine read than text -- an on-site reader could be
both simple, cheap, and reliable for a bar code, but I suspect OCR will
not be as reliable.  In a centralized, more controlled location OCR will
probably be fine.  The case of actual fraud, a mere sampling of votes
will probably expose the fraud (since the text is known to be accurate
since the voter will confirm the text).

I don't think filled-in dots are particularly better than bar codes. 
It's effectively just a slightly more transparent bar code, which isn't
necessary.  I think an audit trail is sufficient -- the problem with
punch cards is that the voter doesn't get to confirm their choice in
such a way that a recount can match the confirmed, known correct choice
against what the machine read.

> My caution though is that usability testing for this is deeply hard,
> and I would advise against "a few weeks" even for demo prototype
> code as you suggest.

Well, the only way to do a usability test is with a demo, so no reason
not for him to dive in...

  Ian