Chapter 4: Using This Document
As noted, this document is intended primarily for voting system manufacturers and test lab personnel. However, the language used throughout has been improved and made more understandable for most audiences. This section contains a brief overview of how to read the document and best understand its features and requirements.
Comment by Tom Poe (General Public)
Asking the public for input on guidelines for proprietary voting systems is insulting, offensive, and appalling. Proprietary voting systems, by definition, eliminate the voters' right to vote, and prohibit public scrutiny. No amount of garbage formatted in a so-called guidelines document will overcome the bare facts. You folks are despicable. Please publish my comment without editing. Tom Poe, Charles City, Iowa
Comment by conceredcitizen (Federal Agency)
The voting machines should be more secure and add paper trails. They should be running open source code to allow for better public oversight and avoid corporate tampering
Comment by Carol Fryer (Voter)
Voting machine manufacturers? Is the document a sugestion or a requirement? Are there paper trails for vote recounts. If not it stinks. And once a seal is broken and its not clear who did it, that vote should be redone. Vote fraud from parties and from noncitizens or even dead people is a major concern for Americans. I wont just take your word for it anymore that its tamper proof. Its been proven to be the opposite and its known widely now. Now will you ignore us again????
4.1 Requirements Language and Structure
The first place to start in understanding the VVSG is to understand how language is used. The language is divided into two categories: normative, i.e., the requirements language itself, and informative. Informative parts of this document include discussion, examples, extended explanations, and other matter that is necessary for proper understanding of the requirements and conformance to them. Informative text may serve to clarify requirements, but it is not otherwise applicable.
Normative language is specifically for requirements. The following keywords are used within requirements text to indicate the conformance aspects of the requirement:
- Shall indicates a mandatory requirement to do something;
- Is prohibited indicates a mandatory requirement not to do something;
- Should, Is encouraged indicate an optional recommended action;
- May indicates an optional, permissible action.
The requirements are structured specifically to make them clear and precise. Requirements may have subrequirements, usually used when the main requirement needs further definition of its implications. A typical requirement and subrequirement (taken from Part 1: 3.3.3) are as follows:
Audio Features and characteristics
Voting stations that provide audio presentation of the ballot SHALL do so in a usable way, as detailed in the following subrequirements.
Applies To: VEBD-A
Test Reference: Part 3: 3.2 "Functional Testing"
These requirements apply to all voting system audio output, not just to the ATI of an accessible voting station.
The ATI SHALL provide its audio signal through an industry standard connector for private listening using a 3.5mm stereo headphone jack to allow voters to use their own audio assistive devices.
Requirements and their subrequirements are designated by the "" and "" characters, respectively. Requirements are numbered according to the section of the VVSG they appear in; the titles serve as a shorthand description. The actual text of a requirement appears directly below the requirement in blue. Requirements have the following fields:
- Applies to: indicates which voting system or device class the requirement applies to (see the discussion of classes in the following section);
- Test Reference: what type of testing must be used for testing whether the requirement is met; these point to appropriate sections in Part 3: Testing Requirements;
- DISCUSSION: optional: informative supporting information for the requirement;
- Reference: optional: the source for the requirement; many requirements are new.
Each usage of a word or term with special meaning in the VVSG, such as voting stations, ATI, or accessible voting station, is linked to its definition in Appendix A: Definitions of Words with Special Meanings.
Comment by E Smith/J Homewood (Manufacturer)
In many places it is unclear what the roll of the [Discussion] is. Guidance provided in this section is incomplete. Is this to be taken to be clarification or recommendation on how to implement the requirement. Is the discussion an actual part of the requirement? As an example, in Part 3 section 5.2.3-D.2 In the requirement section is says that at least 50 device must be used, 10,000 ballots must be used and no fewer than 400 ballots per device. Then in the discussion it adds that is must be 400 distinct ballots per device but this is not part of the requirement. The discussion further states that the number of ballots per device should be at least 10 times the number of ballots to be expected … to be counted on that device per election but ion no case less than 5000 ballots. A minimum of 5000 ballots per device on 50 devices seems much different than the test described in the requirement.
4.2 The Conformance Clause and Classes
With some background on requirements structure and language, readers may wish to read Part 1: Chapter 2: Conformance Clause for the discussion on classes and to interpret requirements language. The purpose of classes is to categorize requirements into related groups of functionality that apply to different types of voting systems and devices. Understanding how classes work is the key for understanding requirements and their implications.
The conformance clause chapter is highly technical in nature, thus the following is a summary of its discussion on classes:
There are two types of classes:
- Voting system classes: each class pertains to a voting system that supports a specific voting variation, e.g., primary elections, open primaries, straight party voting, etc.
- Voting device classes: each class pertains to a voting device, ranging from higher-level classes such as vote-capture device to lower-level, specific classes that describe specific devices such as VVPAT or PCOS.
Most requirements have an Applies to: field that contains the name of a class or several classes that the requirement essentially applies to, e.g., a requirement dealing with cryptography with Applies to: Vote-capture device, means that all vote-capture devices must satisfy the requirement. The vast majority of requirements in the VVSG apply to device classes, i.e., types of voting devices.
4.2.1 Inheritance in device classes
As stated previously, classes may subsume (or incorporate) other subclasses below them in the hierarchy. For example, vote-capture device subsumes IVVR vote-capture device, which subsumes other subclasses beneath it. The subsuming class is called the superclass, while the subsumed classes are called subclasses.
Subclasses inherit the requirements of their superclasses, e.g., in the class diagram in Figure 4-1, the lines that connect the classes show that EPB inherits all requirements that apply to EBM, which inherits all requirements that apply to IVVR vote-capture device, which inherits all requirements that apply to vote-capture device. A subclass may add new requirements, e.g., IVVR vote-capture device contains requirements in addition to those that apply to vote-capture device and so forth. However, a subclass is not allowed to relax or remove requirements inherited from a superclass; everything that applies to vote-capture device, for example, applies also to every subclass of vote-capture device.
4.2.2 Instantiated device classes
The lines that connect the classes in class diagrams are there to show the hierarchical inheritance relationships among the classes. However, there are voting devices that may be special-purpose and that are not represented by a specific device class or lines. These sorts of voting devices can belong to (or inherit the requirements of) multiple classes at the same time. For example, the complete device classes diagram in Part 1: Figure 2-1 does not show a device class for an accessible VVPAT, yet it is possible to have such a device. The way in which this is identified is actually in the requirements that would apply to such a device. For example, a requirement that applies to a VVPAT when it is also an Acc-VS has an Applies to: field as follows:
Applies To: Acc-VS ^ VVPAT
The wedge ("Λ") character signifies that the requirement applies to an accessible VVPAT and that all requirements that apply to Acc-VS and that apply to VVPAT also apply to the accessible VVPAT. Pictorially, this can be shown as follows in Figure 4-2; the dotted lines indicate that the accessible VVPAT is actually a device class that is instantiated when a requirement applies to both Acc-VS and VVPAT.
Figure 4-2 An instantiated accessible VVPAT device class
Comment by Diane Gray (Voting System Test Laboratory)
This paragraph could be more clearly written.
4.2.3 General device class usage in requirements
Classes and how to use them are not immediately intuitive, yet they greatly assist in making requirements specific to devices and allow new devices to be instantiated or created (via the Innovation Class) following orderly rules of device class inheritance. Table 4-1 shows some common examples of how device classes are used in requirements.
Table 4-1 Examples for Applies to: fields
Applies to all Vote-capture devices.
DRE, Activation device
Applies to all DREs and all Activation devices.
DRE ^ Activation device
Applies only to a DRE that is also an Activation device.
Applies to all voting devices (voting device is the superclass of all voting device classes).
Applies to the voting system as a whole; might be satisfied by a single device or by multiple devices working together.
Voting device is the highest-level device class, i.e., superclass, of all voting device classes, therefore a requirement that applies to voting device applies to all voting devices. For example, the requirement
Storage between elections
Voting devices designated for storage between elections SHALL continue to meet all applicable requirements after storage between elections.
Applies To: Voting device
applies to Voting device because every device designated for storage between elections must meet the requirement. On the other hand, a requirement that applies to Voting system could apply to any of the voting devices comprising the voting system; it does not matter as long as somehow the requirement is satisfied. For example, the requirement
Comment by Max (None)
I'm just a voter, but it concerns me that (as I understand) there is no paper trail or hard copy. There needs to be an irrefutable back up system to avoid these ridiculous chad-counting stories from previous elections.
The voting system SHALL prevent others from determining the contents of a ballot.
Applies To: Voting System
applies to Voting system because the voting system, as a whole, must protect ballot secrecy. Not every device in the voting system by itself may be able to protect ballot secrecy, but as a whole the voting system must do this. For example, the privacy of a sole voter who uses an alternative language on an accessible voting station can be protected if additional voters are directed to use the same voting station.
4.3 Navigating Through Requirements
There is a requirement listing provided immediately after the table of contents in this document. Readers can navigate through the document using this list and quickly identify requirements in various sections.
As noted previously, requirements that use words with special meanings are linked to their definitions in Appendix A. References in requirements and informative text are linked to Appendix B.
Part 1: 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. It may also be of use to election officials in setting requirements for voting systems in requests for proposals. It contains 8 chapters, organized as follows:
- Chapter 1: Introduction;
- 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;
- Chapters 6-7: Core requirements and requirements arranged by voting activity; and
- Chapter 8: Reference models - process model, vote-capture device state model, and logic model.
Part 2: Documentation Requirements, contains requirements applying to the Technical Data Package, the Voting Equipment User Documentation, the Test Plan, the Test Report, the Public Information Package, and the data for repositories. It is intended primarily for use by manufacturers, test labs, and software repositories. It contains 7 chapters, organized as follows:
- Chapter 1: Introduction;
- Chapter 2: Manufacturer requirements for quality assurance and configuration management documentation provided to test labs;
- Chapter 3: Manufacturer requirements for documentation to be included in the technical data package provided to test labs;
- Chapter 4: Manufacturer requirements for documentation provided to users, i.e., customers;
- Chapter 5: Requirements for the voting system test plan by the test lab;
- Chapter 6: Requirements for the test report by the test lab; and
- Chapter 7: Requirements for test results-related documentation to be made available to the public.
Lastly, Part 3: Testing Requirements contains requirements applying to the conformity assessment to be conducted by test labs. It is intended primarily for use by test labs. Requirements in Part 1 and Part 2 reference sections in Part 3 to indicate the general methods for how the requirements are to be tested (but not the tests themselves). Part 3 contains 5 chapters, organized as follows:
- Chapter 1: Introduction;
- Chapter 2: Overview of the conformity assessment process and related requirements;
- Chapter 3: Overview of general testing approaches;
- Chapter 4: Requirements for documentation and design reviews; and
- Chapter 5: Requirements for different methods for testing.
Comment by IT professional (General Public)
Closed-source computer programs counting votes is comparable to outsourcing the ballot boxes to a foriegn country. Votes should be tallied by blue-haired old ladies who can be closely watched - not computer code designed by a private company. If anything deserves an exclusion from the Trade Secrets Act, voting machine code is a good candidate.
Comment by Ellen Cerda (None)
All voting machines must have voter verifiable paper records of everyone who votes. All elections must have sufficient mandatory manual audits performed afterwards to ensure that election outcomes are correct. Funds must be made available to ensure the first two stated requirements as well as for upgrading voting systems. Fund only fully auditable voting systems. States must submit timely reports of detailed election data that can be used to measure voter disenfranchisement & voter service levels. Provide enforceable penalties whenever an election jurisdiction fails in transparency, auditing, or reporting obligations. Election records must be made easily accessible to the public. Jurisdictions must be required to allow citizens to observe all aspects of elections. Require public disclosure of all voting equipment. Require election officials to make publicly availabe all election data. Prohibit practices that disenfranchise voters.
Comment by Alexander Censor, M.S. (Academic)
The code for these systems needs to be made public -- open source -- to reduce even the APPEARANCE of the possibility of criminally modified or defective code. The need for absolute confidence on the part of the voting public of absense of security risks and errors in the code, which can only be totally achieved with open code, trumps the manufacturer's needs to protect their proprietary code. If some manufacturers are unwilling to do that let them drop out of the market and others who are willing to address this need and market without guarentees of secrecy of their code.
Comment by Joan Dixon (Voter)
With all the evidence that the computerized paperless voting and vote tallying is vulnerable to hacking, I cannot support use of this system anywhere anytime. The old tried and true way of hand counting vote by vote was good enough for our grandparents and I think it is good enough for us. Election results should be posted right where they are counted too. What's so difficult about hiring a crew to count the votes and providing them some kind of guard for the facility where they are counting? Putting it back into the hands of the people makes it harder to be stolen. Putting the votes on a romote hackable system leaves us totally outright vulnerable to election theft. STOP ELECTION THEFT!!!!!! Thank-you! Concerned Voting Citizen