United States Election Assistance Comittee

Register to Vote!

Use the National Mail Voter Registration Form to register to vote, update your registration information with a new name or address, or register with a political party.

Note: If you wish to vote absentee and are a uniformed service member or family member or a citizen living outside the U.S., contact the Federal Voting Assistance Program to register to vote.

EAC Newsletters
and Updates

Sign up to receive information about EAC activities including public meetings, webcasts, reports and grants.

Give Us Your Feedback

Share your feedback on EAC policy proposalsElection Resource Library materials, and OpenEAC activities. Give feedback on general issues, including the Web site, through our Contact Us page.

Military and Overseas Voters

EAC has several projects under way to assist states in serving military and overseas citizens who register and vote absentee under the Uniformed and Overseas Citizens Absentee Voting Act. Learn more

Chapter 1: Introduction

This part of the VVSG, Equipment Requirements, contains requirements applying to the voting system and the voting devices that it contains. It is intended primarily for use by manufacturers and testing labs. The Equipment Requirements may also be of use to election officials in setting requirements for voting systems in requests for proposals.

This part contains 8 chapters, organized as follows:

  • Chapter 2: conformance-related information and requirements;
  • Chapter 3: usability, accessibility, and privacy requirements;
  • Chapter 4: auditing and records-related requirements;
  • Chapter 5: security-related requirements;
  • Chapter 6: core requirements;
  • Chapter 7: requirements arranged by voting activity; and
  • Chapter 8: reference models – process model, vote-capture device state model, and logic model.

1.1 Changes from VVSG 2005 and Previous Versions of the Standards

5 Comments

Comment by Sheila Parks, Ed.D. (General Public)

On November 7, 2006, I observed the General Election in Acton, ME. They used the read and tally/mark prototocol for hand-counted paper ballots (HCPB). With seven races and two initiatives, the six teams of two people each hand-counted twice 944 ballots in four hours. Since both DRE's and optical scan electronic voting machines have been publicly hacked, (see http://bbvforums.org/forums/messages/2197/6847.html for the Harri Hursti reports of his hacking, done with Black Box Voting),these machines should NEVER be used in our voting systems. We must make sure that each one of our votes is counted as cast. This is the cornerstone of democracy. I am writing to recommend that we must use a hand-counted paper ballots (HCPB) system to help restore the USA to democracy. Based on my observations of the election in Acton, ME, I recommend the following: 1)The hand-counting of paper ballots must immediately be followed by a complete second hand-counting and a reconciliation of the two counts, if necessary, by additional counting. 2)Ballots are to be hand-counted at the precinct by registered voters in that precinct. 3) The counting is done in full view of the public. 4) The counting is videotaped. 5)The results are posted at the precinct immediately after the count. 6) To be manageable, precincts are no larger than 1000 registered voters. (Because the concept of HCPB operates at the precinct level, even large communities can adopt such a system.) 7)In each precicnt there are at least 10 teams of two counters each (a Democract and a Republican). I have not included chain of custody here, and that is imperative for a HCPB election that is secure. For a beginnning discussion of chain of custody see my paper "Hand-Counted Paper Ballots Now at http://www.tikkun.org/magazine/specials/article.2006-04-10.1693298872. An updated version of this article can be found at http://electionfraudnews.com/News/HCPBNow.htm. My article which fully describes the Acton, ME HCPB election and called "ON-SITE OBSERVATIONS OF THE HAND-COUNTING OF PAPER BALLOTS AND RECOMMENDATIONS FOR THE GENERAL ELECTION OF 2008 can be found at http://www.opednews.com/articles/opedne_sheila_p_070718_on_site_observations.htm A third aricle on the need for HCPB elections can be found at www.tikkun.org/magazine/reviews/article.2006-01-06.7975946864 It is way past time to take our elections away from "experts" and the privatized electronic voting machine industry and give back our elections to We The People. Our democracy is at stake. The right to vote, as well as the principle of "one person, one vote" are cornerstones of our democracy. The anti-slavery,women's suffrage,and civil rights movements as well as the extension of voting to young people are all part of the history of electoral reform in this country. Equally fundamental is the assurance that each voter knows that her or his vote counts and is counted as intended. At this time in our history, many have lost confidence in our voting system. We must return our elections to HCPB now. Sincerely, Sheila Parks, Ed.D.

Comment by Kevin Baas (General Public)

Instead of "certified" or "not certified", perhaps it would be more useful for election commissions if voting technology was rated, sucha s by A through F. "not certified" would then be "F". For instance, paper ballots with optical scan machines for counting would get an "A", and, due to the inherent vulnerabilities in programmable logic, any programmable device, such as touchscreen voting, would get no better than an "F". Just a computer programmer's opinion. To be fair, I should really break it down and consider the technologies on their merits: Paper ballots w/optical scan: Reliability: A Verifiability: A Tamper-resistance: A Cost: A Overall: A E-voting: Reliability: F Verifiability: F Tamper-resistance: F Cost: F Overall: F Okay, well, that didn't seem to make a whole lot of difference. Any case, point is, maybe you should rate these things. Break them down into categories like this and rate them in each category, then publish the results. I think that would be a lot more helpful for people deciding what technology to go with for an election.

Comment by John R. Hudson, Jr. (State Election Official)

It appears that this is crediting hand counting of ballots as being more accurate than electronic machine counting which has been long ago proven untrue. Plus as we all know if there is considerable hand counting required, which will be the case in a lot of places, there is insufficient time to complete the task, and the cost to the local election boards, may very well be considerable and not paid for by state or federal funding. If hand counting is going to be the "gold standard", the system is immediately fatally flawed.Those of us who have had years of "hands on" election experience know this first hand.I implore you to clear this up by removing this provision.

Comment by James C. Davis (Voter)

All computer systems can malfunction or be deliberateley corrupted at any stage of their design, manufacture, and use. The methods used to do this can be extremely difficult to foresee and detect. It is crucial to the integrity of elections that voting systems provide a means of recording and recovering voter intent THAT DOES NOT DEPEND ON THE RELIABILITY OF THE SOFTWARE"

Comment by E Smith/P Terwilliger (Manufacturer)

1.1.1. Is VVPR defined as "verifiable" or "verified"? Appendix A conflicts with this section. 1.1.3. Missing words in 4th paragraph "software security all system modes"

1.1.1 Conformance clause

The conformance clause has been expanded to define classes of voting systems and devices. Classes are an evolution of the notion of voting system "categories" that appeared in previous Guidelines. Those categories were paper-based, DRE, precinct count and central count.

The conformance clause also contains requirements for software independence, and the two methods for satisfying software independence in the VVSG:

  • Use of independent voter-verified records (IVVR);
  • The Innovation Class.

IVVR is a general category; voter-verified paper records (VVPR) is the only type of IVVR used by voting systems. In essence, only voting systems that use VVPR can currently conform to the VVSG unless new types of IVVR are developed.

The Innovation Class is a method for specifying new and innovative voting systems that meet the definition of software independence but in other ways besides IVVR.

8 Comments

Comment by Anne Kennedy Rackham (General Public)

Thus far, no information has been presented which is not geared toward the industry which has written and will be charged with administering this bogus system.

Comment by Michael J. Baker (Federal Agency)

The term "Software Independence" would be better replaced by the term "Software Integrity", per the definition provided.

Comment by ted selker (Academic)

"voter-verified paper records (VVPR) is the only type of IVVR used by voting systems. In essence, only voting systems that use VVPR can currently conform to VVSG unless new types of IVVR are developed Should be deleted." This approach has been problematic and should not be codified in standards as a proven solution.

Comment by George Gilbert (Local Election Official)

1.1.1-- The entire premise behind "software independence," as defined by the proposed standards, is unsupportable. It rests upon the assumption that paper ballot records, examined visually by human beings, can be more accurately interpreted and tabulated than any computerized system of recording and tabulating votes. This assumption is not supported by history, it is not supported by research, it is not supported by the practices in every other major private or governmental enterprise. Reliance on this assumption impels reliance on manual auditing and, ultimately, on manual recount procedures. This, as acknowledged by this section, compels the use or production of paper records under currently applied technology. But with or without paper records, this requirement of manual auditing and tabulation lies at the heart of the problem. Even development of so called "innovation class" technologies will not address this problem since, as currently conceived, even "innovation class" technology produced IVVRs will be subject to the hand auditing requirements of these standards. To require "software independence" for all audit mechanisms leaves the accuracy and integrity of our election outcomes ultimately reliant on the accuracy and integrity of the people executing or observing the system. While the human brain perhaps cannot be deemed "programmable" or "software" in the technical sense, its performance is certainly not certifiably accurate nor certifiably free of "malware." Accurate, verifiable and reliable tabulation must be the objective of voting system standards. While "software independent" systems may provide accurate, verifiable and reliable recording of votes, they fail to achieve the end product of elections which is the certified results.

Comment by John R. Hudson, Jr. (State Election Official)

The definition of software independence is so worded that it only applies to DREs, which I hope is not the intent, and seems to impose an unattainable goal for them. If there is an undetected change or fault, how can that system cause it to be detected or the error found? This appears to be a catch 22 clause which would not be possible for any DRE system to obtain, as how you are able to detect the undetectable with that software, and if you do detect it , it was not undetectable. Independent software would seem to be what should be the appropriate nomenclature, and would have a seperate system in place to continuously monitor the election software so that it detected the change or fault, and reported it.

Comment by Frank Padilla (Voting System Test Laboratory)

IVVR is a general category; voter-verified paper records (VVPR) is the only type of IVVR used by voting systems. In essence, only voting systems that use VVPR can currently conform to the VVSG unless new types of IVVR are developed. Wording should be changed to stated that VVPR is the only type of IVVR currently used in certified voting systems.

Comment by Mary Vollero (Advocacy Group)

In order for citizen to maintain confidence in the election results all voting systems need to include a voter verified paper ballot AND random, mandatory audits of these ballots in all elections. DRE touch screens have proven to be problematic, adding votes, losing votes, and flipping votes. We should be using a paper ballot systems such as optical scans with audits.

Comment by Ariel J. Feldman, Harlan Yu, Joseph A. Calandrino (Princeton University) (Academic)

This draft leaves open the possibility that paperless voting systems could be approved in the future if they are deemed software independent. Since the consensus of the computer security community is that paperless software independent systems are beyond the state of the art, we are concerned that the VVSG is too vague about the process by which paperless systems could be approved. Although we support further research into paperless software independent voting systems, we believe that it is important to make sure that the approval process for future paperless voting systems does not become a loophole that allows the current flawed generation of paperless voting systems to be certified.

1.1.2 Usability Performance Benchmarks

The usability requirements in VVSG 2005 contained requirements that are design-based. This version of the VVSG retains some of those requirements but also uses a new method based on summative usability testing that may more directly addresses the usability of the voting system, based on how accurately test participants are able to vote. The features of this new method include:

  • The definition of a standard testing protocol, including a test ballot, set of tasks to be performed, and demographic characteristics of the test participants. The protocol supports the test procedure as a repeatable controlled experiment;
  • The use of a substantial number of human subjects attempting to perform those typical voting tasks on the systems being tested, in order to achieve statistically significant results;
  • The gathering of detailed data on the subjects' task performance, including data on accuracy, speed, and confidence;
  • The precise definition of the usability metrics to be derived from the experimental data;
  • The definition of effectiveness benchmarks against which systems will be evaluated.

2 Comments

Comment by ted selker (Academic)

"The use of a substantial number of human subjects" should be changed to: "the use of a statistically significant number of human subjects"

Comment by ted selker (Academic)

"Protecting electronic voting record" should be changed to: "protecting voting records" All records should be covered. Signatures and locks should protect printed or electronic records.

1.1.3 Security requirements

The security requirements for voting systems have been expanded from VVSG 2005 to provide more complete coverage for different types of voting devices and for all phases of voting. Three entirely new sections have been added for voting device cryptography, event logging, and system integrity management. A number of other sections of security material from VVSG 2005 have been reworked and expanded.

VVSG 2005 contained a section on independent verification systems and VVPAT. This material has been largely reworked to focus on requirements on voting system records for voting systems that use independent voter-verifiable records (IVVR), including VVPAT and optical scan (which use one form of IVVR, voter-verifiable paper records (VVPR)). The concept of independent verification has been broadened to software independence.

The new section on voting device cryptography specifies that signatures for protecting electronic voting records used in audits be generated in an embedded hardware signature module, and includes a basic key management scheme. The new section on event logging expands logging requirements for voting devices and using secure log techniques.

The new section on system integrity management deals with operating system and application software security all system modes of voting. Some of the requirements are based on controls specified on technical standards for gaming machines [NGC06]. The requirements mandate secure boot loading and digital signature verification on binaries before loading. There are additional requirements on backups and expanded requirements from VVSG 2005 dealing with malware detection.

The access control section of VVSG 2005 now specifies baseline access controls for voting system resources such as data files, application programs, underlying operating systems, and voting system devices. The section specifies minimum types of authentication for role-based and identity-based access control.

The telecommunications and wireless communication sections of VVSG 2005 have been combined. A major difference is that this version of the VVSG prohibits radio frequency wireless in voting systems; VVSG 2005 restricted but did not prohibit radio frequency wireless.

The setup validation requirements in VVSG 2005 have been reworked into a newer section on software inspection. A major change in this section is that voting systems are no longer required to be capable of supporting a software setup validation technique that operates independently of the voting system. VVSG 2005 I.7.4.6 required this to be performed via a read-only external interface or by other means; this requirement has been removed in favor of requirements to support software independence and that verify digital signatures on binaries prior to loading.

4 Comments

Comment by ted selker (Academic)

"The VVSG prohibits radio frequency wireless in voting systems" might be changed to: "VVSG prohibits radio frequency wireless hardware in voting systems during setup, while voting, and until memory records have been removed."

Comment by George Gilbert (Local Election Official)

1.1.3—This section asserts that "the concept of independent verification has been broadened to software independence." It is clear that the definition and resulting application of the "software independence" concept is a stringent narrowing of the "independent verification" concept, not a "broadening." If no software or programmable devices can be used integral to an independent voter verifiable recording system, numerous highly effective options (those used by practically every other large scale enterprise in the developed or developing world) are excluded. The final paragraph of this section makes the curious claim that the new "software independent" criterion frees voting system software of having to support "a software setup validation technique that operates independently of the voting system" and implies the elimination of a "read only external interface" requirement. While I am not clear on what is meant by "a software setup validation technique," is seems to me that a VVPAT, or any IVVR system contemplated herein for DRE systems, requires a "read only external interface." In fact, a read only external interface with a record capture device, operating on independent (open source) software, capable of displaying (perhaps on a viewing screen) the voter’s choices and recording the data pursuant to the "Integratibility and Data Export/Interchange" standards appears to promise far greater reliability and security than current or envisioned VVPAT technology. The voter verified record could then be audited, or recounted in entirety, by any selected tabulation software including over the counter spreadsheet or database packages. Simply capturing and displaying rather, than printing, the print string currently send to a VVPAT printer and preserving the record in a simple data file would likely be no more costly that a VVPAT device and would likely be from more reliable. While the use of cryptography would increase the complexity of the software, it would also enhance the security of the whole system.

Comment by David Beirne, Executive Director, Election Technology Council (Manufacturer)

"Concept of independent verification defined in 2005 VVSG has been expanded to include software independence" Independent verification remains a more accurate description for the role and function of the IVVR as it cannot, by itself, provide an assessment for software performance.

Comment by Penelope Starr (Voter)

I am not going to make a comment at the end of each chapter and paragraph. Suffice it to say that we simply need a wait of verifying voter intent. Computers are subject to corruption anywhere from the design stage to the end user stage. Aside from unintentiontal defects, the chances of deliberate interference are all too real in today's world. We need to protect our democracy and way of life by preserving a voter verifification system and the records should be kept for at least a year after the election.

1.1.4 Epollbooks and ballot activation

Requirements on ballot activation involving epollbooks have been added to Part 1: 7.5.1 "Issuance of voting credentials and ballot activation". New requirements have been added primarily to protect integrity and privacy of ballot activation credential information and to ensure records on epollbooks and vote-capture devices cannot be aggregated to violate secrecy of the ballot. Epollbooks are permitted to activate the ballot while connected to an external voter registration database; various requirements on network security are included.

4 Comments

Comment by David Beirne, Executive Director, Election Technology Council (Manufacturer)

"New requirements affecting epollbooks have been added to protect and integrity and privacy of ballot activation and credential information and to ensure records on epollbooks and voting machines cannot be aggregated to violate secrecy of the ballot; various requirements will also address network security" The inclusion of epollbooks within the VVSG is further evidence of the need to include industry representation within the development of the VVSG as many epollbook providers are not currently subject to voting system certification. While the intent is clear, epollbooks are an evolving field of products which operate differently from one another and may have no direct relationship with a voting system. This approach to epollbooks needs to be closely scrutinized as it may portend a jump for the EAC to begin regulating other products "deemed" to be part of the overall voting system.

Comment by Cem Kaner (Academic)

A majority of respondents, in a poll of the IEEE SCC38 Voting Standards committee, supported the recommendation that: "The use of electronic poll books be banned in polling locations and that printed poll books be required." .......... The underlying concern is that in past cases in which fraud has been detected, printed poll books with voters' actual signatures have been important records. .......... VVSG does not take a comprehensive look at the auditability of election records and therefore it is difficult to assess the impact of substitution of printed poll books with electronic ones. Given that there have been so many problems with electronic voting equipment, the addition of more electronic components is bound to be met with appropriate mistrust. .......... (Affiliation Note: IEEE representative to TGDC)

1.1.5 Common data format

Requirements dealing with making voting device interfaces and data formats transparent and interchangeable have been added to Part 1: 6.6 "Integratability and Data Export/Interchange". Although these requirements do not mandate a specific standard data format, manufacturers are encouraged to use consensus-based, publicly available formats such as the OASIS Election Markup Language (EML) standard [OASIS07] or those emanating from the IEEE Voting System Electronic Data Interchange Project 1622 [P1622].

0 Comments

No Comments

1.1.6 Core requirements

The core requirements for voting systems to define elections and to collect, count, and report votes have been expanded to specify what functionality must be provided in order to claim support for the many jurisdiction-specific voting variations such as cumulative voting, straight party voting, etc. In previous versions of the guidelines, manufacturers were required to identify which variations were supported and to document how those variations were supported, but the guidelines lacked any functional requirements on the variations. The new requirements define a baseline of functionality for each of the voting variations.

The requirements have been broadened to cover Electronically-assisted Ballot Markers (EBMs) and Electronic Ballot Printers (EBPs). These devices' combination of a DRE-like interface with a paper-based method of recording votes was something that previous versions of the guidelines did not handle.

The metric for reliability has been changed from Mean Time Between Failure (MTBF) to a failure rate based on volume that varies by device class and severity of failure. The metric for accuracy has been changed from ballot position error rate to report total error rate, and separate requirements referring to specific, low-level operations have been replaced with a single, general, end-to-end accuracy requirement. The metrics for multiple feed and rejection of ballots that meet all manufacturer specifications have been merged into a single "misfeed" metric. In each case, revised benchmarks have been derived from input from the Technical Guidelines Development Committee and election officials.

Significant changes have been made to the accuracy requirements for optical scanners. Previous versions of the guidelines required optical scanners to conform to a low error rate requirement when reading marks that were made to manufacturer specifications. This requirement has been retained, but is now supplemented by a requirement to read a standard mark made with a #2 pencil with the same level of accuracy. A related requirement to ignore "extraneous perforations, smudges and folds," which under some interpretations is unattainable with existing technology, has been adjusted to recognize that there is no mechanical way of determining whether a given mark that appears within a voting target is extraneous or not. This ties into the well-known problem of voter intent. Marks appearing outside of voting targets, on the other hand, are always extraneous—at least as far as standard behavior is concerned. Systems that support detection of circled voting targets and other marks that jurisdictions may consider to be valid votes must also support a baseline, standard mode of operation in which such marks are ignored.

Requirements and discussion on the handling of marginal marks have been added. See Part 1: 7.7.5.1 "Marginal marks".

Requirements on the content of vote data reports, which appeared in several places and in different ways in previous versions of the guidelines, have been unified, harmonized, and clarified. Required contexts for reporting have been specified, and the concepts cast ballot, read ballot and counted ballot have been clearly distinguished. The quantities to be included in vote data reports have been formally defined using a logic model.

Other changes include

  • Made compatible with early voting.
  • Clarified that the redundant records stored by DREs are for recoverability purposes, and not to be confused with independent voter-verifiable records as specified in Part 1: 4.4 "Independent Voter-Verifiable Records".
  • Clarified and generalized the prohibition on counter overflow.
  • Specified that voting systems should flag any discrepancies in vote data reports that are detectable by the system.
  • Added "should" requirements for reporting the count of blank ballots and for combined precinct reporting.
  • Separated election administration concerns from product requirements.
  • Replaced the term ballot format, which was inherited from [GPO90], with the term used in modern practice, ballot style.

3 Comments

Comment by Brian V. Jarvis (Local Election Official)

This will likely be covered in more detail later in the document, however, the phrase "flag any discrepancies" will have to be more specifically defined as to what the requirement is to satisfy "flagging." Also, I would expect (hope?) that all voting system discrepancies will be flagged and that there will be a defined (minimum) set of discrepancies that all voting systems would be required to detect in order to be certified.

Comment by ted selker (Academic)

Part 1, Chapter 1, page 4, section 1.1.6, paragraph 2 These devices' combination of a DRE-like interface Should be changed to: These devices offer separate feedback to users that is distinct from vote counting. They give a combination of DRE-like interface… Part 1, Chapter 1, page 4, section 1.1.6, paragraph 4 With a #2 pencil Should change to reflect the reality: with a pencil, blue or black pen, or dark felt pen dauber Part 1, Chapter 1, 1.1.6, paragraph 4 "A related requirement to ignore extraneous perforation, smudges and folds which under some interpretations is unattainable with existing technology" should change to reflect the fact that, internationally, this technology has been used for some time: "A related requirement to ignore extraneous perforation, smudges and folds which is only possible with scanning, optical character recognition-type scanners." Part 1, Chapter 1, section 1.1.6, paragraph 4 Cast ballot, read ballot, counted ballot Should be added: and reported ballot

Comment by Cem Kaner (Academic)

In the new "Core Requirements" for voting equipment, members of the IEEE SCC38 Voting Standards committee favored adding the notion of complete observability. Operationalized, this means that every bit of storage in the voting system should be readable and examinable by a tester or other inspector (e.g., auditor or forensic analyst). .......... (Affiliation Note: IEEE representative to TGDC)

1.1.7 Coding conventions

Volume 1, Section 5.2 and Volume 2, Section 5.4 of [VVSG2005] define coding conventions and a source code review to be conducted by test labs. That material has been substantially revised in these Guidelines.

[VVSG2005] Volume 1, Section 5.2.6 specifies that manufacturers be permitted to use current best practices in lieu of the coding conventions defined in the VVSG. However, the coding conventions in [VVSG2005] are not aligned with the modern state of the practice, and if followed, could do more harm than good. The misalignments are (1) that the conventions, some of which were carried over from [GPO90], are out of date, and (2) that the conventions, being limited by the requirement to remain language-neutral, are variously incomplete and/or inappropriate in the context of different programming languages with their different idioms and practices. The vast majority of coding conventions used in practice are tailored to specific programming languages.

In these Guidelines, the few coding conventions that have significant impact on integrity and transparency and that generalize relatively well to different programming languages have been retained, expanded, and made mandatory, while the many coding conventions that are language-sensitive and stylistic in nature, and are made redundant by more recent, publicly available coding conventions, have been removed in favor of the published conventions. Meanwhile, the evaluation of logical correctness that was underspecified in [VVSG2005] has been greatly enhanced (see Part 1: 6.4.1 "Software engineering practices").

Prominent among the requirements addressing logical transparency is the requirement to use high-level control constructs and to refrain from using the low-level arbitrary branch (a.k.a. goto). As is reflected in Part 1: Table 6-4 , most high-level concepts for control flow were established by the time the first edition of the guidelines was published and are supported by all of the programming languages that were examined as probable candidates for voting system use as of this iteration. However, two additional concepts have been slower to gain universal support.

1 Comment

Comment by Jason Frisvold (None)

Coding standards aside, there are no provisions to open the code to general audits by the public. As can be seen from high profile projects such as Linux, SSH, and more, public audits can and do result in extremely secure code. At this point, any such code developed by a manufacturer is not subject to audit and may be susceptible to unknown attack.

1.1.8 Applicability to COTS and borderline COTS products

To clarify the treatment of components that are neither manufacturer-developed nor unmodified COTS and to allow different levels of scrutiny to be applied depending on the sensitivity of the components being reviewed, new terminology has been introduced: application logic, border logic, configuration data, core logic, COTS (revised definition), hardwired logic, and third-party logic. Using this terminology, requirements have been scoped more precisely than they were in previous iterations of the Guidelines.

The new terminology obviates the software vs. firmware distinction that in practice has sometimes caused confusion. The requirements applying to application logic are not relaxed in any way if that logic is realized in firmware or hardwired logic instead of software. Consequently, the use of hardwired logic in an application logic capacity is all but prohibited, as it is unlikely to meet requirements such as Requirement Part 1: 6.4.1.2-A. It is expected that hardwired logic will be limited to COTS and border logic.

By requiring "many different applications," the definition of COTS deliberately prevents any application logic from receiving a COTS designation.

Details regarding the testing implications of these revisions are provided in Part 3: 1.1.2 "Applicability to COTS and borderline COTS products".

1 Comment

Comment by E Smith/M Faulk (Academic)

Does the prohibited use of hardwired logic affect the use of functions such as the Open Polls switch and the activate button, both commonly found on DREs?

1.1.9 Reference models

Part 1: 8.1 "Process Model (informative)" provides an informative model of the entire voting process.

Part 1: 8.2 "Vote-Capture Device State Model (informative)" provides an informative state model for vote-capture devices to clarify the definitions of voting session and active period, particularly for the case of early voting.

Part 1: 8.3 "Logic Model (normative)" provides normative terms and constraints for use in evaluating the correctness of voting system logic. Part 3: 4.6 "Logic Verification" describes the verification procedure.

0 Comments

No Comments

1.1.10 Deletions

Requirements regarding the system's handling of unofficial data and reports have been deleted or converted to procedural requirements because the distinction between unofficial and official data is often outside the scope of the voting system. It is now assumed that any vote data present on a voting system and any reports that it generates are potentially official. Requirements on the reconciliation of provisional ballots and other activities involved in the creation of official data are unaffected by this change.

As discussed, prescriptive coding conventions not directly related to integrity and transparency have been deleted in favor of published, credible conventions.

Requirements on system and device availability have been deleted because they did not reflect the logistical overhead of repairing equipment on election day and because it is generally impossible to place precinct equipment back into service after it has been repaired on election day without raising concerns about possible tampering. Instead, Requirement Part 1: 6.3.1 "Reliability" has been tightened to discourage equipment from failing in the first place.

A requirement to designate one set of redundant electronic CVRs in a DRE as the "primary" set has been deleted because it prejudices the result of an audit.

Requirements that were redundant with the definitions of device classes (e.g., [VSS2002] I.2.4.3.2.1.b, all paper-based systems shall allow the voter to punch or mark the ballot to register a vote) have been deleted.

Requirements predicated on state law, local practices, software developed by the voting jurisdiction, and other variables that are indeterminate and untestable in the federal certification process have been deleted.

Requirements that were stated in terms of vague generalities, such as "appropriate" or "intended" options or behavior, for which no precise replacement could be determined and to which no testing value could be ascribed, have been deleted.

Vacuous requirements, such as "Be of any size and shape consistent with its intended use," have been deleted.

Redundant requirements, such as "Comply with the requirements of Section Y" when Section Y is already known to be applicable, have been deleted.

Informative text that was overtaken by changes in the requirements or the structure of the Guidelines has been deleted.

Definitions and requirements pertaining to punchcard technology have been deleted.

2 Comments

Comment by Brian V. Jarvis (Local Election Official)

Recommend making it a requirement that any vote data present on a voting system and any reports that it generates are official (and not "potentially" official). Also, regarding reliability and the concern about possible tampering. There is the possibility of voting precincts losing power (or a voting machine's plug being inadvertantly pulled). As I understand the voting machines we currently use (Diebold), after re-booting, the machine will return to the mode it was in at the time of power disruption. Is this covered in the requirements and procedures? Or would this scenario come under the category of "concern about possible tampering?"

Comment by ted selker (Academic)

Part 1, Chapter 1, section 1.1.10, paragraph 3 "Because it is generally impossible to place precinct equipment back into service after it has been repaired on Election Day" This is a great goal. However, we are currently dealing with jamming folded ballots, full ballot boxes, jamming VVPATS, VVPATS out of paper, DREs that need recalibration after a person jabs it repeatedly with a sharp stylus. Part 1, Chapter 1, section 1.1.10, paragraph 3 "Definitions and requirements pertaining to punchcard technology have been deleted" Punchcard technology that includes ballot information has had similar performance to optical scan. This document could show people how to reuse that technology for the interim.

1.1.11 Supplemental Guidance

Throughout Part 1 are informative subsections titled "Procedures required for correct system functioning." The requirements in these subsections provide context for what the functional requirements specify or, more often, for what they omit. These requirements do not pertain to the voting system and are not tested by an accredited test lab.

1 Comment

Comment by Matthew Sugarman (Academic)

How can elections be secure when the code within the voting machines is deemed prioritized by for- profit organizations? This is a national security issue for which a bi-partisan citizens panel made up of computer experts should be given the computer codes for these machines to see if that code was made with back door access, vote switching or other hacker friendly programs and permissions built in. Entire organizations of computer programming experts have rated the security of Black Box voting machines with a grade of F. Based on the degree of implausibility created by the discrepancy between vote counts and election polls entire organizations of statisticians reported the extremely high probability that election fraud is not only evident but is likely to have decided the winner of the last two presidential elections. Anyone who looks into this issue with any seriousness is soon convinced that American elections are probably fixed. Only the mandatory implementation of paper trails backed up and mandatory random audits of all federal and state elections can hope to restore a democratic voting process to the USA.