RE: [election-services] FYI: BREAKING: NATIONAL STANDARDS INSTITUTE RECO

Subject: RE: [election-services] FYI: BREAKING: NATIONAL STANDARDS INSTITUTE RECOMMENDSSCRAPPING TOUCH-SCREEN VOTING SYSTEMS!

-------- Original Message --------
Subject: RE: [election-services] FYI: BREAKING: NATIONAL STANDARDS
INSTITUTE RECOMMENDSSCRAPPING TOUCH-SCREEN VOTING SYSTEMS!
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
Date: Fri, December 01, 2006 6:08 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "Patrick Gannon" <patrick.gannon@oasis-open.org>,
<joehall@pobox.com>, "OASIS EML TC"
<election-services@lists.oasis-open.org>

David,

I think there is one further difference. In my example, both the DRE and the counting engine (which I think is your tabulator) keep counts. My counting engine has to have a "live" connection to the DRE, which should be a local, secure, wired LAN. The feedback from the counting engine to the user could be to a printer (no intelligence required - a teletype would do). The printed slips could then be stored.

We then have (using the printer model):

1. Voter casts "provisional" vote.

2. DRE records provisional vote and sends a 440 to the counting engine (CE).

3. CE records provisional vote and sends feedback to printer.

4. Voter confirms that vote has been correctly registered.

5. DRE and CE record the confirmed vote.

6. Voter puts paper record in ballot box.

At the end of the election period:

7. DRE And CE counts are compared for each DRE.

8. If they are different, the paper ballots are counted.

9. For audit purposes, some paper records are counted anyway and compared to the DRE and CE counts.

10. The paper record is also available for recounts.

I think this is software independent. I probably should have patented it!

Regards

Paul

-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 30 November 2006 13:18
To: Paul Spencer
Cc: Patrick Gannon; joehall@pobox.com; OASIS EML TC
Subject: RE: [election-services] FYI: BREAKING: NATIONAL STANDARDS INSTITUTE RECOMMENDSSCRAPPING TOUCH-SCREEN VOTING SYSTEMS!

Paul,

Yes - I'd gone down this path on my original trusted voting logic analysis.

By requiring EML as a foundation - then you have a set of mechanisms and data layouts that you can explicitly test for and have certification and conformance suites to validate.

In the trusted model I developed the 2nd trusted machine - actually is a printer - that receives the XML from the first machine - applies a built-in stylesheet and then dumps the result out to paper. Since the printer can be off the shelf and have this functionality built-in (darn these latest photo-smart printers ARE a complete computer!) - the only difference is that you have a permanent physical record on the paper - and the fact that the second printer has NO election specific logic in it - its just a generic "blackbox" that knows how to render XML to paper via a stylesheet.

But you absolutely need this second double-blind mechanism - to crosscheck what the first machine did electronically.

And of course there is a third machine involved - the central tabulation processor. So all three should confirm the records. Using a barcode that's associated with the original electronic 440 and then printed on the paper and then re-confirmed by the tabulator - allows you an audit trail - to confirm that only valid ballots were cast. (e.g. someone does not have a setup in a backroom somewhere ballot stuffing - happily creating ballot records and printing out cast ballot papers!).

The use of EML standard formats in key in being able to have independent manufacturers of DRE, printing and tabulation components - and having interchangability between them.

DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: RE: [election-services] FYI: BREAKING: NATIONAL STANDARDS
INSTITUTE RECOMMENDSSCRAPPING TOUCH-SCREEN VOTING SYSTEMS!
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
Date: Thu, November 30, 2006 4:37 am
To: <joehall@pobox.com>, "OASIS EML TC"
<election-services@lists.oasis-open.org>
Cc: "Patrick Gannon" <patrick.gannon@oasis-open.org>

The mechanism I have proposed before is that the DRE equipment should link
to counting equipment from another manufacturer. It is the counting
equipment that provides the feedback to the user. In this way, an error in
either the DRE or counting equipment is immediately detectable. The DRE
should also keep a count so that this can be compared to the counting
equipment count at the end of the day. I suspect that this two-stage process
(provisional vote and confirmation) may need a slight change to the 440
message. Since this could be key to promotion of EML in the USA, perhaps we
should check this and describe the scenario in detail. I will try to have a
look at it.

This seems to get round the "software independence" aspect. Of course, the
multi-manufacturer approach relies on open standards for the interface ...

Any views? Especially from our two NIST observers?

Paul

> -----Original Message-----
> From: Joseph Lorenzo Hall [mailto:jhall@SIMS.Berkeley.EDU]
> Sent: 30 November 2006 02:40
> To: OASIS EML TC
> Cc: Patrick Gannon
> Subject: Re: [election-services] FYI: BREAKING: NATIONAL STANDARDS
> INSTITUTE RECOMMENDSSCRAPPING TOUCH-SCREEN VOTING SYSTEMS!
>
>
>
> On 11/29/06, David RR Webber <david@drrw.info> wrote:
> >
> > Kudos to NIST on making this assessment,
>
> Actually, what NIST is recommending is "Software Independence":
>
> http://vote.nist.gov/meeting20061204.htm
> http://vote.nist.gov/DraftWhitePaperOnSIinVVSG2007-20061120.pdf
>
> Which, if adopted, would mean that paperless DREsof which
> touchscreens are a subsetwill not be certifiable by the EAC when the
> 2007 VVSG come into effect in Dec. 2009. -Joe
>
> --
> Joseph Lorenzo Hall
> PhD Student, UC Berkeley, School of Information
> <http://josephhall.org/>

election-services message