Federal Voluntary Voting System Guidelines: Summary and Analysis of Issues
Released: 2005-11-09T00:00:00

Historical Context of the Guidelines

The VSS were developed in response to concerns raised in the 1970s and 1980s about thethen largely unregulated voting technology industry. In 1977, an FEC advisory panel recommendedthe development of voluntary standards, following an FEC-requested study released in 1975 by theNational Bureau of Standards (renamed the National Institute of Standards and Technology, NIST,in 1988). Two years later, Congress enacted legislation directing the FEC to perform a study on thematter in cooperation with the National Bureau of Standards. The study, submitted to Congress in1984, reaffirmed the advisory panel's recommendation, and the FEC received federal funding overthe next several years to develop the VSS; however, Congress did not establish the VSS specificallyby statute (see CRS Report RS21156 , Federal Voting Systems Standards and Guidelines:Congressional Deliberations , by by [author name scrubbed] for more detail about congressionaldeliberations).

The VSS were first released in 1990. They applied to computer-based voting systems --namely, punchcard, marksense (optical scan), and direct recording electronic (DRE) systems. Theywere developed for both hardware and software and included functional and documentationrequirements, performance characteristics, and testing procedures. No standards were developed forlever-machine or hand-counted paper ballot systems.

The FEC developed a plan to implement the VSS through cooperative action by the FEC,NIST, a set of laboratories that would be called the independent test authorities (ITAs), state andlocal governments, and voting system vendors. Under the plan, states would adopt the standards andthe ITAs would test voting systems to determine whether they met the standards. NIST's intendedrole was to assist in accreditation of the ITAs. However, the plan did not materialize as originallyconceived. Instead, the National Association of State Election Directors (NASED), which wasestablished in 1989, appointed a voting systems board (1) to choose ITAs and administer a process for qualifying votingsystems under the VSS . The testing program began in 1994. NASED chose The Election Center,a professional organization of election officials, to serve as the secretariat for voting systemqualification.

States began adopting the VSS, with some requiring that voting systems be qualified underthe standards before being used in the state, and others adopting elements of the VSS into staterequirements. As implementation proceeded and technology continued to evolve, calls increased forrevising and updating the VSS . The FEC began a project to update the standards in 1997. Thesecond version was approved by the FEC in May 2002. The revision took a broader approach thanthe original version, focusing on the voting medium -- paper-based versus electronic -- rather thanspecific kinds of voting systems. It also included or expanded coverage of functions andrequirements not in the original version -- such as accessibility and some aspects of usability,telecommunications, and audit trails.

While this update was underway, Congress was considering legislation to respond to theproblems that arose in the November 2000 presidential election. The enacted version, HAVA, theHelp America Vote Act of 2002 ( P.L. 107-252 ), was signed into law in October 2002. It includesvoting system requirements and an administrative structure for promulgating standards and certifyingsystems. The act established the EAC and assigned it responsibility for developing the VVSG. Italso created three bodies -- a Standards Board, a Board of Advisors, and a Technical GuidelinesDevelopment Committee (TGDC) -- to provide advice on standards and other matters; and it gaveNIST a substantial role. For example, it made the director of NIST the chair of the TGDC. Sec. 222of HAVA effectively renamed the VSS as the Voluntary Voting System Guidelines ( VVSG ), (2) to be developed by the EACpursuant to recommendations by the TGDC and with support from NIST. Thus, HAVA provideda statutory basis for the VSS . HAVA does not direct the EAC to include any specific issues in theguidelines. However, in the debate on the House floor before passage of the HAVA conferenceagreement on October 10, 2002, a colloquy ( Congressional Record, daily ed., 148: H7842) stipulatedan interpretation that the guidelines specifically address the usability, accuracy, security,accessibility, and integrity of voting systems. Also, Sec. 221(e) requires NIST to provide supportto the TGDC for development of guidelines relating to security, voter privacy, human factors, remotevoting, and fraud detection and prevention.

The current VSS will serve as the guidelines until new ones are completed. Work ondevelopment of the first version of the VVSG, a partial revision of the VSS, began in 2004 with theappointment of the TGDC. That committee transmitted its recommendations, in the form of aproposed version 1 of the VVSG, to the EAC on May 12, 2005. After reviewing the recommendedguidelines and making some revisions, mostly but not entirely of an organizational nature, (3) the EAC released the draft VVSG on June 27, 2005, for a 90-day public comment period, with adoption initially anticipated inOctober 2005. (4) They willgo into effect two years after being adopted. (5)

HAVA also requires the EAC to provide for testing and certification of voting systems (Â§231)by laboratories it has accredited, with support from NIST, thereby transferring that responsibilityfrom NASED. The act stipulates that the current system of NASED certification will continue untilthe EAC adopts its replacement. HAVA does not specify whether the guidelines it establishes areto be used as the standard against which voting systems are tested and certified, but that is how the VSS have been used, and it is how the EAC intends to use the VVSG . (6)

NIST began the process of soliciting applications for accreditation in June 2005, under itsNational Voluntary Laboratory Accreditation Program (NVLAP). (7) It will make recommendationsthrough this program on accreditation of individual laboratories. Because of the length of theaccreditation process, in August the EAC adopted a resolution to provide temporary accreditationto the laboratories (ITAs) accredited by NASED. (8)

Summary of Guidelines

Most sections of the draft version of the VVSG released for public comment are virtuallyidentical to those in the 2002 update of the VSS . That was a consequence of a stated intent by theEAC to create a version that could be used in preparation for the 2006 election cycle. (9) Consequently, major revisionfocused mainly on usability and certain aspects of security. Major changes included

addition of a conformance clause;

revised and expanded standards for accessibility and usability;

revised standards for security, including voter-verified paper ballots used withelectronic voting machines (DREs) (10) ;

some changes to testing procedures; and

some new and expanded appendices.

A more extensive revision is reportedly underway. (11) A brief summary ofprovisions in the current draft is provided below, and a section-by-section summary is included atthe end of this report in Appendix 1. These summaries are intended only to aid in understanding thebasic scope and contents of the guidelines from a legislative perspective; other writers might chooseto emphasize different aspects.

The VVSG, like the VSS, are divided into two volumes. Volume I provides performanceguidelines for voting systems and is intended for a broad audience. It includes descriptions offunctional requirements and performance standards, as well as requirements for vendors in qualityassurance and in configuration management, a complex discipline that involves ensuring that asystem and its components function in the ways they are specified to function under variousmodifications and throughout their life cycles. It includes an extensive glossary and references,suggested practices for election officials in some areas covered by the guidelines, and discussion ofverification concepts for future design of voting systems.

Volume II provides details of the testing process for certification of voting systems. It isaimed at a narrower audience of vendors, testing laboratories, and election officials. It includes adescription of the data that vendors are required to provide when submitting a system for testing, andbasic requirements for testing against the standards described in Volume I. It also provides guidanceand requirements for testing laboratories in planning tests and reporting certification results.

Issues Raised by Guidelines

Many of the issues described below, as well as a number of more specific ones, have beencaptured in the various public comments made on the draft VVSG . (12) Commenters includeelection officials, vendors, academic researchers, representatives of professional associations andinterest groups, and members of the public. However, the discussion is not limited to issues raisedin the comments.

Technical Guidelines versus Regulatory Requirements

The VVSG, like the VSS before them, are voluntary technical standards, not regulatoryrequirements. Such standards are usually developed through a consensus process. They are commonin industry, and federal law encourages their use by federal agencies. (13) Some observers believethat making standards voluntary at the federal level cannot ensure sufficient quality of voting systemsand that adherence should be mandatory or at least a condition of receiving any federal grants forvoting equipment. (14) Others state that mandatory standards would give too large a role to the federal government andreduce the flexibility of state and local governments to respond to their specific needs. They alsopoint out that most states have adopted the VSS in whole or in part -- many require that any newvoting systems purchased adhere to the VSS or VVSG . The practical effect of such state requirementsis that voting system vendors can successfully market systems only if they are certified under the VSS or VVSG . In this sense, the provisions have acquired some of the force of regulation, in that they aretreated by manufacturers as requirements. Comments by vendors often reflect that perception.

HAVA addresses this controversy by establishing some specific requirements for votingsystems (Sec. 301), but leaving the method of implementation to the states (Sec. 305). The act islargely silent on the relationship between the VVSG and the Sec. 301 requirements. (15) The EAC is required toprovide guidance for implementing the requirements (Sec. 311--312), but the guidance is not atechnical standard and its use is also voluntary.

What Standards Can and Cannot Do

There are many different kinds of standards. They may be classified according topurpose -- e.g., product, process, testing, or interface standards. They can also be classifiedaccording to their focus -- commonly, a distinction is made between performance standards,which focus on function, and design standards, which specify features, dimensions, or othersuch characteristics. (16) A third classification is based on how standards aredeveloped and implemented. They may be developed through consensus or some otherprocess. They may be implemented voluntarily, or they may also be imposed, for example bylaw, and therefore mandatory. Standards may also be open or proprietary, but differentobservers define "open standard" somewhat differently. Some form of open standards is theapproach used typically by major standards organizations such as the American NationalStandards Institute (ANSI). (17)

The VVSG and the VSS before them do not fall neatly into any one of the abovecategories. They combine product, process, and testing requirements. They are intended tobe performance-based, but in some cases they provide fairly specific design details. That hasbeen criticized by some observers as not providing sufficient flexibility for innovation, butit has been praised by others as providing more precise requirements. The VVSG have alsobeen criticized, on the one hand, for being too precise and detailed, and on the other, for beingtoo vague and ambiguous. (18) Also, they are voluntary at the federal level but mandatoryin a number of states. Finally, the process of development of the VSS might best be describedas having been only partially open. With the involvement of NIST and the various EACboards and committees, the development of the VVSG is arguably more closely akin to atypical consensus process for standards development.

Properly designed standards can provide a clear baseline of expected performance. In conjunction with a well-implemented certification program, they can provide assurancesto all parties that voting systems will operate according to specifications. The VSS and theNASED certification program are widely credited with having greatly improved theperformance of voting systems in several areas, such as reliability and accuracy.

However, standards can address only those issues that were considered by thedevelopers, and the way that the standards are developed and implemented can also affect theway issues are addressed. Those factors can lead to at least two kinds of problems. First,specifications and testing might not reflect real-world conditions. That has been a criticismof the VSS and especially certification testing, which was done in a laboratory testingenvironment rather than realistically simulated election conditions. Thus, consideration oferror rates in the 1990 VSS was limited to machine error and did not take into account the kindof voter error that became such a central issue in the 2000 presidential election.

Second, standards may not be able to anticipate changed conditions. This is especiallytrue for rapidly evolving information technology. For example, the security weaknesses foundover the past few years in some DREs (19) were discovered in systems that had been certified underthe VSS . (20) Those 1990 standards could not anticipate the rapid evolution of information technology andthe kinds of security threats to which it would be subjected.

The Development Process for the VVSG

HAVA created a relatively complex process for the development of the VVSG . Proposed guidelines are developed by a technical committee chaired by the director of NIST. Those are then considered by two EAC boards -- the Standards Board, consisting of state andlocal election officials from all the states, and the Board of Advisors, consisting ofrepresentatives of various groups specified in the act -- and finally, by the EACcommissioners, after a public comment period.

Even without that complexity, the development of standards can involve lengthydeliberations. That is especially true for consensus standards, (21) but even the twoversions of the VSS took years to develop. International standards are often updated on athree- to five-year cycle. HAVA does not specify an updating cycle for the VVSG, althoughSec. 215(a)(2) requires the Standards Board and the Board of Advisors to meet at least oncea year "for purposes of voting on the voluntary voting system guidelines referred to itâ¦," andSec. 301(c) requires that guidance for the implementation of requirements be updated everyfour years. The first version of the VVSG, currently under EAC consideration, is notanticipated to go into effect until two years after adoption. (22) That implies aninitial revision cycle of at least two years, although the TGDC has already begun work on thesecond version.

Some observers believe that a four-year development cycle is desirable, to permitsystems to be used for two federal election cycles without requiring recertification. Othershave criticized the process for development of the VVSG as being too slow and cumbersome,given the rapid development of information technology and associated issues. Others pointout that rapid development and frequent revision could create serious financial and logisticaldifficulties for both vendors and election officials in trying to conform to the guidelines, aswell as having a potentially negative impact on the quality of any revisions. This issue hasbeen raised not only with respect to the release and effective date of the current VVSG draft,but also subsequent revisions. There appears to be an inherent conflict in responsiveness ofthe guidelines to, on the one hand, evolving needs and technology and, on the other, time andcost constraints inherent in responding appropriately to such changes. Achieving the rightbalance between them is likely to be difficult.

The Internet Engineering Task Force (IETF), a professional group involved in theevolution of Internet architecture, has addressed the challenge of rapid development andchange by creating a system for developing standards that is performed largely online. Interested parties form a working group that is completely open to anyone interested. Thereis no active attempt by the IETF to guarantee a balance among different interests. The groupidentifies the scope of a standard and begins developing it. Drafts are posted online andcomments incorporated. Once the group reaches a rough consensus, the draft is sent to theInternet Engineering Steering Group (IESG) for independent review, after which the draft maybecome a standard through some additional steps. (23) According to some observers, the use of such a fully open,online process, rough consensus, and independent review results in "cleaner" standards anda more rapid process than the more traditional approach. Whether the method could beadapted for the VVSG is not clear, especially given the complexities inherent in both the goalsof the guidelines and much voting technology. An attempt to use such an approach has beendeveloped for the purpose of creating performance ratings for voting systems but has not yetled to any public results. (24)

Another issue has to do with how other accepted standards are used and incorporatedin the VVSG . For example, the draft guidelines reference many NIST standards publicationsthat are generally designed for use by federal agencies under the Federal Information SecurityManagement Act (FISMA). (25) Some observers argue that product standards such as theCommon Criteria (ISO/IEC 15408), which provides a set of evaluation criteria for the securityof information technology, (26) would be more appropriate.

Certification Process

The development of plans for certification testing is also an issue. Volume II of the VVSG specifies that testing laboratories are to develop explicit plans for the certificationtesting. Some observers believe that those plans, like the VVSG itself, should be public andthat opportunities for public comment should be given before they are finalized. However,since the plans are to be designed for each submitted system and based on the data providedby the vendor, it is not clear that public disclosure would be possible without releasingproprietary information. Similar concerns have been raised with respect to the call from someobservers that the results of the certification testing be made publicly available. Some arguethat making such information public would be a disincentive to investment and innovationby industry. Others disagree and state further that, given the important role that votingsystems play in the democratic process, the public trust is best served by full disclosure.

Some observers have also raised questions about the methods for determining howtesting laboratories are chosen. Under the NASED process, there has been little to nocompetition among different laboratories. Critics have expressed concern that the result hasbeen higher costs for certification testing and barriers to the timely certification of systemsfrom smaller, innovative manufacturers. The NVLAP accreditation process being developedunder EAC auspices is expected to address such concerns by increasing the number oflaboratories involved. However, this approach has also been criticized: "[W]hen testingauthorities compete against each other for business, a vendor can select the authorities mostfavorable to its products or negotiate for advantageous testing procedures." (27) Those critics arguethat government or nonprofit testing centers would be a better approach.

The Scope and Features of Revisions in the VVSG

The VSS were criticized for inadequately addressing usability, security, administrativeprocedures and practices, performance in actual use, voter registration systems, and otheraspects of election administration. Those criticisms have been partially addressed in the VVSG . As described in the section above summarizing the guidelines, the TGDC decided toproduce only a partial revision of the VSS as the first version of the VVSG . Except for newsections on human factors (usability and accessibility) and security, and the addition of somenew appendices, the VVSG is largely unchanged from the 2002 version of the VSS .

The two major areas of revision are arguably the most important for immediate action,since usability and accessibility are major focuses of HAVA voting system requirements, andsecurity concerns have been prominent in recent public debate about voting systems,especially DREs. Some observers welcome this restricted focus, believing that limitedchanges are more likely to be implementable in the short term. Others, however, believe thatbroader changes to the VSS are more urgently needed and that the draft VVSG should havebeen more thoroughly revised with more stringent requirements. Some believe that an"end-to-end" or "life cycle" approach is needed, and that standards or guidelines should bedeveloped for technology, procedures, and personnel across all entities involved in electionadministration, ranging from developers and manufacturers of voting systems to pollworkers. It is not yet clear to what extent future versions of the VVSG may take such an approach. Stillother observers have expressed concerns that the first version of the VVSG has created morenew requirements for certification than is prudent for an interim document, which is intendedto be followed by a more complete revision. (28) Those observers propose delaying adoption of the VVSG until it can be thoroughly revised. (29)

Yet others believe that the added provisions are inadequate to meet accessibility,alternative language, and security needs and that broader and more stringent requirements areneeded. For example, some of the provisions in the sections on human factors and securityhave been criticized for being recommendations rather than requirements, the concern beingthat they do not therefore ensure full compliance with HAVA's accessibilityrequirements. (30) There is also concern among some that the VVSG do not adequately cover the full range ofdisabilities as required by HAVA. Disabilities that are specifically addressed relate to vision,dexterity, mobility, hearing, speech, and cognitive function, although little to no detail isprovided for the last two. There are several different ways to categorize disabilities, and the VVSG provide neither a source for the list used nor any indication of how exhaustive it isintended to be. The guidelines also state, "As a practical matter, there may be a small numberof voters whose disabilities are so severe that they will need personal assistance." (31)

The revised security provisions have also raised questions among some observers. Forexample, some state-sponsored studies used penetration testing -- deliberate attempts to breakinto voting systems -- in attempting to address security issues associated with votingsystems. (32) Thisis a fairly common technique in security testing, and some observers believe that it should berequired by the guidelines. Other observers have expressed concern that some of the differentrequirements may be conflicting -- that meeting one will require violating another.

Some have also pointed to concerns about specific elements of the VSS that were notexamined by the TGDC. One particularly contentious provision is the requirement thatfailures occur no more often than every 163 hours of use. (33) Some observersargue that this is far too low, permitting 10% of precinct-based electronic systems to failduring an election. (34) Others argue that the more relevant standard is availability-- which stipulates that the time it takes to repair a system must be short enough that it isavailable 99% of the time it is needed. However, availability is tested under laboratoryconditions, and in practice may depend on factors such as whether someone is present at thepolling place who can effect any needed repairs. Therefore, a system that achieves anavailability score greater than 99% in testing might not achieve that level in actual use.

Whether the VVSG should include management guidelines for election administratorsis also a matter of some dispute. In the current draft, best practice recommendations havebeen placed in an appendix, whereas they were in the numbered sections in the TGDCrecommendation document. Their removal to an appendix eliminates any ambiguity withrespect to their role, or lack of it, in the certification process. However, the development ofa set of administration or management sections in future versions of the VVSG could raise thequestion of whether certification protocols should be developed for election administration. That possibility may be worthy of consideration, but it could require an additional certificationmechanism for election jurisdictions as well as vendors, depending on the focus of themanagement requirements. (35)

The VVSG and the 2006 Federal Election

Even with the limitations in scope of initial change to the VSS, there is some questionwhat impact the VVSG can have on the 2006 election. (36) The EAC hasindicated a desire to finalize the guidelines soon after the close of the comment period at theend of September 2005, but it has received more than 4,000 individual commentsaltogether. (37) Inaddition, the VVSG are not scheduled to go into effect until two years after adoption -- thatis, no sooner than fall 2007. Until that time, federal certification of voting systems willpresumably continue to be based on the 2002 VSS, although state or local jurisdictions maychoose to require vendors to meet some or all of the VVSG requirements sooner, and the EACplans to issue guidelines to assist states in implementation. (38) That may beespecially important for those jurisdictions that require a voter-verifiable paper audit trail foruse with DREs, since that option is not covered by the VSS but is covered by the VVSG .

Some observers have expressed concern that uncertainties about the VVSG development and implementation have resulted in delays by states in procuring new votingsystems to meet HAVA requirements. Among the reasons are worries about acquiring newsystems in time for the January 2006 deadline that might later be deemed not to be incompliance with the requirements, or not obtaining systems of as high a level of quality aswould be possible once the VVSG go into effect. Similarly, some observers are concerned thatsystems in use that were certified under the VSS but not the VVSG could be effectivelydecertified once certification under the VVSG begins. Those concerns are amplified byuncertainties with respect to federal funding for future acquisitions. One proposed solutionis for the EAC to advise jurisdictions that systems conforming to the 2002 VSS will satisfyHAVA requirements. However, that version of the VSS was released before HAVA wasenacted, and since the EAC has no regulatory authority, it is not clear what effect such advicewould have. Other observers believe that delaying the implementation of the VVSG meansthat the 2006 federal election will need to be conducted with voting systems that are notdesigned to conform to HAVA requirements. Another concern raised by some is that theproposed fall 2007 implementation date may not leave sufficient time for vendors and statesto develop and acquire conforming systems before the 2008 federal election.

The VVSG and Voter Registration Systems

The focus of the VSS has been limited to polling-place and central-office systemsinvolved in the conduct of an election -- from ballot preparation to election certification. Neither the VSS nor the first version of the VVSG address the technology used to create andmanage voter registration lists. Sec 221(3)(2)(a) of HAVA requires NIST to provide technicalsupport for development of guidelines relating to the computerized statewide voterregistration lists mandated by Section 303(a) of HAVA. That arguably implies congressionalintent that the VVSG cover that topic, but HAVA does not explicitly require that. The datainterchange standards being developed by IEEE include voter registration data. (39) However, there arecurrently no formal or widely accepted standards for those lists, and that absence has raisedconcerns about adequate state implementation of the requirement by the January 2006deadline.

Integrated versus Component Certification

The VVSG focus on voting systems rather than on individual components. While theypermit the submission of interoperable components for certification, they require that"vendors shall submit for testing the specific system configuration that will be offered tojurisdictions or that comprises the component to be marketed plus the other components withwhich the vendor recommends that the component be used." (40) This implies, inessence, that a vendor wishing to submit a component that could be used with different votingsystems would have to submit those systems along with the component for certificationtesting. Some observers argue that this restriction stifles innovation by requiring that thosevendors who wish to market devices that can be used with existing voting systems negotiateagreements with voting-system vendors before certification of their components. However,such agreements may be difficult to obtain before a component is certified or may entailrestriction on the use of the component to only one brand of voting system. (41) One proposal toaddress this concern is to allow certification of components separately, but require that theysubsequently be certified with each voting system with which they would be used.

Use of Commercial Off-the-Shelf (COTS) Software

Most if not all voting systems use some form of COTS software that is proprietary --that is, the code is not publicly available. The use of COTS software is somewhatcontroversial. It is much less expensive in general to use such software when appropriate thanto develop code specifically for the voting system. In addition, some commercial software,such as Microsoft Windows, has become standard, with computer hardware developedspecifically to work with it. However, vendors have no control over how the COTS softwareis coded, and the code may be very complex. Code examination is not required under the VVSG for unmodified COTS software, and general-purpose software such as operatingsystems may be exempt from detailed examination. Some observers object to this exemption,arguing that it creates unacceptable security risks. Others believe that the guidelines shouldprohibit the use of COTS software altogether (although presumably they are referring to itsuse in a voting or counting machine, not in back-office computers used in such tasks as ballotpreparation). Proponents counter that VVSG safeguards are adequate and that the use ofCOTS software permits superior applications at far lower cost than custom software wouldallow.

Grading versus Pass/Fail Certification

Under the VVSG testing scheme, voting systems pass or fail, but no additionalinformation is provided to potential customers or the public about details of performance ofcertified systems -- such as to what extent the tested system exceeded the standards. Someobservers believe that a certification regime that provided more finely graded performancereports would be very useful in stimulating innovation and helping election officials decidewhich systems are best suited to their jurisdictions. However, to the extent such grading wassubjective, it could be misleading or potentially subject to abuse. In 2004, a group ofcomputer experts, vendors, election officials, social scientists, and advocates started theVoting System Performance Rating (VSPR) project, which aims at developing performancerating standards for U.S. voting systems, (42) but there has been no public indication from the groupabout when such standards might be expected.

Verification Systems, Including VVPAT

One thing added to the VVSG was a discussion of methods by which votes could beverified. For one such method, the voter-verified paper audit trail, or VVPAT, the VVSG provides standards, since such systems have been mandated by several states. However,several other kinds of such systems exist, and some are described in an appendix to theguidelines, (43) with some guidance for how they might be implemented. The systems described all have thecharacteristic of providing two independently verifiable channels for processing votes and aretherefore called Independent Dual Verification (IDV) systems in the VVSG . The possibleneed for such systems has become a matter of public interest because of the controversy overthe security of DREs. While most public attention has been paid to VVPAT, other methodsarguably show more promise in terms of usability, accessibility, and verification power. (44)

Some observers believe that IDV systems -- especially, VVPAT -- are essential toensure security of and confidence in electronic voting, whereas others believe that the costsand complexity of at least some IDV systems are disadvantages that outweigh any benefits. The guidelines do not require such a system, although such a requirement was considered bythe TGDC. (45) Some observers believe that the VVSG should require VVPAT, but others believe that theverification provided by that method is of questionable value in practice and may createunforeseen problems of its own. Some also believe that the accessibility and alternativelanguage provisions relating to VVPAT do not ensure full compliance with HAVA and otherfederal requirements. Still others believe that the VVSG should provide more stringentrequirements with respect to what kinds of data should be recorded by voting systems foraudit purposes. In any case, the trend at the state level toward requiring the use of VVPATto address security issues is raising significant questions about whether such requirements canbe reconciled with HAVA accessibility requirements under the constraints imposed by currenttechnology.

Legislative Proposals in the 109th Congress

Several bills introduced in the 109th Congress could affect the scope or other aspectsof the VVSG . They include the following proposals:

Adding provisions on security of electronic data ( H.R. 278 );

Requiring submission to and testing of voting machine software bystates before an election ( H.R. 470 );

Requiring use of a voter-verified paper audit trail ( H.R. 278 , H.R. 550 ; H.R. 704 , H.R. 939 , S. 330 , S. 450 );

Requiring the use of a verification method involving paper, audio, orother means, and relevant standards ( H.R. 533 , S. 17 ; H.R. 939 for voters with disabilities);

Requiring that voting systems used for disability access separate thefunctions of vote generation, verification, and casting ( H.R. 550 , H.R. 939 , S. 450 );

Requiring the EAC to develop best practices for voter-verification forpersons with disabilities and languages other than English ( H.R. 550 );

Requiring the EAC to develop standards on conflict of interest fortesting laboratories, manufacturers, and/or other entities involved with voting machines( H.R. 470 , H.R. 533 , H.R. 550 , H.R. 3094 );

Requiring the EAC to develop standards for the minimum number ofvoting machines at polling places ( H.R. 533 , H.R. 939 , S. 17 , S. 450 );

Requiring the use of open-source software in voting systems( H.R. 3094 ) and the development of relevant standards by the EAC( H.R. 533 , H.R. 550 , H.R. 939 , S. 450 );

Prohibiting the use of wireless communications by voting systems( H.R. 550 , H.R. 939 , H.R. 3094 , S. 450 );

Requiring public disclosure of information relating to certification ofvoting systems ( H.R. 550 );

Requiring the EAC to establish standards for early voting( H.R. 533 , H.R. 939 , S. 17 , S. 450 ) andfor a federal write-in absentee ballot ( H.R. 4141 );

Requiring manufacturers to follow security standards as specified byNIST ( H.R. 939 , S. 450 );

Requiring the EAC to establish a benchmark for voter error-rates( H.R. 939 , S. 450 );

Requiring EAC certification of technological security of state voterregistration systems ( H.R. 939 , S. 450 );

Prohibiting states from not registering certain voters or removing themfrom registration roles unless accuracy standards established by NIST are met( H.R. 3094 ).

None of the above bills have received committee or floor action in either chamber.

Appendix 1. Section-by-Section Summary of the VVSG

Volume I

Section 1 lays out the overall objectives for the guidelines: to specify what a votingsystem should do -- how it should function and perform -- as well as documentationrequirements and evaluation criteria for certification. It describes background on the historyof the guidelines and describes what a voting system is -- not just a voting machine but alsosoftware and documentation relating to steps in the election process ranging from ballotdefinition through system audit. (46) It characterizes voting systems as either paper-based (suchas punchcard and optical scan systems) or direct recording electronic (DRE), which are thetwo kinds of computer-assisted system currently in use, and distinguishes precinct- andcentral-count systems, but it recognizes that the distinctions may blur with future technology. This section also describes application of the guidelines and test specifications, pointing outthat commercial off-the-shelf (COTS) products are exempt from some aspects of certificationif they are not modified for use in a voting system. The VVSG contains a new subsection, a"conformance clause," which broadly defines what is required of those implementing thespecifications in the guidelines and is a common feature of standards documents.

Section 2 describes the functional capabilities that a voting system is expected to haveand is the longest chapter in the VVSG . Required capabilities include the following:

Security. This involves both technical and administrative controls andis discussed in detail in Section 6.

Accuracy. This involves both accurate recording and error detection, andspecifies that DREs must retain redundant records of all votes cast.

Error Recovery. Systems must be able to recover from malfunctions andresume operating with data intact.

Integrity. Systems must be protected against outside perturbations suchas loss of power or attempts at improper data inputs, and must record and maintain specificaudit data.

System Audit. Generation of audit records is to be largely automated,including continuous "real-time" data on machine status along with accurate time and dateinformation, and error messages where appropriate. COTS operating systems must havespecific protections against vulnerabilities that could affect audit data.

Election Management System. This involves databases that assistofficials in performing a wide range of functions, from defining political subdivisions throughthe processing of election audit reports.

Human Factors. This subsection has been greatly expanded and revised. The standards in it are based on three principles -- nondiscriminatory access to voting,accurate capture of ballot selections, and preservation of ballot secrecy. It contains more than50 specific provisions describing required and recommended features responding todisabilities relating to vision, dexterity, mobility, hearing, speech, and cognition, as well aslimited English proficiency and alternative language accessibility. It also containsinterim (47) provisions relating to usability for all voters, based on both HAVA requirements andestablished usability principles.

Vote Tabulating Program. Systems must have software for tabulatingvotes that is flexible, accurate, and includes monitoring and auditfunctions.

Ballot Counter. Systems must have accurate, tamper-proof ballotcounters that are visible to election officials.

Telecommunications. Systems that use telecommunications musttransmit data with no alteration or unauthorized disclosure.

Data Retention. Systems must provide for retention of records inaccordance with applicable federal law.

Prevoting Functions. Systems must support preparation, installation,and control of ballots and election programs; testing for readiness; and verification offunctions both centrally and at the polling place.

Voting Functions. This involves ensuring that only properly tested,activated, and functioning devices are used in voting, and that systems facilitate accurate andsecret casting of ballots and respond appropriately to power or telecommunicationsinterruptions.

Postvoting Functions. Systems must accumulate and report both resultsof the election and audit trails and prevent additional voting after the polls areclosed.

Maintenance, Transportation, and Storage. Systems must be capableof being stored and transported without degradation in capabilities.

Section 3 covers requirements for voting system hardware, from printers to votingdevices to paper ballots to back-office computer equipment, regardless of source. Theseinclude

performance requirements such as accuracy; (48) operationalspecifications such as electricity supply, storage, and ability to operate under a range ofenvironmental conditions; vote recording specifications for voting booth, paper ballots,marking devices, ballot boxes, various features of DREs, and so forth; ballot reading andprocessing specifications for machine readers and DREs; and specifications for printers andremovable storage media, and for data management;

physical requirements, especially for transport and storage of equipment;

design, construction, and maintenance requirements, with an emphasison best commercial practice for design, "the lowest level [of malfunction] consistent with costconstraints," (49) an average time-to-failure (called MTBF or mean time between failures) in testing of no lessthan 163 hours (50) with time to repair short enough that the system is available for at least 99% of the time it isneeded, (51) thepresence of features to assist in the reliability and maintainability of the system, properproduct labeling, quality workmanship, and safe design andconstruction.

Section 4 covers requirements for voting system software, including firmware, (52) regardless ofprogramming language or source. These include

design and coding , including the kinds of programming languagepermitted; the importance of stable computer code (53) and modular software; (54) the way programcontrols are constructed, and the way components are coded, named, and commented;

data and document retention, including accurately maintaining votingand audit data for at least 22 months after the election, and proper security and failureprotection for devices;

audit record data, including ballot preparation, system readiness, (55) documentation ofoperations during diagnostic routines and ballot casting and counting, (56) and detailedvote-tally data including overvotes and undervotes;

vote secrecy for DREs, including erasing from temporary storage anddisplays the selections of previous voters immediately after a vote is cast orcancelled.

Section 5 covers telecommunications requirements for systems operation and reportingelection results, including performance, design, and maintenance characteristics. It coverstechnologies such as dial-up communications, cable and wireless, and high-speed lines,regardless of provider. It covers data transmission from election preparation throughpreservation of data and audit trails after the election, including voter authentication, ballotdefinition, vote transmission, vote counts, and lists of voters, and other transmissions relatingto voting-system operation. Requirements are the same as those contained in Section 3 foraccuracy, durability, reliability, maintainability, and availability. For wide-area networks(WANs), (57) outside providers or subscribers are not permitted access inside the network boundary, nocontrol resources for the network are permitted outside the border, and the system cannot bevulnerable to a single point of failure. The system must notify users of successful andunsuccessful transmission and actions taken if transmission is unsuccessful.

Section 6 addresses essential security capabilities for all voting systems componentsregardless of source, ownership, or location, and includes controls to minimize errors andaccidents, protect from malicious manipulation, identify fraudulent or erroneous changes, andprotect voting secrecy. The section cites the importance of effective security practices byjurisdictions but does not address them. (58) Topics covered include

access control, including general access control and individualprivileges, and specific measures such as passwords and encryption;

equipment and data security , including physical security for pollingplaces and ballot-counting locations;

software security , including installation requirements and testing offirmware, protection against malicious software, (59) and software distribution and validation requirements toensure that no unauthorized modifications have been made (this is a new set of detailedrequirements) (60) ;

telecommunications and data transmission , including access control,integrity of transmission, use of encryption to protect data from interception, use of intrusiondetection methods, protection against external threats to COTS software, and specificrequirements for DREs that transmit data over public networks and for wirelesscommunications (this latter subsection is new), including the caution that the use of wirelesscommunications should be approached with "extreme caution" (61) ;

optional requirements for voter-verified paper trail (VVPAT), includingrequirements for handling spoiled and accepted paper records, preserving voter privacy andvote secrecy, audit and election data such as linking electronic and paper records, machinereadability of paper records, tamper protection, printer reliability and maintenance, anddurability of the paper record, as well as usability and accessibility requirements (thissubsection is new). Section 7 requires that vendors and third-party suppliers implementquality-assurance programs to help ensure conformance with VVSG requirements. It includestesting, inspection, and documentation requirements.

Section 8 describes requirements for configuration management, includingdescriptions of the policy, identification and acquisition of component items; procedures usedto decide what components are included in the product as it is developed, submitted forcertification, and throughout its useful life cycle; how configuration is controlled to preventunauthorized changes; product release; configuration audits; and any automated tools used inconfiguration management.

Appendix A is a glossary, which has been substantially expanded in the VVSG . It nowlists sources and keywords (called "association") for each entry as well as definitions.

Appendix B lists reference documents that have been incorporated into the guidelinesin whole or in part. Several new references have been added and others updated.

Appendix C describes suggested best practices for election officials with respect tousability and security requirements added in the VVSG . These are drawn from the TGDCdraft, in which they were embedded in Sections 2 and 6. (62)

Appendix D describes independent dual verification (IDV) systems, of which VVPATis one type. Such systems produce at least two separate, independent ballot records that voterscan verify before casting and that can be compared in a post-election audit. Examples include

split-process architecture, where the vote is captured on paper oranother medium and then taken to a verification station, where a separate, voter-verifiedrecord is made and stored;

end-to-end systems, which permit voters to verify ballot choices, evenafter casting, without compromising ballot secrecy. Voters are typically given a receipt witha code number that they can check later, such as on a website. The use of cryptographictechniques prevents voters from using the receipt to prove how they voted while ensuringaccurate verification with a very high degree of probability;

witness systems, which independently record voters' choices through ameans such as a camera that takes a picture of the choices displayed on a DRE screen; and

direct systems, such as VVPAT, which produce a second record that thevoter may directly verify before casting.

The appendix also discusses issues in handling records produced by IDV systems, suchas how to structure records to ensure comparability in audits, and describes desirablecharacteristics for each type. (63)

Appendix E is a NASED technical guideline produced to assist vendors in meetingrequirements originally in the 2002 VSS to improve readability for persons with low visionor color blindness.

Volume II

Section 1 provides an overview of the certification testing process, which focuses onoperational accuracy and failure, system performance under normal and abnormal conditions,and the quality of documentation. There are five different categories of testing: functionality,hardware, software, system integration, and documentation of practices for quality assuranceand configuration management. Testing is to be performed according to a test plan and in adesignated sequence -- from initial examination through delivery of the test report to the EAC-- that follows specified practices. Vendors are required to submit for testing the specificsystem configuration that will be offered to election jurisdictions, and testing is required forboth new systems and previously certified ones that have been modified. Some hardware isexempt from some aspects of testing, including certain kinds of commercial equipment thatmeet established standards and other criteria of compatibility and function. If more than onelaboratory is involved in testing, one must be designated as the lead laboratory. Testingactivities must be observed by one or more independent, qualified observers. A test lab mustwitness the final system build by the vendor for certification. The EAC is to develop aprocess for resolving issues that arise about interpretation of the VVSG for testing.

Section 2 describes the documentation, called the Technical Data Package (TDP), thatthe vendor must submit at the beginning of the certification process. The TDP includesdescriptions of system design (including specifications and constraints); functionalcapabilities; performance specifications; applicable standards; requirements for compatibility,operation, maintenance, and support; and quality assurance and configuration managementpractices. The TDP must identify any proprietary information that is not to be publiclyreleased and must include a security specification, among other things. Previously certifiedsystems that have been modified must be submitted with notes including a summary andspecification of the changes to the system, changes to documentation, and documentation ofvendor testing.

Section 3 describes testing to confirm functional capabilities as required by VolumeI, Section 2. It stresses the importance of flexibility in testing to accommodate variations indesign and technology and any additional capabilities not described in the VVSG .

Section 4 describes testing of hardware components to confirm that they functionproperly according to the requirements in Volume I, Section 3. It includes both operationaltests and environmental tests of nonoperating equipment, including responses to handling,vibration, low and high temperature, and humidity, as well as response to temperature andpower variation during operation and other electrical disturbance. Testing is also done formaintainability and reliability. For accuracy testing, a system will be rejected if it makes anerror before correctly counting 26,997 ballot positions consecutively, and will be accepted ifit makes no errors in consecutively counting 1,549,703. (64) Systems that fallbetween these two thresholds are discussed in Appendix C.

Section 5 describes testing for proper software functioning. Code examination is notrequired for unmodified COTS software, and if it is also general-purpose, and not used forvoting, detailed examination is not required. Source code is examined for conformance tovendor specifications, adherence to requirements in Volume I, Section 4, and use of specifiedcontrol constructs (65) and coding conventions.

Section 6 describes testing to confirm proper functioning of integrated voting-systemcomponents, under normal and abnormal conditions, and including telecommunications,security capabilities, accessibility, and any functions that exceed VVSG requirements. Testingincludes configuration audits comparing components and functions with technicaldocumentation of them provided by the vendor.

Section 7 describes examination of a vendor's documented configuration managementand quality assurance processes, to verify conformance to VVSG requirements. However,on-site examination is not required.

Appendix A contains a recommended outline for the laboratory's testing plan, calledthe National Certification Test Plan, which is intended to document the development ofcertification tests. The plan is to be developed after the receipt of a TDP from the vendor andis therefore specific to a particular system being submitted for certification.

Appendix B contains a recommended outline for the laboratory's test report, called theNational Certification Test Report. A full report is required on initial certification of asystem, but partial reports can be prepared for certification of subsequent modifications. Thereport is to include a recommendation to the EAC for approval or rejection of the applicationfor certification, as well as descriptions of any uncorrected deficiencies. Those deficienciesnot involving loss or corruption of data will not necessarily lead to rejection.

Appendix C, on test-design criteria, describes the principles used to design the testingprocess. Design must balance the need to produce sufficient data to support the validity ofthe test, on the one hand, with the need for reasonable cost of testing, on the other. The designapproach used in the VVSG is to determine if the object being tested achieves or exceeds aminimum threshold of performance. Tests are continued until that threshold is reached or theobject fails.

Appendix 2. Abbreviations

ANSI. The American National Standards Institute, a private, nonprofit organization thatadministers and coordinates the U.S. voluntary private-sector standardization system.

BIOS. Basic Input/Output System, a form of ROM used in computers to provide basicfunctions such as control of disk drives. (66)

COTS. Commercial Off-the-Shelf, referring to readily available, commercial software orhardware.

DRE. Direct (or Digital) Recording Electronic Voting System, a kind of voting system whereballot choices a voter makes are recorded directly onto electronic media rather than paper.

EAC. The federal Election Assistance Commission, a four-member, bipartisan commission,established by HAVA, that replaced the former Office of Election Administration in theFederal Election Commission.

FEC. The Federal Election Commission, which was responsible for federal guidance andinformation relating to election administration before the enactment of HAVA.

FISMA. The Federal Information Security Management Act, first enacted as part of theHomeland Security Act of 2002 ( P.L. 107-292 ) and later in modified form in theE-Government Act of 2002 ( P.L. 107-347 ).

HAVA. The Help America Vote Act of 2002, which, among other things, established theEAC, required it to develop the VVSG , and established a mechanism for that.

IDV. Independent Dual Verification refers to "electronic voting systems that produce multiple[at least two] records of ballot choices whose contents are capable of being audited to highlevels of precision." (67)

IEC. The International Electrotechnical Commission, a standards organization for electrical,electronic and related technologies.

IEEE. The Institute of Electrical and Electronics Engineers, an international professionalorganization that is also involved in the development of standards.

IESG. The Internet Engineering Steering Group is part of the Internet Society, a professionalorganization. The IESG is responsible for the technical management of IETF activities.

IETF. The Internet Engineering Task Force, a community of professionals involved in theevolution of Internet architecture, with the goal of improving Internet operations through thedevelopment of standards, best practices, and other information.

ISO. International Organization for Standardization, a federation of the principal standardsbodies from countries around the world.

ITA. Independent Testing Authority, a laboratory accredited by NASED to performcertification testing of voting systems.

LAN. Local-Area Network, referring to a computer network that spans a comparatively smallarea, such as an office or building, as opposed to a wide-area network (WAN).

MTBF. Mean Time Between Failures, defined in the VVSG as "the value of the ratio of theoperating time [of a voting system] to the number of failures which have occurred in thespecified time interval." (68)

NASED. The National Association of State Election Directors, a professional association that,before HAVA, administered the national certification program for voting systems.

NIST. The National Institute of Standards and Technology, required by HAVA to provideassistance to the EAC in the development of the VSS and the process for certification ofvoting systems.

NVLAP. The National Voluntary Laboratory Accreditation Program, a NIST programinvolved in the identification and assessment of candidates testing laboratories for the VVSG certification program.

OEA. The former Office of Election Administration within the FEC. OEA was abolishedupon the establishment of the EAC.

ROM. Read-Only Memory, a kind of computer memory in which data has been prerecordedand which is retained when the computer is turned off. It often contains small BIOS programsnecessary to start the computer when power is turned on. (69)

TDP. Technical Data Package, the "vendor documentation relating to the voting systemrequired to be submitted with the system as a precondition of certification testing." (70)

TGDC. Technical Guidelines Development Committee, a 15-member committee establishedby HAVA and chaired by the Director of NIST. The main function of the TGDC is to makerecommendations to the EAC on the VVSG .

VSPR. Voting System Performance Rating, an independent project designed to developperformance rating standards for U.S. voting systems.

VSS. The federal voluntary Voting Systems Standards ( VSS ) developed by the FEC.

VVPAT. Voter-Verified Paper Audit Trail, a printed record of all of a voter's ballot choicesthat the voter can review before the ballot is cast. This term is usually used to refer to an IDVmethod used with DREs, rather than standard paper-based ballot systems such as optical scan.

VVSG. The federal Voluntary Voting System Guidelines, developed by the EAC withassistance from NIST, as required by HAVA.

WAN. A Wide-Area Network, referring to a computer network that spans a comparativelywide geographic area, as opposed to a local-area network (LAN).