[clug] eVACS lives!

Simon Fowler simon at himi.org
Tue Jan 27 01:31:02 GMT 2004


On Tue, Jan 27, 2004 at 11:52:20AM +1100, Martin Pool wrote:
> On 27 Jan 2004, David Gibson <david at gibson.dropbear.id.au> wrote:
> > On Sat, Jan 24, 2004 at 11:56:28AM +1100, Steve Jenkin wrote:
> > > Saw this on the ACM Technews list and thought that some of the
> > > contributors may still read the CLUG list.
> > > Love the way that 'Software Improvements' are
> > > 
> > > http://www.acm.org/technews/articles/2004-6/0121w.html#item1 [copied at
> > > end]
> > > 
> > > This summary points to the base article.  I'm sure there's many more.
> > > http://www.wired.com/news/evote/0,2645,61968,00.html
> > > 
> > > Canberra consistently 'punches above it weight' in IT, especially in
> > > Open Source.
> > > 
> > > Something I wasn't aware of [is this claim true?] - that the AEC was
> > > offered but did not want a 'VVPAT' - Voter Verified Paper Audit Trail.
> > > [A printer in _every_ polling booth - many $$$$]
> > 
> > Not just many $$$.  Printers just aren't reliable - they jam, mess up
> > prints, etc. etc.  When you're trying to guarantee various properties
> > about the number and nature of receipts printed, this makes life very
> > difficult indeed.  This, I think, is one of the primary reasons the
> > AEC didn't like the idea of a attempting to implement a vvpat.
> 
> Printing a receipt sounds fairly silly.  There are severe theoretical
> problems, aside from practicality and cost.
> 
> Australian elections are meant to be secret ballots.  Printing a
> record of how someone voted would encourage coercion or vote-buying by
> giving a record of how the person voted.
> 
> Printing a receipt does not address any important threat model.  If
> the machines are corrupt it would be trivial for them to print one
> thing and record another.  If the machines are merely flaky then it is
> easy to imagine that some votes would be lost after being printed.
> 
> Printing out receipts does not give a credible voter-verified audit
> trail anyhow, since the voter cannot verify that that the vote was
> permanently recorded and counted.  There are crypto protocols to allow
> voters to verify the whole process and it might be nice to use them,
> but they are a very large change from how we vote at the moment[0].
> The paper voting system relies on trusted observers monitoring the
> process, so it is reasonable that electronic voting works the same
> way.
> 
> If you *did* go to a crypto protocol that allowed both verifiability
> and anonymity, then you lose the ability for humans to verify it.
> (Factored many 2048-bit numbers recently?)
> 
> If the receipt *does* show something different to how you meant to
> vote, how are you supposed to resolve this?
> 
> Electoral officials should not normally connect a completed ballot
> with the voter[1], but resolving any problems with a receipt probably
> involves the person presenting the receipt to an official and losing
> their anonymity.
> 
> You don't get a receipt for a paper vote.  Why should an electronic
> vote be any different?
> 
The sane model I've seen is printing out a paper copy of the vote,
which is then verified by the voter and put into a ballot and
handled the same as any other paper ballots (maybe not identically -
you wouldn't want to put the printed ballots in with the hand-filled
ones, so you'd easily tell which votes had already been "counted"
electronically). 

It still suffers from the same reliability problems and so forth,
but it retains the secret ballot idea, and gives a paper trail that
can be used to check what the /voter/ agreed to on paper. The
electronic vote then becomes a shortcut to a quick result, rather
than the only record.

Not sure about the voting theory implications, of course . . . .

Simon

-- 
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS) 
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/linux/attachments/20040127/be64e956/attachment.bin


More information about the linux mailing list