Chapter 7: Requirements by Voting Activity
7.1 Election Programming
Election programming is the process by which central election officials use election databases and manufacturer system software to logically define the voter choices associated with the contents of the ballots.
There are significant variations among the election laws of the 50 states with respect to permissible ballot contents, voting options, and the associated ballot counting logic.
4 Comments
Comment by Harry VanSickle (State Election Official)
We have a positive impression of the requirements in this chapter. The requirements for election programming and ballot preparation are fairly inclusive. It appears that these standards will guarantee that local election officials have more control over the formatting and definition of ballots.
Comment by E Smith/P Terwilliger (Manufacturer)
7.1-C. Why is this a requirement? Small jurisdictions may only have a single election district? Perhaps this should be a voting variation? 7.1-D.2. "All systems" is not defined. 7.1-D.3. How is this requirement, for "all systems", different than the cross-party endorsement voting variation? 7.1-D.3. "all systems" is not defined. 7.1-E. "Exactly" is untestable. 7.1-F. "Exactly" is untestable. 7.1-G. "Verify" and "correct" are untestable. How is this different from "exactlY" in 7.1-E and 7.1-F? Is this less stringent than being "exact"? 7.1-H. "The system" is not defined. 7.2-A.1. "political subdivision" is not defined. How does it differ from "election district", "ballot style" and "reporting context"? 7.2-A.4. "perceives" is untestable. 7.2-A.4. To apply this requirement to each contest is inappropriate and probably in conflict with State election laws; the ordering and presentation of contests is usually fixed. 7.2-A.5. Why is this single requirement specifying "central election officials"? Why not the rest? 7.2-A.8. How is a "ballot configuration" different from a "ballot style"? 7.2-D. "precent" and "unauthorized" are untestable. 7.2.1. This section mystifies. 7.3.1-A. "all systems" is not defined. 7.3.1-A. "properly", "correct", "verify" and "segregate" are not testable. 7.3.1-C. Why is this restricted to 'central election officials"? 7.3.1-D. How does the "programmed device" ensure that the notification (ie error indication) it generates actually notifies an "election official"? The best any programmed device can do is provide a clear indication of its status, not who is viewing such. 7.3.1-E. How does the "programmed device" ensure that the notification (ie error indication) it generates actually notifies an "election official"? The best any programmed device can do is provide a clear indication of its status, not who is viewing such. 7.3.1-F. "Programmed tabulators" is undefined. Is there such a thing as an unprogrammed tabulator? 7.3.1-F. Shouldn't this requirement be specific to paper-based tabulators? 7.3.1-I. As the discussion indicates, this requirement is borderline silly. (The discussion crosses that border.) Suggest restricting it to EBMs. 7.3.1-J. This contradicts 7.3.1-A(d). Segregated test data introduces changes beyond "status changes". 7.3.1-J.1. This contradicts 7.3.1-A(d). Is test data to be isolated (which preserves it for post election audit) or expunged (so that no record of the test is retained)? 7.3.1-J.1. Why is this specific to the undefined "programmed tabulator" when the parent requirement applies to no device type? 7.4-A. This should be applied to vote capture devices and tabulators, not programmed devices. 7.4-B. This should be applied to vote capture devices and tabulators, not programmed devices. 7.4-C. How is a tabulator different from the undefined "ballot counting device". 7.4-D. How is a tabulator different from the undefined "ballot counting device". 7.4-E. How is a function determined to be "designated"? How is this tested? 7.4-E.1. What is a "data code"? A "recognition capability"? Why are locks/keys not permitted? 7.5.1. The intro implies that "issuance of voting credentials" and "ballot activation" are used in different ways elsewhere. Why would this be? This section also provides a duplicate definition for "voting credentials" which is inappropriate. Further, the definition given here for "voting credentials" differs from Appendix A. The definition here includes options such as a magnified ballot. Such options potentially violate the voter's privacy in the same way that specifying the voter's preferred language would. 7.5.1. What is "fair game for OEVT"? 7.5.1.1-B. "MAY" appears to change to "SHALL" in the discussion. 7.5.1.2-A.1. Needs to be changed to "SHALL". 7.5.1.2-A.2. Since 7.5.1 suggests that an ePollbook is a form of activation device, this requirement cannot be met. Also, the voter does not use the voting system, but a vote-capture device. 7.5.1.2-A.3. "SSN" is not defined. 7.5.1.3-A. This requirement is too limiting. For example, a DRE can place a "voted" indication along with other information (such as the DRE serial number and timestamp) to allow the pollworker to determine if a vote was successfully cast (versus perhaps a voter claiming the token doesn't work and trying obtain a replacement after actually voting sucessfully). 7.5.1.3-A.1. This section is moot; unless the vendor is required to build a custom device, the capacity of devices such as smart cards is constrained by market forces. COTS tokens with "several bytes or less" capacity do not exist. 7.5.1.3-A.2. The state information proposed in the discussion violates 7.5.1.3-A. 7.5.1.3-A.3. Even as a "SHOULD", this is an unrealistic suggestion, and is incompatible with the suggestion in 7.5.1.3-A.2 of rewriting the token's state during a voting session. 7.5.1.4-A.2. "so authorized" is undefined and untestable. 7.5.1.4-B. "free of vulnerabilities" is untestable. 7.5.2-A. "ballot presented to the voter" is a new term. "link to" is not defined. "advertising or commercial logos" is not defined. 7.5.3-A. This would seem to be redundant and should be deleted. 7.5.3-A.7. The discussion, which permits declaring two aliases (why not three or more?) to be the same, implies a manual process. Such manual process makes a voting system not part of the write-in class. 7.5.3-A.9. This is inconsistent with state laws governing rotation. It applies an Ivory-Tower view to a process that is per state laws deterministic and decidedly non-equal. 7.5.3-A.16. Please detail how this requirement is not equivalent to "manual intervention", which disqualifies a voting system from claiming support of the provisional voting class. 7.5.3-A.17. "Categorize" is untestable. 7.5.3-A.18. "Flagged" and "separated" are not defined and are untestable. 7.5.4-A. "precisely" is vague and untestable. 7.5.4-A.1. "consistent" is vague and untestable. "Feedback" is not defined. 7.5.4-B. The definition for verify in parens here needs to be moved to Appendix A. "correct is vague and untestable. 7.5.4-B. Why is this only a requirement for DRE? Why not all tabulators? 7.5.4-C. "All systems" is not defined. 7.5.4-C.1. "Make it possible" is a new and undefined term. "All systems" is undefined. 7.5.4-C.2. "Systems" is undefined. "Secure receptacles" is undefined. 7.5.4-D. Why is this specific to DRE? "Prevent" is vague and untestable. "After" needs definition: At some point post-election, ALL vote data is destroyed. 7.5.5-A. How is a "ballot image", as used in other sections, different from a CVR? "retain" is untestable - for what period does this apply? "machine-countable" is undefined. 7.5.6-A. If the counter is defined as 32 bits, it is absurd to claim this is not adequate, as such a counter is an order of magnitude beyond the population of the entire US. 7.5.6-A versus 7.5.6-A.1. How does "notify the user or operator" contrast with ""emit appropriate warnings"? 7.5.6-A. "user" is not a defined voting system role. "operator" is not a defined voting system role. 7.5.7. "Early voting" is not mentioned elsewhere in the VVSG. "suspended state" is not explained. 7.6. Many subsections use the "programmed vote capture device" term, which either is redundant with "vote capture device" or needs a definition in Appendix A. 7.6-A. Why is this requirement limited to DRE? How can ANY vote capture device prevent such access (ie if power is removed)? THe best ANY such device can do is provide indications that access has occurred. 7.6-B. What is a "designated function"? 7.6-B.2. Why is this only a DRE requirement? PCOS and BMDs must also have the capability to close polls an prevent further ballot marking/casting. 7.6-B.3. Why is this not also a requirement for opening polls? What is "normal"? 7.6-B.4. What does it mean for a "poll closing sequence" to have been "activated"? This phrasing is confusing with respect to "ballot activation". 7.6-B.4 and 7.6-B.5. How is "activating" polls closing differ from "completing" polls closing? 7.6-C. What is a "designated function"? 7.7. This entire section is very problematic as it makes unwarranted assumptions about the boundary between a vote capture device, whether DRE or PCOS or even central count, and a tabulator. There is no reason that a vote capture device must also tabulate at any level; this distinction needs to be made clear here and in Appendix A. 7.7.1-B. Not also a paper based vote capture device such as PCOS? 7.7.2-A.1. ALthough this section is aligned with HAVA in allowing overvotes, other sections of the VVSG conflict. 7.7.2-A.9. How is "gathering and recording" a tabulator function and not a vote capture device one? 7.7.2-A.17. There is only ever one round of voting. Ranked order voting can have multiple rounds of tabulation/resolution of ballots. 7.7.2.5. Why not require the documentation to describe the approach, as in 7.7.2.3? 7.7.3-A. Section (c) introduces an "election official designee". This appears to be prohibited by earlier discussions of security, roles, etc. Please define this designee and why it is special to this section. 7.7.3-A.1. "this action" is not defined. If it is referring to 7.7.3-A, then the requirement is redundant. 7.7.3-C. There is no way for the machine to know that an actual election official is receiving any alert. 7.7.3-C. This presumes that ALL ballots being tabulated are from the EBM. If the EBM is only being used for handicap access, this special behavior would constitute discrimination. 7.7.4-A. "the operator" is not a defined role. 7.7.5-A. "ignore" is not the same as "not record as votes". 7.7.5-D. "as dark as can practically be made" is untestable. 7.7.5-F. The discussion refers to 2006 technology. Since multiple requirements in the VVSG render ALL existing voting technology obsolete, why is this important in this single section? The requirement must be changed to SHALL. 7.7.5-G. The discussion refers to 2006 technology. Since multiple requirements in the VVSG render ALL existing voting technology obsolete, why is this important in this single section? The requirement must be changed to SHALL. 7.7.6-A. What is a "Precinct EMS"? The requirement sounds more fit for a tabulator; there is no such thing as a "precinct EMS" assuming the definition of EMS in Appendix A, where the EMS defines the ballot. 7.7.6-A.1. Why is this only a DRE requirement? ANY vote-capture device should be subject to this requirement. 7.7.7 This section needs not be in a VVSG. 7.8.1-C. The discussion relaxes the requirement. Why not change the requirement to include the caveat in the discussion? 7.8.2-A. "All systems" is not defined. Suggest "programmable devices". 7.8.2-B. How is "obtain" different from "generate" or "produce"? 7.8.2-B.b. "voting patterns" is undefined. 7.8.2-B.c. "multiple districting" is undefined. 7.8.2-B.d. "peculiar" is undefined. 7.8.2-C. Does this include programmed devices that are only used as a peripheral to a vote-capture device (VVPAT, for instance)? Suggest "voting devices". 7.8.2-C. How is "obtain" different from "generate" or "produce"? 7.8.2-E.d. What is an "active contest choice register"? Is there such a thing as an "inactive contest choice register"? How would one be at "all storage locations"? 7.8.2-F.d. What is an "active contest choice register"? Is there such a thing as an "inactive contest choice register"? How would one be at "all storage locations"? 7.8.2-G. "systems" is undefined. 7.8.3.1-A. "devices" is undefined. 7.8.3.1-A.b. What is an "election, office or issue label"? 7.8.3.1-B. "systems" is undefined. 7.8.3.1-C. "systems" is undefined. 7.8.3.1-D. "completely consistent" is untestable. 7.8.3.1-D.1 and 7.8.3.1-D.2. It is contradictory and rather bizarre to include requirements that only apply if the voting system does not meet a higher-level requirement. 7.8.3.1-D.1. "the system" is undefined. "flagged" is undefined. 7.8.3.1-D.1. The last sentence of the discussion is irrelevant. 7.8.3.1-F. "official close of polls" is outside the scope of the voting system. If a properly authorized official closes polls, there is no way for the device or voting system to know if polls are "officially" closed. Recall perhaps the emergency extension of polling hours in Florida in November 2004. Even if each device had an accurate clock and was programmed with the "official" close time, that time changed when it was too late to update any device. 7.8.3.2. Subsections are using "systems", not "voting systems". 7.8.3.2. Some subsections call for reports in each reporting context, others do not. 7.8.3.3. Subsections are using "systems", not "voting systems". 7.8.3.3. Some subsections call for reports in each reporting context, others do not. 7.8.4. How is a report deemed "official" or "unofficial"? 7.8.4. "Current best practices" is not explained or referenced.
Comment by E Smith/P Terwilliger (Manufacturer)
7.1. The requirements listed here, 7.1-A through 7.1-H use an incomprehensible hodgepodge of: "SHALL provide for" "SHALL be capable of" "SHALL enable" "SHALL allow" "SHALL support" Are these identical terms? If not, please provide exact definitions and highlight the differences. (Note that later sections exhibit the same inconsistent hodgepodge.)
Comment by m. edmund howse (Academic)
Any voting system that does not maintain the highest degree possible of voting results count and recount integrity cannot be considered one of a democracy. Any state that does not conform to a standard of the highest integrity should not be allowed to participate in a democratic election as they are actually a communist or dictator state and any election results which are counted in this manner are either tainted or pre-established and consequently meaningless as well as not the will of the people.
7.1-A EMS, ballot definition
The EMS SHALL provide for the logical definition of the ballot, including the definition of the number of allowable votes for each contest.
1 Comment
Comment by Verified Voting Foundation (Advocacy Group)
Part 1, Section 6.6 notes that "Common formats for specifying election programming data such as ballot definition files promotes greater accuracy and reduces duplication" as well as reducing barriers to interoperability. Yet the section that deals specifically with ballot definition (7.1), does not mention the need for a common ballot definition language. Requiring EML (which is a dialect and extension of XML) for ballot definition could go a long way toward improving ballot design in the United States, where poor ballot design has been the source of a number of notorious voting problems (e.g., the "butterfly ballot" in 2000). One of the primary strengths of XML is for formatting documents and text. In the case of ballots, a single underlying XML document could be used to specify and generate paper ballots, sample ballots, touch-screen displays, etc. simply by using different XML Style Sheets. Because there are a large number of software programs that can render XML using style sheets, and because there are many people familiar with using different variants of XML, election officials would have a much broader base of people and resources to help with ballot preparation. And having a single underlying standard for ballot components would facilitate adoption of best practices for ballot design, definition, and implementation.
7.1-A.1 EMS, ballot definition details
The EMS SHALL be capable of collecting and maintaining
- Offices and their associated labels and instructions;
- Candidate names and their associated labels; and
- Ballot questions and their associated text.
1 Comment
Comment by Carl Hage (General Public)
The EMS must be able to maintain all names-- offices, jurisdictions, subdivisions, candidates, etc. in the correctly spelled, capitalized, and punctuated full legal form without abbreviations. When any data field requires a limitation in length or conversion to capital lettering, the EMS must produce a mapping table giving the correct name for each alteration. The EMS must not have any reasonable limit on name length. The EMS must be able to maintain a set of equivalent names, e.g. aliases, former names, or set of optional words in a name, e.g. in the name, "Loma Prieta Joint Union Elementary School District", the words "Joint", "Union", and "Elementary" are optional when matching the name. Note: Converting or comparing election information across systems is currently very difficult because names cannot be matched by computer-- mainly due to abbreviations, sometimes due to truncations. This inhibits the ability for independent organizations to validate electronic election data.
7.1-B EMS, political and administrative subdivisions
The EMS SHALL provide for the logical definition of political and administrative subdivisions, where the list of contest choices or contests varies between precincts.
7.1-C EMS, election districts
7.1-D EMS, voting variations
The EMS SHALL enable central election officials to define and identify contests, contest choices, candidates, and ballot questions using all voting variations indicated in the implementation statement.
In all systems, the EMS SHALL allow the definition of contests where the voter is allowed to choose at most one contest choice from a list of contest choices.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This is just a special case of the N of M variation which is already defined in 7.1-D.9. Proposed Change: Remove this requirement.
In all systems, the EMS SHALL allow the definition of contests where the voter is allowed to vote yes or no on a question.
7.1-D.3 EMS, indicate party affiliations and endorsements
In all systems, the EMS SHALL allow the definition of political parties and the indication of the affiliation and/or endorsements of each contest choice.
7.1-D.4 EMS, primary elections, party-specific and non-party-specific contests
EMSs of the primary elections device class SHALL support the definition of both party-specific and non-party-specific contests.
EMSs of the Write-ins device class SHALL support the definition of contests that include ballot positions for write-in opportunities.
EMSs of the Straight party voting device class SHALL be capable of defining the necessary straight party contest and associated metadata to support the gathering and recording of votes for the slate of contest choices endorsed by a given political party.
3 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
The use of "contest choice" is incorrect because it includes Y/N questions and non-partisan contests. Parties endorse positions on questions.
Comment by Carolyn Coggins (Voting System Test Laboratory)
Is the VVSG dictating a specific design for Straight Party to be handled as a contest? This is inconsistent with some current voting systems
Comment by Carolyn Coggins (Voting System Test Laboratory)
"Associate Metadata" is broad. Either define it or delete it.
7.1-D.7 EMS, cross-party endorsement
EMSs of the Cross-party endorsement device class SHALL be capable of defining the necessary straight party contest and associated metadata to support the gathering and recording of votes for the slate of contest choices endorsed by a given political party when a given contest choice is endorsed by two or more different political parties.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
Is the VVSG dictating that straight party voting must be supported if a voting system supports cross party endorsement?
7.1-D.8 EMS, split precincts, define precincts and election districts
EMSs of the Split precincts device class SHALL support the definition of election districts and precincts in such a way that a given polling place may serve two or more election districts.
EMSs of the N-of-M voting device class SHALL be capable of defining contests where the voter is allowed to choose up to a specified number of contest choices (N(r) > 1, per Part 1: 8.3 "Logic Model (normative)") from a list of contest choices.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
In this requirement, the explanation of N of M seems complex. Simpler terms can be used to define N of M. Proposed Change: Change the requirement to read as follows: EMSs of the N-of-M voting device class SHALL be capable of defining contests where the voter is allowed to choose N selections from M options.
EMSs of the Cumulative voting device class SHALL be capable of defining contests where the voter is allowed to allocate up to a specified number of votes (N(r) > 1, per Part 1:8.3 "Logic Model (normative)") over a list of contest choices, possibly giving more than one vote to a given contest choice.
EMSs of the Ranked order voting device class SHALL be capable of defining contests where the voter is allowed to rank contest choices in a contest in order of preference, as first choice, second choice, etc.
7.1-E Election definition accuracy
The EMS SHALL record the election contests, contest choices, issues, and political and administrative subdivisions exactly as defined by central election officials.
1 Comment
Comment by Carl Hage (General Public)
This is inadequate. The election definition must be recorded with full legal names, correctly spelled, capitalized, and punctuated without abbreviation-- independent of election officals. The EMS should support verification by the an official within each jurisdiction for names used on contests, and candidates should verify name and labels within the EMS. To support verification of names, the content must be made public and the solicitations made to each candidate and official within each jurisdiction to validate the public EMS content.
7.1-F Voting options accuracy
The EMS SHALL record the options for casting and recording votes exactly as defined by central election officials.
7.1-G EMS, confirm recording of election definition
The EMS SHALL verify (i.e., actively check and confirm) the correct recording of election definition data to the persistent storage of the device.
2 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
It would be a more effective document if all code review requirements like this were included in the code review section?
Comment by Gail Audette (Voting System Test Laboratory)
"Please define the pass/fail criteria and/or the test methodology for a static design review that will ""verify (i.e., actively check and confirm) the correct recording of election definition data to the persistent storage of the device"". "
7.1-H EMS, election definition distribution
The EMS SHALL provide for the generation of master and distributed copies of election definitions as needed to configure each voting device in the system.
7.2 Ballot Preparation, Formatting, and Production
7.2-A EMS, define ballot styles
The EMS SHALL be capable of automatically formatting ballots in accordance with the requirements for offices and contest choices qualified to be placed on the ballot for each political subdivision and election district.
7.2-A.2 EMS, include votable contests
The EMS SHALL provide for the inclusion in a given ballot style of any contest in which the voter would be entitled to vote.
7.2-A.3 EMS, exclude nonvotable contests
The EMS SHALL provide for the exclusion from a given ballot style of any contest in which the voter would be prohibited from voting because of place of residence or other such administrative or geographical criteria.
7.2-A.4 EMS, nonpartisan formatting
The EMS SHALL uniformly allocate space and fonts used for each office, contest choice, and contest such that the voter perceives no contest choice to be preferred to any other.
7.2-A.5 EMS, jurisdiction-dependent content
The EMS SHALL enable central election officials to add jurisdiction-dependent text, line art, logos and images to ballot styles.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
This requirement has been changed so that voting systems are required to accommodate logos, images and line art in contest choice displays? These have been previously optional. This is also grouped within contests. Why would there be line art, logos or images in a contest? (Organizationally 7.2 A seems to be all over the map)
7.2-A.6 EMS, primary elections, associate configurations with parties
EMSs of the primary elections device class SHALL support the association of different ballot configurations with different political parties.
EMSs of the Ballot rotation device class SHALL support the production of rotated ballots and/or the activation of ballot rotation functions in vote-capture devices through the inclusion of relevant metadata in distributed election definitions and ballot styles.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
What precision has been added? Provide clarification of the specific methods of rotation. Specify the types of rotation .... by precinct? By machine? By other methods? Should the EMS let you define if only candidates rotate or should questions?
7.2-A.8 EMS, split precincts, associate ballot configurations
EMSs of the Split precincts device class SHALL support the definition of distinct ballot configurations for voters from two or more election districts that are served by a given polling place.
7.2-B EMS, ballot style distribution
The EMS SHALL provide for the generation of master and distributed copies of ballot styles as needed to configure each voting device in the system.
7.2-B.1 EMS, ballot style identification
The EMS SHALL generate codes or marks as needed to uniquely identify the ballot style associated with any ballot.
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
In paper-based systems, identifying marks would appear on the actual ballots. DREs would make internal use of unique identifiers for ballot styles but would not necessarily present these where the voter would see them.
When different precincts share a common ballot style in a paper-based system, typically it is assumed that the ballots from the two precincts will be kept physically separate, tabulated separately, and attributed to the correct precinct at the time of reporting—even in combined precincts where this imposes procedural overhead.
Source: [VSS2002] I.2.3.1.1.1.e
7.2-C EMS, ballot style reuse
The EMS SHALL support retention, modification, and reuse of ballot styles within the same election and from one election to the next.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
Although general districting/precinct data and general ballot formatting parameters can be re-used from election to election, it is not possible to re-use ballot styles which will always change from election to election. It was mentioned in the VVSG introduction that the term "ballot style" was chosen to replace the term "ballot format" due to the common acceptance of the former term. However, as "ballot style" is defined in the VVSG, it is now used to describe everything on the ballot, including the contests, candidates and its finished image, which, for security purposes, should not be re-used from election to election, nor would it practically be used from election to election as contests and candidates should change. It would seem that intent of this requirement actually pertains to the format used for ballot styles and not the ballot style directly as it is currently defined. Proposed Change: Change the requirement to the following: "The EMS SHALL support retention, modification, and reuse of the format used for ballot styles within the same election and from one election to the next."
7.2-D EMS, ballot style protection
The EMS SHALL prevent unauthorized modification of any ballot styles.
7.2.1 Procedures required for correct system functioning
The requirements for voting systems are written assuming that these procedures will be followed.
Paper ballot production: central election officials must verify that paper ballots are produced in accordance with manufacturer specifications.
Paper ballot production quality: central election officials must ensure that paper ballots conform to manufacturer specifications for type of paper stock, weight, size, shape, size and location of field used to record votes, folding, bleed through, and ink for printing. ([VSS2002] I.2.3.1.3.1.c)
Paper ballot field alignment: Central election officials must ensure that the vote response fields can be properly aligned with respect to any ballot marking devices used. ([VSS2002] I.2.3.1.1.2.b)
Paper ballot timing mark alignment: central election officials must ensure that timing marks align properly with the vote response fields. ([VSS2002] I.2.3.1.1.2.c)
7.3 Equipment Setup for Security and Integrity
7.3.1 Logic and accuracy testing
The purpose of logic and accuracy testing is to detect malfunctioning and misconfigured devices before polls are opened. It is not a defense against fraud.[9]
Election personnel conduct equipment and system readiness tests prior to the start of an election to ensure that the voting system functions properly, to confirm that system equipment has been properly integrated, and to obtain equipment status and readiness reports. The content of those reports is defined in Part 1: 7.8 "Reporting".
2 Comments
Comment by Carl Hage (General Public)
The "Logic and accuracy testing" should include public access and inspection as an integral part of the process. Data files produced by an EMS to be loaded into vote collection or counting equipment should be digitally signed by the election official and make with electronic access public (e.g. copied to a web server and/or distributed via email list). The voting equipment should only support loading of data files co-signed by a higher election authority, e.g. the secretary of state or FEC. All content and digital signatures made to co-sign election data files should be public, collected and audited by the FEC. (Inside the US.) To facilitate verification of ballot styles and election districts, the election officials must make a digitally signed data file available (with public electronic access), containing a mapping between street address ranges and election districts, and a mapping between election districts and jurisdictions and political and administrative subdivisions. To facilitate computer checking, names of contests, elected offices, jurisdictions, and subsivisions must use the full legal name, properly spelled, capitalized, and punctuated. Each election official must define a process to collect errors in spelling, abbreviations, or missing words. Any EMS data file that contains abbreviations or truncations must also produce a mapping file containing the complete correct spelling for any truncated or abbreviated name. [Note: current ballot counting systems often limit the number of characters in contest or candidate names, so candidate names are truncated and contests abbreviated-- sometimes in a human unreadable manner. To allow electronic validation, these errors need to be removed in an automatic manner.]
Comment by David Beirne, Executive Director, Election Technology Council (Manufacturer)
Strike "It is not a defense against fraud." This is a subjective statement and should be stricken and is not relevant to the section.
All systems SHALL provide the capabilities to:
- Verify that all voting devices are properly prepared for an election and collect data that verify equipment readiness;
- Verify the correct installation and interface of all system equipment;
- Verify that hardware and software function correctly; and
- Segregate test data from actual voting data, either procedurally or by hardware/software features.
7.3.1-B Built-in self-test and diagnostics
All programmed devices SHALL include built-in measurement, self-test, and diagnostic software and hardware for monitoring and reporting the system's status and degree of operability.
7.3.1-C Verify proper preparation of ballot styles
The EMS SHALL enable central election officials to test that ballot styles and programs have been properly prepared and installed.
7.3.1-D Verify proper installation of ballot styles
Programmed devices SHALL include a capability to automatically verify that the software and ballot styles have been properly selected and installed in the equipment and immediately notify an election official of any errors.
Applies To: Programmed device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
Examples of detectable errors include use of software or data intended for a different type of device and operational failures in transferring the software or data.
Source: [VSS2002] I.2.3.3.b, I.4.4.2.c
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
Clarify "notify an election official of errors"
7.3.1-E Verify compatibility between software and ballot styles
Programmed devices SHALL include a capability to automatically verify that software correctly matches the ballot styles that it is intended to process and immediately notify an election official of any errors.
Programmed tabulators SHALL provide the capability for central election officials or election judges to submit test ballots for use in verifying the integrity of the system.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
It is unclear as to why election judges have been included under this requirement. Testing of the programmed devices should have been completed before an election judge takes possession of the unit for use on Election Day. Please clarify why election judges are included under this requirement.
Paper-based tabulators SHALL support testing that uses all potential ballot positions as active positions.
7.3.1-H Paper-based tabulators, testing calibration
Paper-based tabulators SHALL support the use of test ballots to test the calibration of the paper-to-digital conversion (i.e., the calibration of optical sensors, the density threshold, and/or the logical reduction of scanned images to binary values, as applicable).
Paper-based vote-capture devices SHALL include a means of verifying that the ballot marking mechanism is properly prepared and ready to use.
7.3.1-J L&A testing, no side-effects
Logic and accuracy testing functions SHALL introduce no residual side-effects other than audit log entries and status changes to note that the tests have been run with a successful or failed result.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is ambiguous. Proposed Change: Change the requirement ot read as follows: Logic and accuracy testing functions SHALL introduce no effects on the election mode operation other than audit log entries, status changes to note that the tests have been run with a successful or failed result, separate storage of test results, changes in the system counter, and normal wear and tear.
Programmed tabulators SHALL ensure that all test data have been expunged before the logic and accuracy test is logged as successful. If the test data have not been expunged the logic and accuracy test SHALL log as failed.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This condition means the system must know that it is in an L&A test mode for a wide range of operations. If the concern is that test results, not just L&A test results, are on the system during voting it would be better to phrase this as requiring all test results to be purged from the system prior to being prepared for election counting. Alternatively, simply require that test data be isolated from election results. Proposed Change: Change the requirement to read as follows: Programmed tabulators SHALL ensure that all test data have been expunged prior to being prepared for capturing election results or that the test data is isolated from the election results. If the test data have not been expunged or isolated, then the logic and accuracy test SHALL log as failed.
7.4 Opening Polls
7.4-A Programmed device, verify L&A performed
Programmed devices SHALL provide an internal test or diagnostic capability to verify that all of the tests specified in Part 1: 7.3 "Equipment Setup for Security and Integrity" have been successfully completed.
7.4-B Programmed device, disable untested devices
Programmed devices SHALL provide for automatic disabling of an untested device until it has been tested.
7.4-C Paper-based tabulator activation
Paper-based tabulators SHALL include a means of activating the ballot counting device.
7.4-D Paper-based tabulator, verify activation
Paper-based tabulators SHALL include a means of verifying that the ballot counting device has been correctly activated and is functioning properly.
7.4-E Programmed vote-capture device, open poll function
Programmed vote-capture devices SHALL provide designated functions for opening the poll.
7.4-E.1 Programmed vote-capture device, protect open poll function
Programmed vote-capture devices SHALL include a security seal, a password, or a data code recognition capability to prevent the inadvertent or unauthorized actuation of the poll-opening function.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement might be construed to mean that the device must make itself completely inoperable if it has not been tested, rather than what is believed to be the intent of not allowing the unit to continue onto a live election mode mode unless it has been tested. Proposed Change: Change the requirement to read as follows: Programmed devices SHALL not allow the unit to proceed to the election mode unless the logic and accuracy test has been performed successfully.
7.4-E.2 Programmed vote-capture device, enforce correct poll opening process
Programmed vote-capture devices SHALL include a means of enforcing the execution of poll-opening steps in the proper sequence if more than one step is required.
7.4-E.3 Programmed vote-capture device, verify activation
Programmed vote-capture devices SHALL include a means of verifying that the system has been correctly activated.
7.5 Casting
These functional capabilities include all operations conducted at the polling place by voters and officials while polls are open.
7.5.1 Issuance of voting credentials and ballot activation
The term "ballot activation" is sometimes used in a broad sense to cover the general activities of (1) determining what type of ballot must be presented to the voter, and (2) activating the voting system to present the ballot style that is appropriate for that voter. In this section, "issuance of voting credentials" is used for the first activity, and "ballot activation" is used exclusively for the second activity.
Voting credentials are those data items sufficient for the voting system to activate the appropriate ballot for the voter. The credentials consist of an indication of the ballot style and ballot configuration as well as any additional ballot options that the voting system may be capable of presenting if selected by the voter, such as a magnified ballot for a voter with low vision. If the voting system is used for provisional voting, the credentials may also include an identifier that effectively would link the voter's identity with the voter’s cast ballot. The credentials must also indicate the election for which the credentials are valid. Lastly, there is usually a code calculated on the credentials so that the voting system can verify their integrity and verify that an authorized activation device issued the credentials.
An activation device (e.g., an epollbook) stores the credentials on a token (e.g., a memory card) so that the voter can carry them to the vote-capture device – a DRE or EBP. Thus, there is typically an "air gap" required between the activation device and the vote-capture device. The requirements in this section do not prohibit, however, the activation device from being connected to a network of DREs or EBPs. In this case, the credentials and token would be represented by whatever signaling and data is exchanged across the network between the activation device and the DREs/EBPs. Credential issuance also may be performed pre-election by a DRE or EBP in a ballot activation mode (for example, a series of memory cards could be activated for certain ballot styles and ballot configurations in advance of opening the polls).
Preserving privacy of the ballot is a paramount consideration in issuance of voter credentials and ballot activation because knowledge of the voter’s identity is involved. The requirements in this section mandate that privacy of the ballot be protected throughout the entire process of Credential issuance and ballot activation, and that no information be maintained in reports or logs that could assist in identifying a voter’s cast ballot (except for provisional voting on a DRE).
Provisional voting using a DRE must, however, "violate" voter privacy because it is necessary to link the DRE’s CVR with the voter’s identity. If an epollbook or other programmable activation device is used also for provisional voting, then it is possible that the epollbook could keep a record of provisional voters and include, with the voting credentials, an identifier associated with each provisional voter’s identification. The DRE might then associate that identifier with that voter’s CVR. This should only happen if the activation device and the vote-capture device are in a "provisional voting" mode; no linkage of voter identity to voter CVRs should be possible otherwise. While this may be an acceptable method for associating a voter’s identity with the voter’s CVR for provisional voting, at the same time this privacy violation is cause for special concern when implemented in software, and the source code associated with these activities on the activation device and the vote-capture device should receive extra scrutiny. As well, this general process should be considered fair game for OEVT.
This section also contains requirements that permit a ballot activation device to connect to an external voter registration database via a network. Network connectivity is inherently difficult to secure and make reliable, therefore the requirements in this section mandate that the external connectivity must be enabled/disabled by an authorized election official, and that a backup mechanism be in place if the connectivity fails. A ballot activation device or DRE/EBP used as an activation device cannot be connected simultaneously to both an internal (to the voting site) network of DREs or EBPs, and an external network. (The ballot activation device cannot include more than one network interface.) Any external network connectivity should be considered fair game for OEVT and, in particular, network vulnerability and penetration testing.
For provisional voting, if the linkage between the voter’s identity and the voter’s CVR is recorded in the external voter registration database, this may also be considered as fair game for OEVT.
4 Comments
Comment by Brian V. Jarvis (Local Election Official)
Regarding external network connectivity. Given the serious concerns stated regarding this feature, I would recommend that verification of this functionality not wait until OEVT and network vulnerability and penetration testing. Long before OEVT, the functionality of the modules implementing this feature should be verified and validated during the design, coding, and unit/integration testing phases of the development lifecycle. (And, documentation submitted in the TDP should indicate this verification was performed.) Waiting until OEVT to identify deficiencies in the system would require the systems/software to have to be opened-up, patched, and then re-verified (including regression testing, etc.). A basic premise of software/system development is that you catch defects as early in the development lifecycle as is possible -- and certainly not wait until system qualification testing.
Comment by George Gilbert (Local Election Official)
7.5.1—Paragraphs 4 and 5 discuss the restriction of CVR identification with a voter to "provisional" voting. North Carolina (not uniquely), however, requires that all "absentee" ballots be "identifiable and retrievable." Ballot secrecy, in our case, is, by law, the responsibility of the local Board of Elections not of the voting system used. The proposed language should be modified to accommodate the unique feature of state law and widely varying procedures employed among the states to protect voter secrecy rather than dictate a single, uniform technical standards that precludes state flexibility.
Comment by David Beirne, Executive Director, Election Technology Council (Manufacturer)
"An activation device (e.g., an epollbook) stores the credentials on a token (e.g., a memory card)" Strike the reference to an epollbook as not all epollbooks may be used during the ballot activiation process.
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)
7.5.1.1 Credential issuance and ballot activation
7.5.1.1-A Activation device, DRE, EBP, ballot activation
DREs and EBPs SHALL support ballot activation.
7.5.1.1-A.1 Activation device, DRE, EBP, credential issuance
DREs or EBPs MAY function exclusively as an activation device and issue ballot activation credentials.
7.5.1.1-A.2 Activation device, DRE, EBP, at most one cast ballot per session
Activation devices, DREs, and EBPs SHALL enable poll workers either to initiate, or to provide the voter with the credentials sufficient to initiate, a voting session in which the voter may cast or print at most one ballot.
7.5.1.1-B Activation device, contemporaneous record
Activation devices MAY create contemporaneous records of credential issuance to a voter. The record, once made, SHALL NOT be able to be modified by the voting system.
Applies To: Activation device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
The voting system must create a record at the time when credentials are issued to voters so that the collection of records can be compared to the number of ballots voted. This may be done if the activation device prints a record, or by using a paper pollbook.
Source: New requirement
7.5.1.1-C Activation device, DRE, EBP, control ballot configuration
Activation devices, DREs, and EBPs SHALL enable poll workers to control the ballot configuration(s) made available to the voter, whether presented in printed form or electronic display, such that each voter is permitted to record votes only in contests in which that voter is authorized to vote.
7.5.1.1-C.1 Activation device, DRE, EBP, enable only applicable contests
DREs and EBPs SHALL activate all portions of the ballot upon which the voter is entitled to vote and SHALL disable all portions of the ballot upon which the voter is not entitled to vote.
Applies To: DRE, EBP
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
In paper-based systems, open primaries have sometimes been handled by printing a single ballot style that merges the contests from all parties, instructing the voter to vote only in the contests applicable to a single party, and rejecting or discarding votes that violate this instruction. To use that approach on a DRE or EBP would violate this requirement.
Source: [VSS2002] I.2.4.2.g., [VSS2002] I.2.4.2.h
7.5.1.1-C.2 Activation device, DRE, EBP, select ballot configuration for party in primary elections
DREs and EBPs SHALL enable the selection of the ballot configuration that is appropriate to a party affiliation declared by the voter in a primary election.
7.5.1.2 Secrecy of the ballot
Activation devices, DREs, EBPs SHALL preserve secrecy of the ballot throughout the process of issuing credentials and activating the ballot and the keeping of records associated with ballot activation.
Applies To: Activation device, DRE, EBP
Test Reference: Part 3: 4.5 "Source Code Review", 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"
DISCUSSION
Secrecy of the ballot must be preserved during all operations associated with activation of the ballot, including during the creation of the ballot activation credential and information, during the process of activating the ballot, and in all keeping of associated records, reports, and logs. It must not be possible to identify a voter’s ballot or in some way violate secrecy of the ballot by aggregating records from different devices.
For example, an epollbook cannot retain and associate any information written to a ballot activation token with the voter’s identification information, and a vote-capture device cannot retain information from the token and associate it with the CVR – or else it would be possible to link the sets of records and identify the voter.
Note that Requirement Part 1: 7.5.1.2-A.3 modifies this requirement if the activation device is used with provisional voting on a DRE.
Source: New requirement
7.5.1.2-A.1 DRE and EBP, open primaries, party selection should be private
In an open primary on a DRE or EBP, the voter SHOULD be allowed to choose a party affiliation in private at the start of the voting session and vote the appropriate ballot configuration (i.e., the choice of affiliation SHOULD be private as well as the selection of votes on the ballot).
2 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
The definition of an Open Primary in the Glossary does not match the requirement of a private selection. If the VVSG is using Open Primary to mean a primary where party selection is made in private then it should be clearly indicated that the standard uses the term to define the ballot selection process and not the various political definitions used by states. The VVSG should either use Open & Closed primaries to describe system functions of private and non-private selection of a party ballot or create specific terms that identify the selection process. Closed and Open primaries are being used inconsistently in the standard.
Comment by George Gilbert (Local Election Official)
The definition of "Open Primary" points out that state rule differ regarding the "privacy" allowed a voter in selecting a party affiliation in an "open primary." The way this provision is worded makes it sound as if voter privacy in selecting party is prefered. Section should read that the DRE or EPB should have the capability to allow private selection leaving the options of which is prefered to the states.
7.5.1.2-A.2 Activation device, records preserve secrecy of the ballot
Activation devices SHALL NoT create or retain information that can be used to identify a voter’s ballot, including the order and time at which a voter uses the voting system.
7.5.1.2-A.3 Activation device, ballot activation provisional voting
Credential issuance, only when used during provisional voting, MAY permit the voter’s name to be associated with the voter’s ballot for the purposes of deciding whether to count the ballot. The mechanism used for this association SHALL itself not identify the voter.
Applies To: Activation device, DRE, EBP
Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"
DISCUSSION
For provisional voting, the voter’s identity is associated with the voter’s ballot so as to permit a subsequent decision whether to count the ballot. As an example, the activation device may create an identifier and associate it with the provisional voter’s identity, and then include this identifier with other information necessary to activate the ballot. The vote-capture device may store this identifier with the ballot so as to trace the ballot back to the voter’s identity for the purposes of deciding whether the count the ballot. The identifier must not itself identify the voter. For example, it must not include the voter’s identity or other information associated with the voter such as an SSN or other identifying information.
Source: New requirement
2 Comments
Comment by George Gilbert (Local Election Official)
7.5.1.2-A.3-- North Carolina (not uniquely) requires that all "absentee" ballots, in addition to "provisional" ballots, be "identifiable and retrievable." Ballot secrecy, in our case, is, by law, the responsibility of the local Board of Elections not of the voting system used. The proposed language should be modified to accommodate the unique feature of state law and widely varying procedures employed among the states to protect voter secrecy rather than dictate a single, uniform technical standards that precludes state flexibility.
Comment by Robert Ferraro, SAVEourVotes.org (Advocacy Group)
There should be no exception allowing a vote to be associated with a unique number identifying the voter, even for early or provisional voting. The risk of losing the privacy of the vote is way too great compared to the efficiency gained. Provisional voters can vote on paper provisional ballots. The best way to avoid a possible breakdown in privacy is to prohibit the vendors from building the capability of associating a vote to a voter in the voting system. Certification should require both testing the voting units and the ballot activation devices and examination of their source code, to verify that they do not have this capability. If the proposed guideline 7.5.1.2-A.3 is implemented as written, and voting systems are permitted to accomodate this dangerous capability, it would require that each and every county, that is concerned about the secrecy of the ballot, perform the necessary testing to ensure that it is not being used. Most counties do not have sufficient expertise to accomplish this task. Moreover, such testing would be prohibitively expensive.
7.5.1.3 Credentials and tokens
7.5.1.3-A Activation device, credentials and tokens
The sole purpose and use of the ballot activation credentials and token SHALL be for the purpose of activating the ballot.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement should allow for the token to record the fact that the voter did cast their ballot by de-activating the token. If tokens are not de-activated after the ballot is cast, then they could be used to cast additional ballots. Proposed Change: Change the requriement to read as follows: The sole purpose and use of the ballot activation credentials and token SHALL be for the purpose of activating the ballot and then de-activating the token once the ballot has been cast.
7.5.1.3-A.1 Activation device, token limited in capacity
The token SHOULD have the capacity to contain only the information sufficient to activate the ballot.
Applies To: Activation device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
The token should be limited to containing only the necessary information and nothing more – on memory card, possibly several bytes or less. This requirement addresses the threat of the token being used to pass other information to and from the vote-capture device, which should be considered especially if the activation device is connected to an external network (to connect to a registration database).
Source: New requirement
7.5.1.3-A.2 Activation device, DRE, EPB, token de-activated after casting
DREs and EBPs SHALL de-activate ballot activation credentials on the token after the voter has successfully cast the ballot.
Applies To: DRE, EBP
Test Reference: Part 3: 4.5 "Source Code Review", 5.2 "Functional Testing"
DISCUSSION
The token and credentials are considered as authorization to cast a ballot and therefore must be de-activated after that ballot has been cast (and not before). It may be useful for the token to carry state information, such as:
- Inactive - ready to be used in an activation device;
- Active - loaded with credentials and able to activate the ballot;
- In use - has been used to activate the ballot but the ballot has not yet been cast;
- Closed successfully - has been used to activate the ballot and the ballot has been cast successfully; and
- Closed unsuccessfully - has been used to activate the ballot but the ballot was not successfully cast for some reason.
Source: New requirement
7.5.1.3-A.3 Activation device, token should be non-reusable
Applies To: Activation device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
The token should be one-way in that it is used only once to activate the ballot and cannot be recycled and used again by an activation device to activate a subsequent ballot. This eliminates the threat of passing other information from the vote-capture device back to the activation device, which should be considered especially if the activation device is connected to an external network (to connect to a registration database).
Source: New requirement
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
It appears that this requirement only permits the use of a voter smart card one time in an election. Isn't there an huge cost to jurisdictions to have thousands, tens of thousands or hundreds of thousands of smart cards in the polls ? Isn't there a greater risk of voters being unable to vote because precincts run out of cards?
7.5.1.3-A.4 Activation device, integrity and authenticity of ballot activation information
Ballot activation credentials SHALL be created in such a manner that the vote-capture device can verify their integrity and authenticity for the current election and for that vote-capture device.
7.5.1.4 Activation devices connected to remote registration databases
7.5.1.4-A Activation device, may access remote registration database
The activation device MAY connect to an external network for the purposes of accessing and updating information from a remote voter registration database.
Applies To: Activation device ^ Electronic device
Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"
DISCUSSION
External is used here to mean "a public or private network extending beyond the voting site." An activation device may include the capability to access an external network for the purposes of accessing voter identification information in a remote voter registration database. Note that this is the only remote access permitted; network access cannot be used for other purposes such as for accessing web sites, email, etc. See also related requirements in Part 1: 5.5 "System Integrity Management" and 5.6 "Communication Security" pertaining to secure system and network configurations for the ballot activation device.
Source: New requirement
1 Comment
Comment by Ariel J. Feldman, Harlan Yu, Joseph A. Calandrino (Princeton University) (Academic)
This allows devices at polling places to connect to public communication networks to interface with voter registration databases. Connecting these devices to the public networks provides adversaries with yet another interface to attack, and one that can be exploited remotely on many devices simultaneously. In addition, networks, even private networks, provide a means for viruses to propagate quickly. Thus, although networks can be useful to elections (e.g. quickly reporting unofficial results and checking voter registration in real-time), we believe that their security risks outweigh their benefits. Voting machines should never be networked to each other or to any other device, and, if possible, neither should election management systems (EMSs), polling place accumulators, or pollbook devices. We also suggest that voting systems adopt a "segregated dual-EMS architecture," where devices used to initialize an election are distinct from devices used to tabulate election results (see: J.A. Calandrino, A.J. Feldman, J.A. Halderman, D. Wagner, H. Yu, B. Zeller. Source Code Review of the Diebold Voting System. July 2007. Section 6.10.) This architecture hinders the spread of viruses and reduces the possibility that viruses could persist from one election to the next.
7.5.1.4-A.1 Activation device, cannot connect to multiple networks
The activation device SHALL connect to at most one network; either a network connection to vote-capture devices or an external network for the purposes of accessing information in a remote voter registration database, but not both.
7.5.1.4-A.2 Activation device, access to remote registration database configurable
The activation device SHALL have the capability to access an external network only if so authorized by an administrator.
7.5.1.4-A.3 Activation device, notification of access to remote registration database
The activation device SHALL display a continuous indication to the poll worker during the period it is enabled to access an external network.
7.5.1.4-A.4 Activation device, remote access failure backup capability
The voting system SHALL include a backup capability to activate ballots if access to a remote registration database fails.
Applies To: Voting system
Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"
DISCUSSION
If the remote database is unavailable, the voting system must include some backup capability so that it may continue to activate ballots, e.g., a cached local copy of the voter registration database or a paper pollbook.
Source: New requirement
7.5.1.4-A.5 Activation device, connects to router/firewall
If externally networked, the activation device SHALL connect to a router with network firewall capabilities using a wired connection and the TCP/IP communications protocol.
Applies To: Activation device ^ Electronic device
Test Reference: Part 3: 5.2 "Functional Testing", 5.4 "Open-Ended Vulnerability Testing"
DISCUSSION
This requirement prohibits the activation device from connecting directly to the external network and possibly using a wireless connection. The device must connect to a router over a wire (e.g., Ethernet). The router must have firewall capability and be configured to block or filter unneeded services and protocols. See [NIST02] for suggested firewall configuration information.
Source: New requirement
1 Comment
Comment by Gail Audette (Voting System Test Laboratory)
This design requirement limits innovation by requiring TCP/IP and wired connections. Is it the intent of this requirement to impede use of current and emerging technologies?
7.5.1.4-B Activation device, source code reviews
Activation devices SHALL be free of vulnerabilities that may be exploited by remote attackers over the network.
2 Comments
Comment by Gail Audette (Voting System Test Laboratory)
The discussion implies that this requirement applies to all activation devices, even those that do not have the capability of being networked (the preceding requirements do not require that a card activation device be attached to a network). Is this a design requirement forcing a component to be designed to support a capability that is not that system's functional requirement?
Comment by Premier Election Solutions (Manufacturer)
This requirement should only be required if the device is connected to an external network. Proposed Change: Change the requirement to read as follows: Activation devices SHALL be free of vulnerabilities that may be exploited by remote attackers over the network, if the activation device is capable of being connected to a network.
7.5.2 General voting functionality
The ballot presented to the voter SHALL NOT display or link to any advertising or commercial logos of any kind, whether public service, commercial, or political, unless added by central election officials using the functionality described in Requirement part1: 7.2-A.5.
2 Comments
Comment by George Gilbert (Local Election Official)
7.5.2-A--While I agree entirely with this restriction, it does not seem germaine to this section. If the concern is security, it should appear there rather than here.
Comment by Premier Election Solutions (Manufacturer)
As the ballot content is under the control of the jurisdiction, such a requirement is not relevant to vote capture device. In respect to compliance with legal requirements and copyright notices, a manufacturer is required to provide identification on the unit and certain software displays. Please clarify whether this requirement prevents a manufacturer from providing their identification in respect to compliance with legal requirements and copyright notices.
All vote-capture devices SHALL record the selection and non-selection of individual contest choices for each contest.
7.5.3 Voting variations
7.5.3-A Vote-capture device, voting variations
All vote-capture devices SHALL support the gathering of votes using all voting variations indicated for them in the implementation statement.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This section clearly defines the requirements and having all of the sub-sections does not add any extra information or value and should therefore be removed. Proposed Change: Remove all sub-sections to this requirement.
All vote-capture devices SHALL be capable of gathering and recording votes in contests where the voter is allowed to choose at most one contest choice from a list of contest choices.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.5.3-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
7.5.3-A.2 Vote-capture device, yes/no question
All vote-capture devices SHALL be capable of gathering and recording votes in contests where the voter is allowed to vote yes or no on a question.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.5.3-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
7.5.3-A.3 Vote-capture device, indicate party affiliations and endorsements
All vote-capture devices SHALL be capable of indicating the affiliation and/or endorsements of each contest choice.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.5.3-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
7.5.3-A.4 Vote-capture device, closed primaries
Vote-capture devices of the closed primaries device class SHALL be capable of gathering and recording votes within a voting process that assigns different ballot styles depending on the registered political party affiliation of the voter and supports both party-specific and non-party-specific contests.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
The registration of the voter does not generate system functionality that selects the primary ballot, unless an e-pollbook provides this function via network or token writing. The selection is made by the poll worker either through direct selection on the voting system or programming of a token. In some states this may occur in Open Primaries that permit voters to cross over to another party's primary. The VVSG should either use Open & Closed primaries to describe system functions of private and non-private selection of a party ballot or create specific terms that identify the selection process. Closed and Open primaries are being used inconsistently in the standard.
7.5.3-A.5 Vote-capture device, open primaries
Vote-capture devices of the open primaries device class SHALL be capable of gathering and recording votes within a voting process that assigns different ballot styles depending on the political party chosen by the voter at the time of voting and supports both party-specific and non-party-specific contests.
Vote-capture devices of the write-ins device class SHALL record the voter's selection of candidates whose names do not appear on the ballot and record as many write-in votes as the voter is allowed, per the definition of N(r) in Part 1: 8.3 "Logic Model (normative)".
7.5.3-A.7 Vote-capture device, support write-in reconciliation
Vote-capture devices of the write-ins device class SHALL be capable of gathering and recording votes within a voting process that allows for reconciliation of aliases and double votes.
7.5.3-A.8 Vote-capture device, ballot rotation
Vote-capture devices of the ballot rotation device class SHALL be capable of gathering and recording votes when the ordering of contest choices in ballot positions within each contest is variable.
7.5.3-A.9 Ballot rotation, equal time for each contest choice
Programmed vote-capture devices that enable ballot rotation in a given contest SHALL alter the ordering of contest choices in such a manner that no contest choice SHALL ever have appeared in any particular ballot position two or more times more often than any other.
Applies To: Vote-capture device Λ Programmed device Λ Ballot rotation device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
This is less restrictive than requiring sequential rotation. For a contest of M contest choices, the order may be shuffled randomly after each batch of M ballots and rotated sequentially within each batch.
Source: Clarification or extension of existing requirements
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is ambiguous. There are many variations in rotation algorythms that attempt to achieve this result since rotation is usually done on a precinct by precinct basis and not within a precinct on with a voting device. Rotation algorythms are dictated by State Law. A voting system may have the ability to provide rotation, but this standard should not attempt to dictate the numerous variations mandated by laws of various States. Proposed Change: Change this requirement to the following: Voting systems that enable ballot rotation in a given contest SHALL alter the ordering of contest choices in a manner consistent with the documented rotation algorythms. Applies to: Voting system
7.5.3-A.10 Vote-capture device, straight party voting
Vote-capture devices of the straight party voting device class SHALL be capable of gathering and recording votes for a special contest in which the selection of a political party implies votes for the contest choices endorsed by that party in all straight-party-votable contests on the ballot.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
"What should be the behavior in a straight party selection: - to cross over and select a candidate in another party in one or more contests - what is the behavior of a cross over when the vote for is a 1 of M and an N of M; - with no affiliated candidates; < than the vote for; = to the vote for; > than the vote for - non-partisan contests or questions? "
7.5.3-A.11 Vote-capture device, cross-party endorsement
Vote-capture devices of the cross-party endorsement device class SHALL be capable of gathering and recording straight-party votes when a given contest choice is endorsed by two or more different political parties.
Applies To: Vote-capture device Λ Cross-party endorsement device
Test Reference: Part 3: 5.2 "Functional Testing"
Source: Clarification or extension of existing requirements
2 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
What is the required functionality of a Cross Party Endorsement in N of M contests.? Can 1 candidate get 2 votes, 1 for each party?
Comment by Premier Election Solutions (Manufacturer)
This requirement does not take into account the action required when conflicts arise between the straight party vote and the specific candidate vote. Further define this requirement to provide required actions by the vote-capture device when conflicts occur between the straight party vote and the specific candidate vote.
Vote-capture devices of the split precincts device class SHALL be capable of gathering and recording votes in a precinct where there are distinct ballot styles for voters from two or more election districts.
Vote-capture devices of the N-of-M voting device class SHALL be capable of gathering and recording votes in contests where the voter is allowed to choose up to a specified number of contest choices (N(r) > 1, per Part 1 8.3 "Logic Model (normative)") from a list of contest choices.
Vote-capture devices of the cumulative voting device class SHALL be capable of gathering and recording votes in contests where the voter is allowed to allocate up to a specified number of votes (N(r) > 1, per Part 1 per Part 1: 8.3 "Logic Model (normative)") over a list of contest choices, possibly giving more than one vote to a given contest choice.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
Insufficient detail: No precision has been added. This is the same vague requirement as the 2005 standard. If there are multiple ways to handle cumulative votes identify them and provide detailed requirements so they can be consistently tested. How does the voting system record a cumulative vote in the selection of 2 in a vote for 3? Does each candidate get 1.5 votes? Does the voter select one candidate's name twice & another candidate's name once?
7.5.3-A.15 Vote-capture device, ranked order voting
Vote-capture devices of the ranked order voting device class SHALL be capable of gathering and recording votes in contests where the voter is allowed to rank contest choices in a contest in order of preference, as first choice, second choice, etc.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
No precision has been added from the 2005 standard. Should the voting system have to support ranking of all contest choices? Is there a minimum acceptable number that must be ranked?
7.5.3-A.16 Vote-capture device, provisional-challenged ballots
Vote-capture devices of the provisional-challenged ballots device class SHALL be capable of gathering and recording votes within a voting process that allows the decision whether to count a particular ballot to be deferred until after election day.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
Poorly stated requirement. It appears that this can be defined in the polling place. The requirement should address this in terms of the totals being included or excluded from the polling place totals when the polls are closed. Also this should be an EMS requirement.
DREs of the provisional-challenged ballots device class SHALL provide the capability to categorize each provisional/challenged ballot.
Applies To: DRE Λ Provisional-challenged ballots device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
Categories (e.g., "regular provisional," "extended hours provisional," "regular extended hours") would be jurisdiction-dependent.
Source: [P1583] 5.6.5.2.s.2[5]
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
What are the specific provisional categories that the voting system must support? If these are defined by the election official then this requirements also needs to be addressed in the EMS.
7.5.3-A.18 Vote-capture device, review-required ballots
Vote-capture devices of the review-required ballots device class SHALL be capable of gathering and recording votes within a voting process that requires certain ballots to be flagged or separated for review.
Applies To: Vote-capture device Λ Review-required ballots device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
In some systems and jurisdictions, all ballots containing write-in votes require flagging or separation for review. Support for the class indicates that the system can flag or separate ballots in this manner and include the results of the review in the reported totals (see Part 1: 2.5.3.1 "Supported voting variations (system-level)"). Other reasons for which ballots are flagged or separated are jurisdiction-dependent. It is assumed that ballot presentation is unchanged for Review-required ballots.
Source: Extrapolated from [VSS2002] I.2.5.2
7.5.4 Recording votes
Vote-capture devices SHALL record each vote precisely as indicated by the voter.
7.5.4-A.1 Records consistent with feedback to voter
All CVRs and logs SHALL be consistent with the feedback given to the voter.
2 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
Assuming that this requirement includes the audit log, the requirement should be clarified to exclude feedback provided to the voter during the voting session.
Comment by Craig Burton, CTO, EveryoneCounts.com (Manufacturer)
There is no specification of how voting- and system- messages are specified via the EMS, nor how they are provided if there are multiple languages. L&A testing should also seek to cause all such messages to display. That is, "ballot style proofs" do not show system messages.
7.5.4-B DRE, confirm votes recorded
DREs SHALL verify (i.e., actively check and confirm) the correct addition of votes to the persistent storage of the device.
1 Comment
Comment by Christopher (None)
It is also of PARAMOUNT importance that the voter receive some kind of receipt for the transaction that has been made. This receipt should include an anonymous unique transaction ID, time, date and each vote cast. This way a user (or official) can, at the request of any voter in possession of this receipt, verify any vote cast by it's Transaction ID.
All systems SHALL support the casting of a ballot.
7.5.4-C.1 Equipment allows each eligible voter to vote
All systems SHALL make it possible for each eligible voter to cast a ballot, provided that the limits declared in the implementation statement for each device are not exceeded.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
Clarify what the implementation statement limits might be.
7.5.4-C.2 Paper-based, must have secure ballot boxes
Systems that include paper-based vote-capture devices SHALL include secure receptacles for holding voted ballots.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
The definition of "secure" is ambiguous and should be more clearly defined. Further define the term "secure" to a testable requirement.
DREs SHALL prevent modification of the voter's vote after the ballot is cast.
7.5.5 Redundant records
This section contains design requirements to enhance the recoverability of DRE devices. This is a separate concern from auditability, which is addressed in Part 1: Chapter 4: "Security and Audit Architecture". However, in some systems, the same records might satisfy both these requirements and auditability requirements.
7.5.5-A DRE, at least two separate copies of CVR
DREs SHALL record and retain at least two machine-countable copies of each CVR.
Applies To: DRE
Test Reference: Part 3: 4.3 "Verification of Design Requirements"
DISCUSSION
Besides data stored in electronic memory, a paper record with barcodes or EBM-style markings or a paper record printed in a machine-readable font would qualify as machine-countable.
Source: [VSS2002] I.2.2.2.2, I.2.2.4.2 and I.3.2.4.3.2.c
1 Comment
Comment by George Gilbert (Local Election Official)
7.5.5-A--It should be clarified whether a machine countable IVVR would qualify as one of these copies.
7.5.5-A.1 DRE, redundant CVRs on physically separate media
These redundant records SHALL be written to media that are physically separate from one another (e.g., two separate memory cards or one electronic record and one paper record).
Test Reference: Part 3: 4.3 "Verification of Design Requirements"
DISCUSSION
For improved auditability, it is preferable for the processes and paths used to record separate records to themselves to be as separate as possible, so that the opportunities for a single error to corrupt multiple records in the same way are minimized.
Source: [VSS2002] I.2.2.4.2 and I.3.2.4.3.2.c
1 Comment
Comment by George Gilbert (Local Election Official)
7.5.5-A.1—This section should specify that this redundancy requirement should be executed contemporaneously and that multiple memory chips within a DRE does not constitute compliance with this provision. My experience has been that, if one of the redundant memories in a DRE machine becomes corrupted, the reliability of all memory records becomes suspect….at least the way most DRE systems I have administered in the past (4 of them) have been designed….because of the interaction between these memory locations. Most DRE systems provide a separate, removable, medium for redundant capture of CVRs but some systems do not write these CVRs to this separate medium until the close of polls when all records are then written to the redundant medium. In this case, no sufficiently separate copy of the CVRs can be retrieved if the internal memory locations become corrupted.
7.5.6 Respecting limits
7.5.6-A Tabulator, prevent counter overflow
When a tabulator can no longer accept another ballot without the potential of overflowing a vote counter or otherwise compromising the integrity of the counts, it SHALL notify the user or operator and cease to accept new ballots.
Applies To: Tabulator
Test Reference: Part 3: 4.5 "Source Code Review", 5.2 "Functional Testing"
DISCUSSION
Assuming that the counter size is large enough such that the value will never be reached is not adequate. Systems are required to detect and prevent an impending overflow condition.
Source: Clarification of [VSS2002] II.5.4.2.g
When a DRE can no longer accept another ballot without the potential of overflowing a vote counter or otherwise compromising the integrity of the counts, it SHALL emit appropriate warnings and audit events and cease to activate new ballots.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant as it is already covered in 7.6.6-A. Proposed Change: Remove this requirement.
7.5.7 Procedures required for correct system functioning
The requirements for voting systems are written assuming that these procedures will be followed.
Process allows each eligible voter to vote: The voting process must allow each eligible voter to cast a ballot. ([VSS2002] I.2.4.2.b, generalized from DRE systems to the voting process.) See also Requirement Part 1: 7.5.4-C.1.
At most one cast ballot per voter: The voting process must prevent a voter from casting more than one ballot in the same election. ([VSS2002] I.2.4.2.d, generalized from DRE systems to the voting process.) See also Requirement Part 1: 7.5.1.1-A.2.
Process ensures correct ballot style: The voting process must prevent a voter from voting a ballot style to which he or she is not entitled. ([VSS2002] I.2.4.2.c, generalized from DRE systems to the voting process.) See also Requirement Part 1: 7.2-A.2, Requirement Part 1: 7.2-A.3 and Requirement Part 1: 7.5.1.1-C.
Process prevents vote tampering: The voting process must prevent modification of the voter's vote after the ballot is cast. ([VSS2002] I.2.4.3.3.n, generalized.) See also Requirement Part 1: 7.5.4-D, cast ballot.
Early voting, ballot accounting: In the presence of a witness, election judges must record the value of the ballot counter from each tabulator at the end of each active period. (Issue #1366, Issue #2143) See Part 1: 8.2 "Vote-Capture Device State Model (informative)". This procedure might be facilitated by designated functions of the voting equipment (i.e., printing of special early-voting end-of-day reports that include the timestamp, the value of the ballot counter, and little else).
Early voting, resumption practices: election judges returning equipment to the ready state after it has been placed in the suspended state must perform this operation in the presence of a witness, confirm that the equipment recorded no activity, and confirm that the ballot counter is unchanged from the value that was recorded when voting was suspended. See Part 1: 8.2 "Vote-Capture Device State Model (informative)". This procedure might be facilitated by designated functions of the voting equipment (i.e., printing of special early-voting resumption reports that include the timestamp, the value of the ballot counter, confirmation that nothing happened overnight, and little else).
1 Comment
Comment by David Beirne, Executive Director, Election Technology Council (Manufacturer)
The last two paragraphs of this section contain language that can be considered requirements for election practices not subject to the VVSG. If the intent is to provide a recommendation, the language should be amended to reflect this. See below for suggested edits: Early voting, ballot accounting: Election judges should record the value of the ballot counter from each tabulator at the end of each active period. (Issue #1366, Issue #2143) See Part 1: 8.2 "Vote-Capture Device State Model (informative)". This procedure might be facilitated by designated functions of the voting equipment (i.e., printing of special early-voting end-of-day reports that include the timestamp, the value of the ballot counter, and little else). Early voting, resumption practices: election judges returning equipment to the ready state after it has been placed in the suspended state should confirm that the equipment recorded no activity, and confirm that the ballot counter is unchanged from the value that was recorded when voting was suspended. See Part 1: 8.2 "Vote-Capture Device State Model (informative)". This procedure might be facilitated by designated functions of the voting equipment.
7.6 Closing Polls
7.6-A DRE, no CVRs before close of polls
DREs SHALL prevent access to CVRs until after the close of polls.
1 Comment
Comment by George Gilbert (Local Election Official)
7.6-A—This restriction could be problematic for early voting on DRE machines. During early voting, the polls are "open" for as much as several weeks. This leaves the CVRs on the machines vulnerable to mishap throughout this extended time if no backup of the records is retrieved and secured in a separate location. Procedures in my jurisdiction provide for a nightly backup of all early voting CRVs to a removable medium and secure storage of such backup throughout the voting, auditing and canvassing period. Such capability, which is vital in my view, to the security of early voting CRVs, would be prohibited by the current provision as written. Your discussion acknowledges that, for paper based voting systems, the voting equipment itself cannot meet this rigid restriction. Ballot security for such systems must be handled procedurally by each local jurisdiction. If this is permissible for paper based voting jurisdictions, there appears to be no justification, and the risk of catastrophic unintended consequences, of not treating DRE systems by the same standard.
7.6-B Programmed vote-capture devices, poll-closing function
Programmed vote-capture devices SHALL provide designated functions for closing the polls.
7.6-B.1 Programmed vote-capture devices, no voting when polls are closed
Programmed vote-capture devices SHALL prevent the further enabling, activation or marking of ballots by those devices once the polls have closed.
7.6-B.2 DRE, no ballot casting when polls are closed
DREs SHALL prevent the further casting of ballots once the polls have closed.
7.6-B.3 Programmed vote-capture devices, poll closing integrity check
Programmed vote-capture devices SHALL provide an internal test that verifies that the prescribed closing procedure has been followed and that the device status is normal.
7.6-B.4 Programmed vote-capture devices, report on poll closing process
Programmed vote-capture devices SHALL provide a means to produce a diagnostic test record that verifies the sequence of events and indicates that the poll closing process has been activated.
7.6-B.5 Programmed vote-capture devices, prevent reopening polls
Programmed vote-capture devices SHALL prevent reopening of the polls once the poll closing has been completed for that election.
7.6-C Precinct EMS, post-election reports
Precinct EMSs SHALL provide designated functions for generating precinct post-election reports.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
What is meant by "Precinct EMSs"? EMS is expected to be at the election office, not in the precinct or polling place.
7.6.1 Procedures required for correct system functioning
The requirements for voting systems are written assuming that these procedures will be followed.
Process, no early reporting: The voting process must prevent access to voted ballots until after the close of polls. ([VSS2002] I.2.4.3.3.r, generalized.) See also Requirement Part 1: 7.6-A.
7.7 Counting
7.7.1-A Detect and prevent ballot style mismatches
All voting systems SHALL detect ballot style mismatches and prevent votes from being tabulated or reported incorrectly due to such a mismatch.
1 Comment
Comment by George Gilbert (Local Election Official)
7.7.1-A—A further variation on this theme is to prevent ballot style/precinct mismatched votes from being cast. Preventing their tabulation is a good feature, however, it leaves one with a partial ballot and no easy way to include the valid contests while excluding the invalid contests. (I speak from experience.) A DRE system should be designed to prevent the activation of the unit is there are conflicts in the "credentials" (precinct & ballot style)recorded on the "token" and the precinct/ballot style configuration programmed on the voting unit. Such conflicts can arise where the precinct/ballot style configuration in an electronic pollbook designed to activate the voter’s "token" does not match the precinct/ballot style configuration of the EMS. This can occur, and has, due to human error. Catching such errors in pre-election testing requires that all testing be executed in the same manner as voting occurs, ie., that activation of the voting units incorporate the ePollbook activation of tokens in carrying out L&A testing.
7.7.1-B Detect and reject ballots that are oriented incorrectly
Paper-based tabulators SHALL either:
- Correctly count ballots regardless of whether they are fed upside down, right side up, forward, or reversed; or
- Detect and reject ballots that are oriented incorrectly.
7.7.2 Voting variations
7.7.2-A Tabulator, voting variations
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This section clearly defines the requirements and having all of the sub-sections does not add any extra information or value and should therefore be removed. Proposed Change: Remove all sub-sections to this requirement.
All tabulators SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the voter is allowed to choose at most one contest choice from a list of contest choices.
2 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
DREs are tabulators. There is no overvoting on DREs. As such they cannot report overvotes.
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
All tabulators SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the voter is allowed to vote yes or no on a question.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Also this is just a special case of the N-of-M case. Proposed Change: Remove this requirement.
Tabulators of the absentee voting device class SHALL be capable of tabulating votes, overvotes, and undervotes from absentee ballots.
2 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
The approach of classifying voting variations is convoluted and unworkable. This is about supported and unsupported functionality that can be turned off and on. Saying a system function is a type of device an unworkable description because whether it is turned on or off, its the same device. This comment is applicable to ALL 7.7.2 requirements.
Comment by Carolyn Coggins (Voting System Test Laboratory)
The approach of classifying Voting Variations is convoluted and unworkable. This is about supported and unsupported functionality that can be turned off and on. Hence saying absentee ballot functionality is a type of device doesn't work because whether it is turned on or off, its the same device. The implementation statement would need to describe the equipment as atabulator of the absentee and non-absentee ballot device class.
7.7.2-A.4 Tabulator, provisional-challenged ballots
Tabulators of the provisional-challenged ballots device class SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the decision whether to count a particular ballot is deferred until after election day.
3 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
When provisional ballots are on paper the process is to accept or reject the voter prior to counting the ballot. Is it correct to identify a requirement for paper based voting systems with provisional ballot functionality?
Comment by George Gilbert (Local Election Official)
7.7.2-A.4—As noted elsewhere, "provisional" and "challenged" ballots are not the only types of ballots that states require to be identifiable and retrievable, eg., North Carolina absentee ballots. The terminology we use to identify such ballots is "coded ballots." Recommend adopting this or a similar, general, designation rather that the restrictive reference to "provisional-challenged ballots."
Comment by Premier Election Solutions (Manufacturer)
The handling of overvotes, undervotes, etc. is not the definition of provisional-challenged ballots. A tabulator should be able to handle those conditions regardless as to whether the ballot is provisional, regularly cast, or an extended hours provisional ballot. Therefore this requirement needs to be changed to clarify what is being requested. Please clarify the intent of this requirement.
7.7.2-A.5 Tabulator, accept or reject provisional-challenged ballots individually
Tabulators of the provisional-challenged ballots device class SHALL support the independent acceptance and rejection of individual provisional/challenged ballots.
Applies To: Tabulator Λ Provisional-challenged ballots device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
This is meant to rule out the mode of failure in which the IDs assigned to provisional ballots fail to be unique, rendering the system incapable of accepting one without also accepting the others with the same ID.
Source: Added precision, based on [VSS2002] I.2.2.8.1, I.2.2.8.2 and glossary
1 Comment
Comment by George Gilbert (Local Election Official)
7.7.2-A.5—As noted elsewhere, "provisional" and "challenged" ballots are not the only types of ballots that states require to be identifiable and retrievable, eg., North Carolina absentee ballots. The terminology we use to identify such ballots is "coded ballots." Recommend adopting this or a similar, general, designation rather that the restrictive reference to "provisional-challenged ballots."
7.7.2-A.6 Tabulator, accept or reject provisional-challenged ballots by category
Tabulators of the provisional-challenged ballots device class SHALL support the acceptance and rejection of provisional/challenged ballots by category.
Applies To: Tabulator Λ Provisional-challenged ballots device
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
For "category," see Requirement Part 1: 7.5.3-A.17. The behavior when an individual acceptance/rejection conflicts with a categorical acceptance/rejection is system-dependent and should be documented by the manufacturer.
Source: [P1583] 5.6.5.2.s.3[5]
3 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
When provisional ballots are on paper the process is to accept or reject the voter prior to counting the ballot. Is it correct to identify a requirement for paper based voting systems with provisional ballot functionality?
Comment by George Gilbert (Local Election Official)
7.7.2-A.6—As noted elsewhere, "provisional" and "challenged" ballots are not the only types of ballots that states require to be identifiable and retrievable, eg., North Carolina absentee ballots. The terminology we use to identify such ballots is "coded ballots." Recommend adopting this or a similar, general, designation rather that the restrictive reference to "provisional-challenged ballots."
Comment by Premier Election Solutions (Manufacturer)
If this requirement is trying to state that overvoted, undervoted, etc ballots should be able to be accepted as a group then that definition needs to be clearer. Again the definition of provisional-challenged seems to be incorrect in this context. Please clarify the categories for which the tabulator must accept or reject a provisional-challenged ballot.
Tabulators of the primary elections device class SHALL be capable of keeping separate totals for each political party for the number of ballots read and counted.
Tabulators of the write-ins device class SHALL be capable of tabulating votes for write-in candidates, with separate totals for each candidate.
2 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
A write in is functionality that is either included or excluded from a contest, therefore the same system is write in voting device class and a non-write in voting device class. This approach is convoluted and unworkable.
Comment by Premier Election Solutions (Manufacturer)
If this requirement is to automatically tabluate votes for each of the write-in candidates then this assumes that the name of the write-in can be determined and is valid (note that some jurisdictions do not permit the reporting of write-in votes cast for candidates who have not met certain requirements.) For paper based systems, OCRing the write-in is not viable and is very error prone. Even for DRE systems voters mis-type or use variations of the names, so even those systems need a manual review. Proposed Change: Change this requirement to refer to the device class as "Automated Write-ins".
7.7.2-A.9 Tabulator, support write-in reconciliation
Tabulators of the write-ins device class SHALL be capable of gathering and recording votes within a voting process that allows for reconciliation of aliases and double votes.
Tabulators of the ballot rotation device class SHALL be capable of tabulating votes when the ordering of contest choices in ballot positions within each contest is variable.
2 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
Provide detailed pass/fail criteria for the various methods of rotation
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Proposed Change: Remove this requirement.
Tabulators of the straight party voting device class SHALL be capable of tabulating straight party votes.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Proposed Change: Remove this requirement.
A straight party vote SHALL be counted as a vote in favor of all contest choices endorsed by the chosen party in each straight-party-votable contest in which the voter does not cast an explicit vote.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Proposed Change: Remove this requirement.
Tabulators of the cross-party endorsement device class SHALL be capable of tabulating straight-party votes when a given contest choice is endorsed by two or more different political parties.
Tabulators of the split precincts device class SHALL be capable of tabulating votes for two or more election districts within the same precinct.
Tabulators of the N-of-M voting device class SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the voter is allowed to choose up to a specified number of contest choices (N(r) > 1, per Part 1: 8.3 "Logic Model (normative)") from a list of contest choices.
Tabulators of the cumulative voting device class SHALL be capable of tabulating votes, overvotes, and undervotes in contests where the voter is allowed to allocate up to a specified number of votes (N(r) > 1, per Part 1: 8.3 "Logic Model (normative)") over a list of contest choices however he or she chooses, possibly giving more than one vote to a given contest choice.
Tabulators of the ranked order voting device class SHALL be capable of determining the results of a ranked order contest for each round of voting.
The following subsections discuss cases for which tabulation logic is not specified in the VVSG.
5 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
Define testable pass/fail criteria for this functionality
Comment by Terrill Bouricius, FairVote: the Center for Voting and Democracy (Advocacy Group)
This should read at the end…"for each round of vote tabulation." or some such words, rather than "voting," as there is only a single round of VOTING in a ranked order voting election.
Comment by David Cary, Californian's for Electoral Reform (Advocacy Group)
It can be inappropriate to apply this requirement to all devices in the tabulator class. For example, in common configurations, it should not be required of a DRE or a precinct scanner.
Comment by Dave Kadlecek (Advocacy Group)
There are two separate but related processes in tabulating an instant runoff voting or single transferable vote election: counting the votes in each round of tabulation (using ballot information and information such as which candidates have been eliminated or elected in previous rounds) and using the count from a round of tabulation to elect or eliminate candidates, both determining whether another round is necessary and what will be counted in it if it is. One way of designing a voting system for ranked voting, used in most or all systems used to this date in the US, is for precinct level devices to simply capture ballot images which are later loaded into a central tabulator that conducts both related processes. In some systems for instant runoff voting, the precinct devices also tabulate the first round of voting, and the consolidated tallies used to determine whether the full ranked voting tabulation is necessary. Another way of designing a voting system for ranked voting, which I understand is used in presidential elections in the Republic of Ireland, separates the two processes. There, all rounds of counting are tabulated in regional counting centers that then report totals to a central headquarters. The headquarters consolidates the regional totals to determine what is needed for the next round and sends instructions to the regional counting centers. The guidelines should allow for ranked voting tabulators that cannot determine the results of a round of counting but only tabulate the ballots available to it following external instructions for a given round.
Comment by Premier Election Solutions (Manufacturer)
This requirement is redundant since it is already defined in the election programming section. If necessary have section 7.7.2-A just refer to the election programming section. Proposed Change: Remove this requirement.
7.7.2.1 Merged ballot approach to open primaries
In paper-based systems, open primaries have sometimes been handled by printing a single ballot style that merges the contests from all parties and instructing the voter to vote only in the contests applicable to a single party. This approach requires additional logic in the tabulator to support the rejection or discarding of votes that violate these special instructions, while the approach of assigning different ballot configurations to different parties does not.
Support for the merged ballot approach is not required for a tabulator to satisfy the requirements in these Guidelines for support of open primaries. Voting systems may provide this option as an extension to the Guidelines without breaking conformance.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
Define testable pass/fail criteria
7.7.2.2 Recall candidacy linked to recall question
In some jurisdictions, a vote for a candidate to replace a recalled official is counted only if the recall question on the same ballot was voted, and sometimes only if it was voted in the affirmative. Voting systems may provide this option as an extension to the Guidelines without breaking conformance.
1 Comment
Comment by Carolyn Coggins (Voting System Test Laboratory)
Define testable pass/fail criteria
7.7.2.3 Logic for counting straight party overrides
Although initially it seems obvious that a straight party override in a 1-of-M race should take precedence over a straight party vote, it is less obvious after considering the generalized case of an N-of-M race in which the number of candidates endorsed by the selected party might be less than N. Approaches supported by commercially available technology include (1) all straight party votes are cancelled when an explicit vote exists; (2) both straight party and explicit votes are counted; (3) both straight party and explicit votes are counted unless this exceeds N, in which case only the explicit votes are counted; (4) both straight party and explicit votes are counted unless this exceeds N, in which case straight party votes from the bottom of the list are dropped until the number of votes is reduced to N.
These Guidelines do not specify any particular approach to resolving straight party overrides, but the approach(es) supported are required to be described in the Voting Equipment User Documentation. See Requirement Part 2: 4.4.4-B.
3 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
After half a dozen repetative empty requirements we find a woefully inadequate discussion that provides no guidance or pass/fail criteria on straight party functionality. (Is there a requirement that says you can only have straight party voting in a general election?) This document needs to provide real testable requirements with pass/fail criteria that define and address the functionality. Here's an example: 1) A straight party mark selects all candidates of the chosen party in a general election; non partisan and questions are not selected 2) Straight party selections can be by-passed; partisan and non-partisan candidates can be individually selected 3) After a straight party selection marks candidates of one party voters can cross over and change their vote to one or more candidates of another party. 4) If there is no candidate for a selected party in a contest no candidate is automatically selected 5) If the number of candidates is < or = to N in a contest all of the chosen party's candidates are automatically selected; if N in a contest the chosen party's candidates are not automatically selected
Comment by Terrill Bouricius, FairVote: the Center for Voting and Democracy (Advocacy Group)
While it may be premature in this round to standardize algorithms, etc. the time is overdue to convene an advisory group to begin the process of developing them. Major voting machine vendors such as ES&S and Sequoia already have, or are currently having, voting systems for ranked voting tested and certified by the labs. The absence of federal guidelines in this area is a major problem for both vendors and jurisdictions that have adopted ranked voting methods. It would be appropriate to have a two step set of guidelines; containing both minimum standards for retro-fitting legacy equipment, and best-practices guidelines for future products. Premier Election Systems (Diebold), ES&S, and Sequoia have all produced firmware to handle ranked voting on some of their existing machines. However, none of these machines are using what the advocacy community consider to be best practices. For example, ideally the output from the vote capture device should be a true representation of all voter choices made, regardless of validity (e.g. rather than inserting a generic "over-vote" code the output should show exactly what choices the voter made), and leave it to the subsequent step of vote tallying software to interpret those voter "marks." All three of these vendors have produced firmware for their optical scan machines that somewhat "cleans" the data that it outputs (such as skipped rankings or duplicate rankings, etc.). This makes auditing a ranked ballot election problematic, as there is no longer a one-to-one match up of ballot to data record. Thus a best practice for future systems would require that the vote capture device store anonymous uninterpreted ballot images from each voter. Also the output file should be in a common record format, such as a comma delimited text file rather than a proprietary format, to allow double checking algorithms by running the ranked ballot election through software other than just that provided by the vendor.
Comment by David Cary, Californians for Electoral Reform (Advocacy Group)
The first paragraph should reflect the option that the system will produce reportable results up to the point that a tie-breaking situation occurs, in order to facilitate an tie-breaking procedure that is external to the voting system. The section confuses the concepts of single-winner (IRV) and multi-winner (STV / choice voting) contests with the concepts of 1-of-M and N-of-M. The former are latter varieties of ranked order voting, while the latter are separate voting variations that are not relevant to ranked order voting. The lack of specific requirements is wrongly attributed to a lack of wide-spread use. Greater use of ranked order voting may simply further diversify the variety of options in use. The lack of specific requirements should instead be attributed to a combination of the options usable by local jurisdictions and to the unmet need for well-developed federal requirements that are specific to ranked order voting. In general, an effort is needed to provide better guidelines for vendors of ranked order voting systems. In lieu of or in addition to the development of those guidelines, there should be an process for acknowledging extensions or other enhancements to the standards, similar to the vendor-initiated innovation class. Such a process could, for example, allow a state to specify extensions that could then become testable at the federal level.
7.7.2.4 Logic for reconciling write-in double votes
Reconciliation of double votes means handling the case where, in an N-of-M contest, a voter has attempted to cast multiple votes for the same candidate using the write-in mechanism. If the voter has selected a ballot position for a given candidate but also written in that candidate's name, or if the voter has written in the same candidate twice using the same spelling or different legal spellings, some corrective action is required—possibly counting only one of the votes, possibly considering the contest to be overvoted. Which action should be specified by jurisdiction election law.
Given a sufficiently robust mechanism for reconciliation of aliases, the reconciliation of double votes can be automated. Once it is known that the name written in identifies the same candidate as the previous ballot position, the tabulator can take whatever action is specified by election law.
These Guidelines do not specify any particular approach to reconciling double votes, but the approach(es) supported are required to be described in the Voting Equipment User Documentation. See Requirement Part 2: 4.4.4-C.
1 Comments
Comment by Carolyn Coggins (Voting System Test Laboratory)
Define testable pass/fail criteria for this functionality
7.7.2.5 Logic for ranked order voting
The 1-of-M case of ranked order voting, known by various names including instant runoff voting, requires the definition of criteria for breaking ties. Whereas in plurality voting the voting system need only report the vote totals, a voting system supporting ranked order voting must implement tie-breaking logic in order to be certain of reaching a reportable result.
It is also necessary to decide whether voters may assign equal rankings to two contest choices, whether voters are required to rank every choice, and how to compute a result in the case where they do not.
The N-of-M generalization, called single transferable vote, has two additional adjustable parameters: the vote quota (the number of votes required to declare a candidate elected) and the weighting or distribution of votes transferred from contest choices that exceed the quota.
Finally, to the extent that a particular ranked order variant defines certain voter responses to be partly or wholly invalid, the manner in which the votes from the affected ballots are to be accounted for and reported (analogous to the reporting of overvotes in plurality contents) must be decided.
Ranked order voting has had insufficient use in the United States to establish clear precedent on how these questions are to be answered; consequently, it would be premature to standardize any particular algorithm or set of algorithms, or attempt to accommodate every possible interpretation.
7.7.3 Ballot separation
See also Part 1: 3.2.2.2 "Non-Editable interfaces" and Requirement Part 1: 6.3.3-A.
7.7.3-A Central paper tabulator, ballot separation
In response to designated conditions, paper-based central tabulators SHALL (a) outstack the ballot (i.e., divert to a stack separate from the ballots that were normally processed), (b) stop the ballot reader and display a message prompting the election official or designee to remove the ballot, or (c) mark the ballot with an identifying mark to facilitate its later identification.
7.7.3-A.1 Central paper tabulator, unreadable ballots
All paper-based central tabulators SHALL perform this action in response to an unreadable ballot.
Paper-based central tabulators of the review-required ballots device class SHALL be able to perform this action in response to a ballot containing write-in votes.
7.7.3-A.3 Central paper tabulator, overvotes, undervotes, blank ballots
All paper-based central tabulators SHALL provide a capability that can be activated by central election officials to perform this action in response to ballots containing overvotes, blank ballots, and ballots containing undervotes in a designated race.
7.7.3-B Precinct paper tabulator, write-ins
Paper-based precinct tabulators of the review-required ballots device class SHALL have the capability, when presented with a ballot containing a write-in vote, to segregate the ballot or mark the ballot with an identifying mark to facilitate its later identification.
7.7.3-C ECOS, react to marginal marks and overvotes
ECOS SHOULD provide a capability to alert an election official when a ballot that is scanned appears to contain marginal marks or overvotes.
Applies To: ECOS
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
If an EMPB appears to contain marginal marks or overvotes, either the EBM is broken or the scanner is broken. Either way, an election official should be notified immediately. (It is possible that the voter simply disregarded instructions and marked the ballot manually.)
Source: New requirement
7.7.4 Misfed ballots
7.7.4-A Paper-based tabulator, ability to clear misfeed
If multiple feed or misfeed (jamming) occurs, a paper-based tabulator SHALL halt in a manner that permits the operator to remove the ballot(s) causing the error and reinsert them in the input hopper (if unread) or insert them in the ballot box (if read).
7.7.4-B Paper-based tabulator, indicate status of misfed ballot
If multiple feed or misfeed (jamming) occurs, a paper-based tabulator SHALL clearly indicate whether or not the ballot(s) causing the error have been read.
Requirement Part 1: 6.3.2-B applies to all voting systems and need not be repeated here. The following requirements elaborate the general requirement with respect to issues that are unique to paper-based systems.
7.7.5-A Optical scanner, ignore unmarked voting targets
Optical scanners SHALL ignore (i.e., not record as votes) unmarked voting targets to the satisfaction of Requirement Part 1: 6.3.2-B.
7.7.5-B ECOS, accurately detect marks
ECOS SHALL detect EBM-generated vote indications to the satisfaction of Requirement Part 1: 6.3.2-B.
7.7.5-C MCOS, accurately detect perfect marks
MCOS SHALL detect marks that conform to manufacturer specifications to the satisfaction of Requirement Part 1: 6.3.2-B.
7.7.5-D MCOS, accurately detect imperfect marks
MCOS SHALL detect a 1 mm thick line that is made with a #2 pencil that crosses the entirety of the voting target on its long axis, that is centered on the voting target, and that is as dark as can practically be made with a #2 pencil, to the satisfaction of Requirement Part 1: 6.3.2-B.
Applies To: MCOS
Test Reference: Part 3: 5.3.3 "Reliability"
DISCUSSION
Different optical scanning technologies will register imperfect marks in different ways. Variables include the size, shape, orientation, and darkness of the mark; the location of the mark within the voting target; the wavelength of light used by the scanner; the size and shape of the scanner's aperture; the color of the ink; the sensed background-white and maximum-dark levels; and of course the calibration of the scanner. The mark specified in this requirement is intended to be less than 100 % perfect, but reliably detectable, i.e., not so marginal as to bring the uncontrolled variables to the forefront. In plain language: scanning technologies may vary, but as a minimum requirement, all of them should be capable of reliably reading this mark.
Source: Many issues and public comments. Specification of mark originated with recommendation in Issue #1322, changed to reduce ambiguity.
7.7.5-E Paper-based tabulators, ignore extraneous outside voting targets
Paper-based tabulators SHALL NOT record as votes any marks, perforations, smudges, or folds appearing outside the boundaries of voting targets.
Applies To: Paper-based device Λ Tabulator
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
In previous iterations of these VVSG it was unclear whether "extraneous perforations, smudges, and folds" included perforations, smudges and folds appearing within voting targets. Those appearing within voting targets are now discussed in Requirement Part 1: 7.7.5-F and Requirement Part 1: 7.7.5-G. Those other requirements are "should" not "shall"—technology in wide use as of 2006 cannot reliably distinguish extraneous marks within voting targets from deliberate marks.
Marks that conflict with timing marks may cause a tabulator to reject a ballot. This is conforming behavior, as it does not result in the recording of bogus votes.
Source: Clarified from [VSS2002] I.3.2.5.2.b
7.7.5-F Optical scanner, ignore extraneous inside voting targets
Optical scanners SHOULD NOT record as votes imperfections in the ballot stock and similar insignificant marks appearing inside voting targets.
Applies To: Optical scanner
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
With technology that is in wide use as of 2006, insignificant marks appearing inside voting targets can be detected as votes. This problem should be minimized.
Source: Clarified from [VSS2002] I.3.2.5.2.b
7.7.5-G MCOS, ignore hesitation marks
MCOS SHOULD NOT record as votes hesitation marks and similar insignificant marks.
Applies To: MCOS
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
With technology that is in wide use as of 2006, it may be possible to reliably detect reasonable marks and reliably ignore hesitation marks if the scanner is calibrated to a specific marking utensil. Unfortunately, in practice, optical scanners are required to tolerate the variations caused by the use of unapproved marking utensils. Thus, lighter marks of a significant size are detected at the cost of possibly detecting especially dark hesitation marks. Emerging technologies for context-sensitive ballot scanning may solve this problem. It is also solvable through procedures that ensure that all voters use only the approved marking utensil.
Source: Clarified from [VSS2002] I.3.2.5.2.b
7.7.5.1 Marginal marks
A marginal mark is a mark within a voting target that does not conform to manufacturer specifications for a reliably detectable vote. The word "marginal" refers to the limit of what is detectable by an optical scanner, not the margin of the page. Marks that are outside of voting targets are called extraneous marks.
A marginal mark is neither clearly countable as a vote nor clearly countable as a non-vote. It is an ambiguous vote, analogous to dimpled chad on a punchcard.
The voter should always be instructed to make an ideal mark, which in a typical optical scan system means completely filling the oval with a #2 pencil. To allow for variations in the marks that diligent voters actually make when trying to follow this instruction, the accidental use of non-approved marking utensils, et cetera, optical scanners are configured to accept a relatively wide range of marks as votes (Requirement Part 1: 7.7.5-D). Marginal marks are below this range. They happen when voters do not follow instructions or the instructions are inadequate.
Although the criteria are not necessarily simple, manufacturers are required to specify what constitutes a reliably detectable mark versus a marginal mark (Requirement Part 2: 4.1.2-A.2). If this cannot be accomplished, then the voting system is counting votes using a mystery algorithm. Such a system cannot be found compliant.
A ballot that was marked with an EBM should never contain marginal marks. If it does, an equipment malfunction has occurred, and it should be handled as such (Requirement Part 1: 7.7.3-C).
In the case of precinct counting of manually-marked paper ballots, the precinct count scanner should be configured to reject ballots containing marginal marks (Requirement Part 1: 3.2.2.2-E). For example, a hypothetical optical scanner that detected marks based only on overall darkness could be configured so that a mark that was more than (30 ± 2) % dark would count as a vote, a mark that was less than (10 ± 2) % dark would count as a non-vote, and anything in between would be rejected as marginal. (These numbers are just examples to clarify the general intent, and are not necessarily fit for use in an any given election.)
The uncertainty at both ends of the marginal zone is of no consequence. A mark that was exactly 30 % dark would either be accepted as a vote or rejected as marginal and returned to the voter for clarification. Either way, it would not be mistaken for a non-vote. Similarly, a mark that was exactly 10 % dark would either be accepted as a non-vote or rejected as marginal and returned to the voter for clarification. Either way, it would not be mistaken for a vote. (Detectable marks in the lower range are typically hesitation marks, accidental smudges, or damage to the paper.)
In the central count case, rejection of marginal marks is only helpful if someone is going to examine each affected ballot and judge the intent of the voter. If this is not going to occur, then it is preferable to disable the detection of marginal marks so that every mark is counted either as a vote or as a non-vote. Unfortunately, it is not technically possible to do this without creating the potential for irreproducible tabulation results. For example, if a hypothetical optical scanner that detected marks based only on overall darkness were calibrated to distinguish votes from non-votes using a threshold of (25 ± 2) % darkness, the detection of marks that were between 23 % and 27 % dark would not reproduce on a different scanner of the same kind. Moreover, the detection of marks that happened to fall very close to the actual detection threshold of the scanner as calibrated would not repeat on the same scanner. As the darkness of a mark (or whatever the scanner is measuring) approaches the detection threshold, the signal-to-noise ratio approaches zero. At some point, the noise determines the result that is tabulated.
Short of banning the use of manually-marked paper ballots, which would create a crisis for absentee voting, the best that can be done for this central count case is to prohibit bias in the detection of marginal marks (Requirement Part 1: 7.7.5.1-A) and advise that the detection of marginal marks be made as repeatable as possible (Requirement Part 1: 7.7.5.1-B).
2 Comments
Comment by E Smith/J Homewood (Manufacturer)
Comment There shall NOT be a bias, the not was left out.
Comment by E Smith/J Homewood (Manufacturer)
This says that detection of marginal marks should be repeatable and yet in the previous page it notes that marks near the edge of the marginal limits may or may not read. This should be changed to account for this condition.
1 Comment
Comment by Kevin Wilson (Voting System Test Laboratory)
The detection … SHALL not show a bias, instead of SHALL show a bias?
7.7.5.1-B MCOS, marginal marks, repeatability
The detection of marginal marks from manually-marked paper ballots SHOULD be repeatable.
Applies To: MCOS
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
It is difficult to have confidence in the equipment if consecutive readings of the same ballots on the same equipment yield dramatically different results. However, it is technically impossible to achieve repeatable reading of ballots containing marks that fall precisely on the sensing threshold. See Part 1: 7.7.5.1 "Marginal marks".
Source: New requirement
7.7.6 Consolidation
Precinct EMSs SHALL consolidate the data contained in each unit into a single report for the polling place when more than one vote-capture device or precinct tabulator is used.
DREs SHALL, if the consolidation of polling place data is done locally, perform this consolidation in a time not to exceed 5 minutes per DRE.
Applies To: Precinct tabulator Λ EMS Λ DRE
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
This requirement assumes that the precinct is operating using DREs exclusively and that one of those DREs fills the role of EMS.
Source: Reworded from [VSS2002] I.3.2.6.2.1
7.7.7 Procedures required for correct system functioning
The requirements for voting systems are written assuming that these procedures will be followed.
Paper-based tabulator, clearing misfeeds when ballot was read: If it is necessary to clear a misfed ballot that was read by a paper-based tabulator but became stuck on its way to the ballot box, election judges or central election officials must perform this task in the presence of a witness. If an audit found that the contents of the ballot box and the records from the tabulator did not match, one would want to be able to rule out the possibility that something made its way into the ballot box while the tabulator was disconnected.
7.8 Reporting
Although reporting is typically an EMS function, most of the requirements in this section are scoped to the entire system because any given EMS might not generate all of the specified information. For example, the precinct- and system extent-level reports might be generated by different EMSs located in the precinct and central location, respectively. The precinct EMSs need not have the capability to generate system extent-level reports and vice-versa.
7.8.1 General reporting functionality
All reports SHALL include the date and time of the report's generation, including hours, minutes, and seconds.
Applies To: Voting system
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
Even if the clock's accuracy leaves something to be desired, second precision is useful to have if two reports are generated in quick succession.
Source: New requirement
7.8.1-B Timestamps should be ISO 8601 compliant
Timestamps in reports SHOULD comply with ISO 8601 [ISO04], provide all four digits of the year and include the time zone.
7.8.1-C Reporting is non-destructive
All programmed devices SHALL prevent data, including data in transportable memory, from being altered or destroyed by report generation.
Applies To: Programmed device
Test Reference: Part 3: 4.3 "Verification of Design Requirements"
DISCUSSION
The appending of an audit record reflecting the fact that a report has been generated is not considered an alteration.
Source: From [VSS2002] I.2.2.6.h, I.2.5.3.1.g, and I.2.5.3.2.d
7.8.2 Audit, status, and readiness reports
All systems SHALL be capable of producing reports of the event logs defined in Part 1: 5.7 "System Event Logging".
The EMS SHALL provide the capability to obtain a report that includes:
- The allowable number of votes in each contest;
- The combinations of voting patterns permitted or required by the jurisdiction;
- The inclusion or exclusion of contests as the result of multiple districting within a polling place;
- Any other characteristics that may be peculiar to the jurisdiction, the election or the precincts;
- Manual data maintained by election personnel;
- Samples of all final ballot styles; and
- Ballot preparation edit listings.
1 Comment
Comment by Premier Election Solutions (Manufacturer)
Item (d) is not testable since it is undefined. Proposed Change: Remove item (d) from this requirement.
All programmed devices SHALL provide the capabilities to obtain status and equipment readiness reports.
7.8.2-D Readiness reports, per polling place
Readiness reports SHALL include at least the following information for each polling place:
- The election's identification data;
- The identification of the precinct and polling place;
- The identification of all voting devices deployed in the precinct;
- The identification of all ballot styles used in that precinct;
- Confirmation that no hardware or software failures were detected during setup and testing, or a record of those that occurred; and
- Confirmation that all vote-capture devices are ready for the opening of polls, or identification of those that are not.
Applies To: In-person voting
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
In jurisdictions where there are no programmed devices in the precincts, confirmation of equipment readiness could occur through a manual check and signoff by election judges. These readiness reports could take the form of checklists, fill-in forms and signature sheets supplied to the precincts by a central authority.
Source: [VSS2002] I.2.3.5, separated generic precinct vs. precinct tabulator reqs, modified to deal with failures
7.8.2-E Readiness reports, precinct tabulator
Readiness reports SHALL include the following information for each precinct tabulator:
- The election's identification data;
- The identification of the precinct and polling place;
- The identification of the tabulator;
- The contents of each active contest choice register at all storage locations;
- Confirmation that no hardware or software failures were detected during setup and testing, or a record of those that occurred; and
- Any other information needed to confirm the readiness of the equipment and to accommodate administrative reporting requirements.
7.8.2-F Readiness reports, central tabulator
Readiness reports SHALL include the following information for each central tabulator:
- The election's identification data;
- The identification of the tabulator;
- The identification of all ballot styles used in the system extent;
- The contents of each active contest choice register at all storage locations;
- Confirmation that no hardware or software failures were detected during setup and testing, or a record of those that occurred; and
- Any other information needed to confirm the readiness of the equipment and to accommodate administrative reporting requirements.
7.8.2-G Readiness reports, public network test ballots
Systems that send ballots over a public network SHALL provide a report of test ballots that includes:
- The number of test ballots sent;
- When each test ballot was sent;
- The identity of the machine from which each test ballot was sent; and
- The specific votes contained in the test ballots.
7.8.3 Vote data reports
The requirements in this section specify a minimum set of information that a voting system must report. They do not prohibit any voting system from reporting additional information that may be required by jurisdictions or merely found to be useful.
Similarly, the identification of four "standard" reporting contexts (tabulator, precinct, election district, and system extent) requires voting systems to support these at a minimum, but does not prohibit any voting system from supporting additional reporting contexts or from offering a generalized facility through which central election officials may define arbitrary reporting contexts.
7.8.3.1 General functionality
All devices used to produce reports of the vote count SHALL be capable of producing:
- Alphanumeric headers;
- Election, office and issue labels; and
- Alphanumeric entries generated as part of the audit record.
All systems SHALL be able to produce an accurate, human-readable report of all votes cast.
Applies To: Voting system
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
Binary document formats and text containing markup tags are not considered human-readable. The system may generate such documents, but it must also provide the functionality to render those documents in human-readable form (e.g., by including the necessary reader application).
Source: [VSS2002] I.2.2.2.1.c as expanded by [P1583] 5.2.1.1.c[5]
7.8.3.1-C Account for all cast ballots and all valid votes
All systems SHALL produce vote data reports that account for all cast ballots and all valid votes.
7.8.3.1-D Vote data reports, discrepancies can't happen
Vote data reports SHALL be completely consistent, with no discrepancy among reports of voting device data at any level.
7.8.3.1-D.1 Discrepancies that happen anyway must be flagged
Any discrepancy that is detectable by the system SHALL be flagged by the system by an annotation or error message in the affected report(s) and/or a separate discrepancy report.
Test Reference: Part 3: 4.6 "Logic Verification", 5.2 "Functional Testing"
DISCUSSION
If this requirement is applicable, then the system has failed to satisfy Requirement Part 1: 7.8.3.1-D and is therefore non-conforming. Nevertheless, in practice it is essential that discrepancies be flagged by the system as much as possible so that they are not overlooked by election judges. The system cannot detect discrepancies if no single voting device is ever in possession of a sufficient set of data.
Source: New requirement in response to Issue #1366
7.8.3.1-D.2 Discrepancies that happen anyway must be explainable
Any discrepancy in reports, regardless of source, SHALL be resolvable to a specific cause.
All systems SHOULD be capable of generating reports that consolidate vote data from selected precincts.
Applies To: Voting system
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
Jurisdictions in which more than one precinct may vote at the same location on either the same ballot style or a different ballot style may desire reports that consolidate the voting location.
Source: Derived from [ND06] 5.04.05.g, [UT04] Requirement 23 and [MS05] 14.3.2.3
1 Comment
Comment by Gail Audette (Voting System Test Laboratory)
This requirement states that discrepancies SHALL not occur but the next two requirements (D.1 and D.2) are requriements for when discrepancies occur. Please clarify how/why a non-conforming system is released for use and the election judges then need this information.
7.8.3.1-F Precinct tabulators, no tallies before close of polls
Precinct tabulators SHALL prevent the printing of vote data reports and the extraction of vote tally data prior to the official close of polls.
Applies To: Precinct tabulator
Test Reference: Part 3:4.5.2 "Security", 5.4 "Open-Ended Vulnerability Testing"
DISCUSSION
Providing ballot counts does not violate this requirement. The prohibition is against providing vote totals. Ballot counts are required for ballot accounting, but early extraction of vote totals is an enabler of election fraud.
Source: Revised from [VSS2002] I.2.5.3.2
Source for Requirement Part 1: 7.8.3.3-A through Requirement Part 1: 7.8.3.3-I: These requirements were distilled, refactored, and clarified from overlapping, subtly differing requirements appearing several places in Chapters 2 and 4 of [VSS2002], including: I.2.2.2.1.c (produce an accurate report of all votes cast), I.2.2.6.h (printed report of everything in I.2.5), I.2.2.9 (ballot counter), I.2.5.2 (means to consolidate vote data), I.2.5.3.1.a (geographic reporting), I.2.5.3.1.b (printed report of number of ballots counted by each tabulator), I.2.5.3.1.c (contest results, overvotes, and undervotes for each tabulator), I.2.5.3.1.d (consolidated reports including other data sources), I.4.4.4.a (number of ballots cast, using each ballot configuration, by tabulator, precinct, and political subdivision), I.4.4.4.b (candidate and measure totals for each contest, by tabulator), I.4.4.4.c (number of ballots read within each precinct and for additional jurisdictional levels, by configuration, including separate totals for each party in primary elections), I.4.4.4.d (separate accumulation of overvotes and undervotes for each contest, by tabulator, precinct, and additional jurisdictional levels), and I.4.4.4.e (for paper-based systems, the total number of ballots both processed and unprocessable, and the total number of cards read).
All voting systems SHALL report the number of cast ballots in the precinct, election district, and system extent reporting contexts, both in total and broken down by ballot configuration.
Applies To: Voting system
Test Reference: Part 3: 5.2 "Functional Testing"
DISCUSSION
In the case of 100 % DRE systems, it would suffice to provide a single total that is noted to represent both the number of cast ballots and the number of read ballots, since these are necessarily equal. Only when there is a tangible (i.e., paper) ballot is it possible to cast a ballot that is never read. There is no subrequirement for separate reporting of provisional cast ballots because the system is unlikely to know whether a ballot is provisional until it is successfully read.
2 Comments
Comment by Robert Ferraro, SAVEourVotes.org (Advocacy Group)
There should be a new, separate, almost opposite requirement that all systems which may be used for centrally counting ballots should be able to generate reports that separate counts and subtotals by batch. In particular, central count optical-scan machines should be able to subtotal and store results for batches of ballots. This feature is especially important for many states where absentee ballots and provisional ballots make up a large fraction of the total. The cost of an audit depends on several factors, including the number of samples needed. The number of samples needed (and thereby the cost) can be reduced by having smaller audit units. With centrally based optical-scan systems for absentee ballots, it is more cost effective to group the ballots into batches and then consider each batch as a separate audit unit than to consider all the ballots together in one audit unit. Although batching centrally counted ballots can drastically reduce audit costs, some current systems do not support such batching.
Comment by Verified Voting Foundation (Advocacy Group)
There should be a new, separate requirement that all systems which may be used for centrally counting ballots should be able to generate reports that separate counts and subtotals by batch. In particular, central count optical-scan machines should be able to subtotal and store results for batches of ballots. This feature is especially important for many states where absentee ballots and provisional ballots make up a large fraction of the total. The cost of an audit depends on several factors, including the number of samples needed. The number of samples needed (and thereby the cost) can be reduced by having smaller audit units. With centrally based optical-scan systems for absentee ballots, it is more cost effective to group the ballots into batches and then consider each batch as a separate audit unit than to consider all the ballots together in one audit unit. Although batching centrally counted ballots can drastically reduce audit costs, some current systems do not support such batching or make it difficult to keep track of batch sub-totals.
All systems SHALL report the number of read ballots in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.
Systems that include paper-based devices SHALL, if there are multiple card/page ballots, report the number of cards/pages read in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.
Systems conforming to the primary elections class SHALL report separate totals for each party in primary elections.
Systems conforming to the provisional-challenged ballots class SHALL report the number of provisional-challenged read ballots in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.
1 Comment
Comment by George Gilbert (Local Election Official)
7.8.3.2-A—In the case of DRE systems, it would be desirable, and feasible, to report the number of "provisional" ballots cast in each category. Provisional ballots cast on a DRE machine would be identifiable, without reading the ballot, by the "credentials" provided by the activating "token." A readily available report of the number of such ballots would be extremely useful to election administrators and likely highly desirable by the candidates.
All systems SHALL report the number of counted ballots in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.
Systems conforming to the primary elections class SHALL report separate ballot counts for each party in primary elections.
Systems conforming to the provisional-challenged ballots class SHALL report the number of provisional-challenged counted ballots in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.
All systems SHOULD report the number of blank ballots (ballots containing no votes) that were counted in each reporting context (tabulator, precinct, election district, and system extent), both in total and broken down by ballot configuration.
Applies To: Part 3: 5.2 "Functional Testing"
DISCUSSION
Some jurisdictions find this information to be useful. Blank ballots sometimes represent a protest vote.
All systems SHALL report the number of counted ballots for each relevant N-of-M or cumulative voting contest, in each reporting context (tabulator, precinct, election district, and system extent), per the definition of K(j,r,tE) in Part 1: Table 8-2.
For the source of these requirements, please see the note in Part 1: 7.8.3.2 "Ballot counts".
7.8.3.3-A Report votes for each contest choice
All systems SHALL report the number of overvotes for each relevant N-of-M or cumulative voting contest, in each reporting context (tabulator, precinct, election district, and system extent), per the definition of O(j,r,tE) in Part 1: Table 8-2 and Part 1: 8.3.3 "Cumulative voting".
All systems SHALL be capable of producing a consolidated report of the combination of overvotes for any contest that is selected by an authorized official (e.g., the number of overvotes in a given contest combining candidate A and candidate B, combining candidate A and candidate C, etc.).
1 Comment
Comment by Premier Election Solutions (Manufacturer)
Overvotes can only occur with manually marked paper ballots and, in a precinct count environment, only if those overvotes are over-ridden when the ballot is cast. In all cases, overvoted contests are not counted and are considered blank contests. It seems arbitrary that the system SHALL be required to be capable of producing reports of this nature. This requirement seeks to capture overvote data that has no bearing on tallies or audits and is redundant information, unless the intent is to gather data to make anecdotal references to any patterns that might be exhibited in the data. Otherwise the data is of no use. If this requirement is for no valuable purpose, then it should be changed from a SHALL to a SHOULD. Proposed Change: Change this requirement from a SHALL to a SHOULD. Otherwise please provide discussion in the VVSG as to the value of this data.
All systems SHALL report the number of undervotes for each relevant N-of-M or cumulative voting contest, in each reporting context (tabulator, precinct, election district, and system extent), per the definition of U(j,r,tE) in Part 1: Table 8-2 and Part 1: 8.3.3 "Cumulative voting".
7.8.3.3-D Ranked order voting, report results
Systems conforming to the ranked order voting class SHALL report the contest choice vote totals for each ranked order contest for each round of voting/counting at the system extent level.
1 Comment
Comment by Terrill Bouricius, FairVote: the Center for voting and Democracy (Advocacy Group)
Eventually these guidelines should require at polling places, precinct systems should be able to report at least the number of first preferences for each contest choice. In the long term, the precinct machine should be able to print a total of each of the rankings received by each of the contest choices. This information is not useful for tallying the election, to know who won, but is a security function to allow a complete audit after the election is completed. None of the major vendors currently have this capacity, but future systems should be required to have this capability.
Systems conforming to the in-person voting class SHALL include all votes collected from In-person voting in the consolidated reports.
2 Comments
Comment by George Gilbert (Local Election Official)
7.8.3.3-E—The distinction between "in-person" votes and "absentee" votes is not reflective of the practices among the states. Many states classify all early votes, whether in-person or by-mail as "absentee" votes, eg. North Carolina. This, in the proposed VVSG definitions, produces significant overlap in the definitions for these terms.
Comment by Premier Election Solutions (Manufacturer)
Systems conforming to the absentee voting class SHALL include all votes from absentee ballots in the consolidated reports.
Systems conforming to the write-ins class SHALL include all write-in votes in the consolidated reports.
7.8.3.3-H Include accepted provisional-challenged votes
Systems conforming to the provisional-challenged ballots class SHALL include all votes from accepted provisional/challenged ballots in the consolidated reports.
Systems conforming to the review-required ballots class SHALL include all votes from accepted reviewed ballots in the consolidated reports.
7.8.4 Procedures required for correct system functioning
The requirements for voting systems are written assuming that these procedures will be followed.
Ballot accounting: All precincts must account for all ballots pursuant to the current best practices for ballot accounting.
Label unofficial reports: Any unofficial reports must be clearly labeled as unofficial. ([VSS2002] I.2.5.4.c, converted to procedural requirement.)