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

["David RR Webber \(XML\)" <david@drrw.info>]

Peter,

 

I totally agree - the "secret sauce" here is one that provides independent mechanisms that can be implemented irrespective of the particular device hardware setup. 

 

What we are talking about is estabishing a minimum level of functionality so that buyers know that the solution is robust (undervotes / overvotes, etc), reliable - and as John noted - auditability, transparency and accreditation.

 

After that it's up to customers to decide if their systems statisfy their other needs appropriately. 

 

I believe we have more than demonstrated that EML can do the job needed - and EML has been correctly designed to control the interchange points in the process - which is always the common sense approach to building a workable set of independent mechanisms.  Do not sweat the internal details - manage and control the interchange points.  NIST and EAC have waste vast time and effort on sweat details that are peripheral and irrelevant - when you establish simple clear standard mechanisms for the interchange control and the content therein.

 

What is frustrating is that OASIS has a perfectly functioning set of standards that NIST can adopt RIGHT NOW.  Instead NIST is provaricating and waffling about not being able to do so until further research is done over the next five years.  And the examples of "current research" NIST cited is old and weak too boot.

 

This is boardering on incompetence on their part in my book - am I missing something - or are they the National Institute of Standards and Technology?  My simple reply to their statement today at the TGDC is "WRONG ANSWER!"   And I'm sure there are going to be droves of politicians and citizens who are fed up with the lack of progress who are going to say the same thing.  Politicians like Barbara Samorajczyk who this week could not get a re-count because of this (see quote below). 

 

NIST have not even attempted to show if OASIS EML can or cannot do the job and use case we've presented.  It's not like EML is some huge secret technology that NIST is completely unaware of.

 

We can pilot this with NIST starting next week - we have the XML, we have the open source code and we have sample deployments.  It's time NIST stopped evading this and actually delivering something worthwhile that will assist every vendor and customer out here.

 

DW

 

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

Barbara Samorajczyk, who lost to Ronald A. George by 53 votes in House of Delegates District 30, said she conceded by phone yesterday after deciding that "there wasn't any meaningful way to do a recount" with electronic voting machines. "We cannot recount the machine," Samorajczyk said.

-------- Original Message --------
Subject: RE: [election-services] FYI: BREAKING: NATIONAL STANDARDS
INSTITU TE RECOMMENDSSCRAPPING TOUCH-SCREEN VOTING SYSTEMS!
From: "Zelechoski, Peter" <pzelechoski@essvote.com>
Date: Mon, December 04, 2006 11:29 am
To: "'David RR Webber (XML)'" <david@drrw.info>
Cc: 'Patrick Gannon' <patrick.gannon@oasis-open.org>,
"'joehall@pobox.com'" <joehall@pobox.com>, 'OASIS EML TC'
<election-services@lists.oasis-open.org>, 'Paul Spencer'
<paul.spencer@boynings.co.uk>

David -

 

I have attempted not to step into this -- being a vendor representative, I don't feel endorsing any specific deployment is appropriate.

 

The conceptual part of using EML and sending the 440 to any independent system for a separate validation is what delivers the independent validation that NIST is moving toward.  That concept is what is important, not any specific physical manifestation.

 

Personally, I take offense at blanket discussion of any voting system as bad.  Every system in use has good and bad points.  I participate on the EML group and in the IEEE group because I believe that open standards are where we need to head to provide for transparent independent validation to let everyone have more confidence in the results from all systems.

 

- Peter

-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Friday, December 01, 2006 12:16 PM
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,

 

No - we're both talking about the exact same identical thing. 

 

Some further nuances / notes - since I'm not allowing the DRE to be directly connected to the printer - it does indeed send its 440 to the count recording engine (CE) - and THAT then releases the 440 to for the printer to print.

 

In the typical USA scenario however - each printer is located next to the DRE voting terminal - but networked from the CE - so - the voter takes the printed ballot - and casts it into the ballot box. 

 

A scanner next to the ballot box can wand the barcode on the ballot to confirm that the paper ballot has actually been deposited in it.  (This allows people to spoil their ballot if they are so inclined by trashing the paper and exiting).

 

A further option is then to actually fully scan the paper ballot printed - at the ballot box - so a separate 440 can then be substanciated.  That provides 3 records then - one from the DRE, one sent to the printer, and the third from the scanner.  However the two records and the separate confirmation of acceptance by the voter depositing in the ballot box would be sufficient as in your model.

 

You cannot patent this - I already made this open public work two years ago - and submitted this to NIST too (I guess someone finally read through all those public submissions!) ; -)

 

I'll take that back - you can patent any darn thing you care too - the sillier the better it seems - (just noticed that Blackboard Inc have a patent now describing when a student is a student and a teacher is a teacher - but that's another whole story) : -(

 

I think we'll stick to just solving this voting thing - it's easier!

 

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: 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/>