RE: AVVPAT-ABP revised draft
In the US, private voting system vendors sell systems that are
proprietary systems protected by trade secrets. No matter how much
independent testing is done, as long as these systems are trade
secrets and not available for public inspection, there will be the
question of their trustworthiness and (A)VVPAT will be useful in
addressing the trustworthiness of DREs. The system in India was
developed under government contract and is publicly owned and the
election in India (as I understand it) was much simpler than typical
US elections, so it is not comparable. VVPAT's are also useful for
recounts. Even if only 20% of the people checked the VVPAT, that
number plus the existence of the VVPAT would be useful in reducing
the potential and perception of the potential for fraud or error.
For those systems for which a VVPAT is used, the Annex is and should
be normative. For those systems for which a VVPAT is not used, the
Annex does not apply.
Best regards,
Arthur
At 6:59 AM +0100 12/3/04, Jacques Hulshof wrote:
>Dear Stephen,
>
>Our reaction to Annex I and VVPAT:
>
>1. On the last MIT / Caltech voting project conference October
>1 and 2, 2004 Adam Stubblefield, the speaker of the Hopkins
>University, recognized that software can be checked 100% if there
>are not too many lines.
>2. In the Ted Selker and J. Goler paper "The SAVE system -
>Secure architecture for voting electronically" BT Technology Journal
>Vol 22 No 4 October 2004 we noticed the same trend.
>NOTE: I have this Selker/Goler paper in my possession, but cannot
>send it because of copyright issues. I am trying to solve the
>copyright issue together with Bill Ash of IEEE.
>3. In India 668 million voters used voting machines without
>VVPAT. These voting machines are not using windows based software,
>but direct compiled software so called firmware. The results of the
>election differ quite a bit from the polls, but the voters did not
>doubt the system. Again the explanation has been the relative simple
>concept of the vote storage.
>
>We can conclude that VVPAT or comparable measures are not necessary
>if one can have the system completely tested (firmware and hardware
>alike). In fact this has been a comment made during the last IEEE
>meeting (visited by Hans van Wijk).
>As we are following this direction we think it is totally wrong to
>make a VVPAT normative as the VVPAT is a superfluously addition to a
>system which is a simple voting registration structure.
>This distinctive difference is not yet reflected in the IEEE recommendations.
>
>To avoid misunderstandings we strongly suggest splitting the DRE
>groups into 2 categories as suggested earlier (NEDAP comments on
>Concept 5)
>2
>NEDAP 2
>3 Definitions
>45
>technical
>Direct Record Electronic (DRE) Voting System:
> A voting system that records votes by means
>of a ballot display provided with mechanical
>or electro-optical components that can be
>actuated by the voter, that processes the
>data by means of a computer program;
>and that records voting data and cast vote
>records in internal and/or extarnal memory
>components. It produces a tabulation of the
>voting data stored in a removable memory
>component and/or printed copy.
>
>If this split is not possible anymore we kindly request to get the
>opportunity to add an annex where this observation is explained
>
>Jacques Hulshof
>N.V. Nederlandsche Apparatenfabriek "Nedap"
>+ 31 (0) 544 471 162 (Phone); + 31 (0) 544 463 475 (Fax)
>+ 31 (0) 6 53718821 (Mobile); jacques.hulshof@nedap.com
>Parallelweg 2, NL-7141 DC Groenlo
>or P.O. Box 6, NL-7140 AA Groenlo, The Netherlands
>
>
>-----Original Message-----
>From: Stephen Berger [mailto:stephen.berger@cox-internet.com]
>Sent: dinsdag 30 november 2004 16:43
>To: Jacques Hulshof; 'Arthur Keller'; 'Jim Adler'
>Cc: 'David Aragon (E-mail 2)'; stds-1583-stg3@IEEE.ORG; 'Sanford
>Morganstein'; 'David Patterson'; 'Robert Oliver'
>Subject: RE: AVVPAT-ABP revised draft
>
>Jacques,
>
>I believe I understand the intent of your comment but this is not best
>accomplished by the use of NORMATIVE and INFORMATIVE. I think to accomplish
>your purpose either a scope statement should be prominently added, e.g. The
>requirements of this section apply only to .... An alternative is the
>appropriate use of shall/should/may to identify mandatory requirements, from
>different levels of suggested or advisory material. Even mandatory
>requirements can be appropriately scoped, e.g. DREs that utilize a touch
>screen shall ...
>
>Best Regards,
>
>Stephen Berger
>
>TEM Consulting, LP
>
>
>Web Site - www.temconsulting.com
>E-MAIL - stephen.berger@ieee.org
>Phone - (512) 864-3365
>Mobile - (512) 466-0833
>FAX - (512) 869-8709
>
>
>-----Original Message-----
>From: owner-stds-1583-stg3@listserv.ieee.org
>[mailto:owner-stds-1583-stg3@listserv.ieee.org] On Behalf Of Jacques Hulshof
>Sent: Tuesday, November 30, 2004 9:19 AM
>To: Arthur Keller; Jim Adler
>Cc: David Aragon (E-mail 2); stds-1583-stg3@IEEE.ORG; Sanford Morganstein;
>David Patterson; Robert Oliver
>Subject: RE: AVVPAT-ABP revised draft
>
>Dear All,
>
>One of NEDAP's comments was: Change Annex I to Informative and not
>Normative. Normative indicates that if a vendor wants to get an approval
>of a DRE he shall include a AVVPAT. This is then compulsory. This i9s
>not what we want.
>
>Jacques Hulshof
>N.V. Nederlandsche Apparatenfabriek "Nedap"
>+ 31 (0) 544 471 162 (Phone); + 31 (0) 544 463 475 (Fax)
>+ 31 (0) 6 53718821 (Mobile); jacques.hulshof@nedap.com
>Parallelweg 2, NL-7141 DC Groenlo
>or P.O. Box 6, NL-7140 AA Groenlo, The Netherlands
>
>
>-----Original Message-----
>From: Arthur Keller [mailto:ark@SOE.UCSC.EDU]
>Sent: dinsdag 30 november 2004 11:45
>To: Jim Adler
>Cc: Arthur Keller; David Aragon (E-mail 2); stds-1583-stg3@IEEE.ORG;
>Sanford Morganstein; David Patterson; Robert Oliver
>Subject: RE: AVVPAT-ABP revised draft
>
>Dear Jim, the changes to I.3.2.1 are relatively minimal, except
>renumbering to I.3.2.2. This section refers to DRE/AVVPAT. A new
>section I.3.2.1 refers to ABP (EBM and EBP) for which input was
>received from Populex only. The Automark system would also be
>handled in this section, but no input has been received from them. I
>suggest we go with what I have and give them a chance to
>comment/revise it later.
>
>I've included a new section I.3.2.1 (ABP-20041130.doc) that should
>precede the existing section I.3.2.1 or follow it. For convenience,
>I've shown the changes from the existing I.3.2.1 (even though this
>section is an addition, not a replacement).
>
>Regarding the existing I.3.2.1:
>Comment 40, BO061 change conflicts with the split of ABP (EBM/EBP),
>so I made a different clarifying change instead.
>
>Comment 44, BO063, is replaced by the split of ABP.
>
>Comment 55, ISP034. I made this change, but the proposed fix is
>infeasible. It is also incompatible with I.3.2.1.2.3.4
>
>Comment 65, BO064. I suggest replacing the prescriptive "is
>expressly permitted" (for physically adding write-in candidates) by
>"may be permitted." The proposed edit *enforces* an alternative
>design to using the keyboard or a keyboard metaphor.
>
>Comment 66, BO065. I did not make this change, since it does not
>apply to DRE with AVVPAT. It instead applies to EBP/EBM's.
>
>Comment 73, BO069. I made the change, except for the replacement of
>"accept" to "cast". In a AVVPAT, the paper trail is not cast, since
>it's an audit trail. On an EBM/EBP, the paper is cast. This is part
>of the confusion for which EBM/EBP category was created.
>
>Comment 75, BO070, applies to EBM/EBP's not DRE/AVVPAT's.
>
>Comment 77, BO071, ditto.
>
>Comments 80-82, ISP049-051. This change is inconsistent with change
>84, BO072. I've made an alternative change to Jim Adler's and left
>it for him to edit further. I changed the first sentence to "any of
>the languages" and added "supported by the DRE in this jurisdiction"
>
>Comment 89, ISP056. I put "for a reasonable ballot length" in a
>different place where it fit better.
>
>Comments 90 and 91 conflict, so I deferred them for a group lead.
>Similarly Comment 92 was deferred
>
>I don't know how to reflect Comment 94. So I didn't.
>
>I've included a version of AVVPAT section I.3.2.1 reflecting the
>split with ABP(EBM/EBP) and comments 40-94 except as noted above.
>
>Sanford Morgenstern suggested this addition to end of the existing
>I.3.2.1.3.1.1.1. It's a substantive change that requires change by
>group lead.
>All testing shall be performed on an end-to-end basis such that
>ballot information shall be prepared, loaded onto the DRE, cast on
>the DRE/AVVPAT, verified on the DRE/AVVPAT and tallied on such system
>intended for use with the AVVPAT. Since in some jurisdictions, the
>AVVPAT may service as the determinant of the voter's intent, the
>AVVPAT must be capable of being tallied with the same accuracy as
>provided elsewhere in this Standard.
>
>
>At 8:41 PM -0800 11/28/04, Jim Adler wrote:
> >Arthur - Do you have consensus on the change of I.3.2.1 from the major
> >proponents of VVPB? I have no problem inserting it in its entirety, I
>just
> >want to make sure we have some consensus.
> >
> >-- Jim
> >
> >-----Original Message-----
> >From: Arthur Keller [mailto:ark@SOE.UCSC.EDU]
> >Sent: Tuesday, November 23, 2004 12:16 PM
> >To: stds-1583-disc@IEEE.ORG; stds-1583-stg3@IEEE.ORG
> >Cc: Stanley A. Klein; Sanford Morganstein
> >Subject: AVVPAT-ABP revised draft
> >
> >
> >This is a replacement for section I.3.2.1
> >
> >This reflects most of the comments from Stanford Morgenstern.
> >
> >The organization discussion group on stds-1583-disc identified three
> >types of electronic voting machines that produce paper:
> >
> >DRE with an AVVPAT - Direct Recording Electronic with an Accessible
> >Voter-Verified Paper Audit Trail
> >EBM - Electronic Ballot Marker (a computerized device that marks a
> >paper ballot suitable for hand marking)
> >EBP - Electronic Ballot Printer (a computerized device that prints a
> >paper ballot, including the selections for each contest)
> >
> >Before those terms were defined, I started working on a revision to
> >Rebecca Mercuri's AVVPAT annex, separating out something I called an
> >ABP (Accessible Ballot Printer). It turns out that there is enough
> >in common between an EBM and an EBP that I was able to cover them
> >together (in the write up for an ABP), along with making the
> >appropriate distinctions along the way. Separating out the ABP from
> >the DRE-AVVPAT did simplify matters, however. I apologize to the EBM
> >community that I called the combination category an Accessible Ballot
> >PRINTER. I'm open to an alternative term.
> >
> >Stan Klein wrote a section he submitted on November 14. He wrote
> >about that section:
> >The title could remain "ancillary devices for optical scan ballots"
> >or, if the EBM and EBP terminology becomes formalized, for
> >consistency it could be called "electronically assisted manual ballot
> >marking" (EAMBM).
> >
> >We need to settle on a name for the combination of EBP/EBM, and we
> >need to harmonize Stan Klein's document with this document.
> >
> >Thanks.
> >
> >Best regards,
> >Arthur
> >
> >--
> >-----------------------------------------------------------------------
>-----
> >---
> >Arthur M. Keller, Visiting Associate Professor, Computer Science Dept.
> >University of California, Baskin School of Engineering, Room 153B,
> >1156 High Street, Santa Cruz, CA 95066-1077
> >tel +1(831)459-1485, fax +1(831)459-4829, www.soe.ucsc.edu/~ark
>
>
>--
>------------------------------------------------------------------------
>-------
>Arthur M. Keller, Visiting Associate Professor, Computer Science Dept.
>University of California, Baskin School of Engineering, Room 153B,
>1156 High Street, Santa Cruz, CA 95066-1077
>tel +1(831)459-1485, fax +1(831)459-4829, www.soe.ucsc.edu/~ark
>
>
>
>
--
-------------------------------------------------------------------------------
Arthur M. Keller, Visiting Associate Professor, Computer Science Dept.
University of California, Baskin School of Engineering, Room 153B,
1156 High Street, Santa Cruz, CA 95066-1077
tel +1(831)459-1485, fax +1(831)459-4829, www.soe.ucsc.edu/~ark