OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

election-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Fw: New NIST draft on VVPATs and DRE audits

 Preliminary Report: NIST Approach to VVPAT Requirements for the VSS
 2002 Addendum (John Wack)

Although only a working draft this is definately a good step forward.

It definately vindicates the trusted process model - being
mostly the same - just some subtle but important 
differences remain.

One thing I intensely dislike here is this notion of
sealed ballot printers behind viewing screens.
We're supposed to be inspiring trust here -
and this whole approach smacks of distrust of the voters!

We've gone from being trusted to fill in our ballot by hand and
place in ballot box - to being unable to touch the ballot.

I think the NIST folks are being unnecessarily anal here
about the printing process.  A regular inkjet printer here
should be more than sufficient.  You can emboss the
paper to make that more secure - but basically each
ballot can have a hash code on it that needs to match
the electronic vote.

And 100% scanning to me is the only way to go - as
opposed to a limited audit of a small % of ballots.
The time differential is negligable - if you are going to
the trouble or scan 10% - while you are there - do
the other 90% through the hopper - its already setup
and running.  Doing a 100% audit means you can
relax the anal requirements on the printing side about
inks and all that business.  So long as they scan -
they should be acceptable.  Having all these anal
printing needs means high cost over using a
regular COTS printer.

Also - they are not separating the printing from the
eVote capture - that is a mistake - and misses the
fact that the DRE can cheat over the VVPAT
after the voter prints - especially if there is not
going to be a 100% check and audit.

Making a separation between DRE and the Printer
using XML just makes sense.  It also allows for the
whole ballot to be scripted - and therefore the
software can be reused repeatedly without
re-certification.  That's a big cost
saver / effort saver - and means ballots can be
implemented much more rapidly.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]