VRD Report

Download PDF

 
 
Association for Computing Machinery
Advancing Computing as a Science & Profession
 
 
 
 
 
 
Statewide Databases of Registered Voters:
Study Of Accuracy, Privacy, Usability, Security, and Reliability Issues commissioned by
the U.S. Public Policy Committee of the Association for Computing Machinery
 
February 2006
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Copyright © 2006 ACM. ISBN: 1-59593-344-1.  Permission to make digital or hard copies of portions of this work for personal or classroom use is
granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full
citation on the first page.  To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
2 2
 
Preface
 
The Association for Computing Machinery (ACM) is an educational and scientific
society uniting the world’s computing educators, researchers and professionals to inspire
dialogue, share resources and address the field's challenges.  ACM strengthens the
profession's collective voice through strong leadership, promotion of the highest
standards, and recognition of technical excellence.  As such, ACM cares deeply about the
dependability and reliability of computing technology.  Voter registration systems
encompass not only the databases that house voter information, but also an entire
information technology infrastructure that must be carefully managed by election
officials.  The U.S. Public Policy Committee of the ACM (USACM) commissioned this
study to provide objective technical information and expert recommendations to state and
local election officials, policy makers, and the public about these systems.
 
The USACM serves as the focal point for ACM’s interaction with U.S. government
organizations, the computing community, and the U.S. public in all matters of U.S. public
policy related to information technology.
 
Supported by ACM’s Washington, D.C., Office of Public Policy, USACM responds to
requests for information and technical expertise from U.S. government agencies and
departments, seeks to influence relevant U.S. government policies on behalf of the
computing community and the public, and provides information to ACM on relevant U.S.
government activities.  USACM also identifies potentially significant technical and
public policy issues and brings them to the attention of ACM and the public.
 
More information about ACM may be found on the World Wide Web at
http://www.acm.org, and information on USACM may be found at
http://www.acm.org/usacm.  
3 3
 
Table of Contents
 
Executive Summary........................................................................................................4
Chapter Overviews and Recommendations......................................................................8
1.  Introduction..............................................................................................................17
2.  Accuracy..................................................................................................................21
3.  Privacy.....................................................................................................................27
4.  Usability...................................................................................................................33
5.  Security....................................................................................................................39
6.  Reliability................................................................................................................50
Appendix A:  Glossary..................................................................................................54
Appendix B:  Biographies of Committee Members........................................................57
4 4
 
 
 
 
 
 
 
 
 
 
 
Executive Summary
 
The voter registration process may seem simple to most voters.  They give their names,
addresses, birth date, and in some cases party affiliations to election officials with the
expectation that they will be able to vote on Election Day.  In reality, election officials
must oversee a complex system managing this process.  They must ensure that the voters’
information is accurately recorded and maintained, that the system is transparent while
voter information is kept private and secure from unauthorized access, and that poll
workers can access this information on Election Day to determine whether or not any
given voter is eligible.  A well-managed voter registration system is vital for ensuring
public confidence in elections.
State and local governments have managed voter registration using different
approaches among different jurisdictions.  In 2002, Congress sought to make these
disparate efforts more uniform by passing the Help America Vote Act, which required
that each state have a computerized statewide voter registration database.  In
implementing this mandate, state and local governments still have differing approaches,
but it is clear that information technology underpins each of their efforts.  While
technology will help election officials manage this complex system, it also creates new
risks that must be addressed.
This study focuses on five areas that election officials should address when creating
statewide voter registration databases (VRDs):  accuracy, privacy, usability, security, and
reliability.  Each chapter contains detailed discussions and recommendations.  The
following are some of the overarching goals for VRDs and selected recommendations for
achieving them.
 
1.  The policies and practices of entire voting registration systems, including those
that govern VRDs, should be transparent both internally and externally.
 
VRDs control access to voting; therefore, they have a direct impact on the fairness of
elections, as well as the public’s perception of fairness.  It must be possible to convince
voters, political parties, politicians, academics, the press, and others that VRDs are
correct and are operating appropriately.  Internal procedures and interfaces also must be
clear to election workers in order to minimize errors.  Transparency can be provided by
allowing voters to verify their voter registration status and data; publicly disclosing
outside data sources that officials use for verification; indefinitely keeping a secure write-
"An adequate and effective registration will go far toward assuring
honesty and fairness in the conduct of elections.  Upon the honest and
faithful maintenance of the registration books depends the purity of the
ballot box.  And upon the purity of the ballot box depends the success or
failure of our democratic form of government."
-- Registration of Voters in Louisiana, Alden
L. Powell and Emmett Asseff, Bureau of
Government Research, Louisiana State
University, 1951
5 5
 
once VRD archive in electronic form to allow audits of previous elections; and using
independent experts to audit and review VRD security policies.  Other goals such as
accountability, audits, and notification also support transparency and are discussed
below.
 
2.  Accountability should be apparent throughout each VRD.  
 
It should be clear who is proposing, making, or approving changes to the data, the
system, or its policies.  Security policies are an important tool for ensuring accountability.  
For example, access control policies can be structured to restrict actions of certain groups
or individual users of the system.  Further, users’ actions can be logged using audit trails
(discussed below).  Accountability also should extend to external uses of VRD data.  For
example, state and local officials should require recipients of data from VRDs to sign use
agreements consistent with the government’s official policies and procedures.
 
3.  Audit trails should be employed throughout the VRD.  
 
VRDs that can be independently verified, checked, and proven to be fair will increase
voter confidence and help avoid litigation.  Audit trails are important for independent
verification, which, in turn, makes the system more transparent and provides a
mechanism for accountability.  They should include records of data changes,
configuration changes, security policy changes, and database design changes.  The trails
may be independent records for each part of the VRD, but they should include both who
made the change and who approved the change.  
 
4.  Privacy values should be a fundamental part of the VRD, not an afterthought.
 
Privacy policies for voter registration activities should be based on Fair Information
Practices (FIPs), which are a set of principles for addressing concerns about information
privacy.  FIPs typically address collection limitation, data quality, purpose specification,
use limitation, security safeguards, openness, individual participation, and accountability.  
There are many ways to implement good privacy policies.  For example, we recommend
that government both limit collection to only the data required for proper registration and
explain why each piece of personal information is necessary.  Further, privacy policies
should be published and widely distributed, and the public should be given an
opportunity to comment on any changes.
 
5.  Registration systems should have strong notification policies.  
 
Voters should be informed about their status, election information, privacy policies of the
government, and security issues.  As with audit trails, notification procedures can
improve transparency; however, they are not always widely embraced.  A recent survey
found that approximately two-thirds of surveyed states do not notify voters who have
been purged from election rolls.  Voters should be notified by mail about their polling
places, any changes that may affect their ability to vote, or any security breaches that
expose private data.
6 6
 
 
6.  Election officials should rigorously test the usability, security and reliability of
VRDs while they are being designed and while they are in use.
 
Testing is a critical tool that can reveal that “real-world” poll workers find interfaces
confusing and unusable, expose security flaws in the system, or that the system is likely
to fail under the stress of Election Day.  All of these issues, if caught before they are
problems through testing will reduce voter fraud and the disenfranchisement of legitimate
voters.  We recommend many different ways to test various aspects of VRDs throughout
the report.  Examples include, evaluation of VRD interfaces by laypersons and experts
for consistency, feedback, and error handling; testing interfaces with real-world users and
conditions, including extreme or sub-optimal conditions such as high processor load or
network congestion; and allowing thorough, independent evaluations of the security and
reliability of the VRD.
 
7.  Election officials should develop strategies for coping with potential Election Day
failures of electronic registration databases.  
 
VRDs are complex systems.  It is likely that one or more aspects of the technology will
fail at some point.  Different strategies can be employed to adjust for various failures.  
For example, Election Day verifications can be done via any of the following:  paper
systems, personal computers or hand-held devices with DVD-ROMs or other methods of
holding static copies of the voter list, or via personal computers or hand-held devices
connected by electronic communication links to central VRDs.  Regardless of the method
used, a fallback process should be devised to deal with a VRD failure.  When appropriate,
these processes should operate in tandem with provisional balloting and other measures
designed to protect the voters’ right to vote.  
 
8.  Election officials should develop special procedures and protections to handle
large-scale merges with and purges of the VRD.
 
One of HAVA’s main requirements is that VRDs be coordinated with other state
databases (such as motor vehicle records).  Ensuring that voter records reflect up-to-date
information from other databases can improve the accuracy of VRD, but coordination can
introduce errors from the same databases, thereby undermining accuracy.  Because large-
scale merges and purges can render voters ineligible, the action should only be performed
by a senior election official with procedures that force some sort of manual review of the
changes.  Further, if large-scale purges occur, they should be done well in advance of any
election, and anyone purged from the database should receive notification so that any
errors can be corrected.
 
Conclusion.  State and local election officials face an ongoing and challenging task in
creating and implementing statewide voter registration databases.  We hope that the
discussion and recommendations in this report will help inform officials and the public
on how to meet these challenges.
In issuing this report, we recognize that many states have been working diligently
7 7
 
toward meeting the federal requirement to have an operational statewide VRD.  Both
because many states will not meet this deadline, and because there will be ongoing
maintenance and changes to any such system, state and local governments will also face
the issues identified in this report well beyond the federal deadline.  For this reason, we
offer our continued guidance to officials who may wish to discuss any of the topics raised
in this report.
8 8
 
Chapter Overviews and Recommendations
 
Accuracy
 
Databases are only as good as the data they contain.  Quality assurance is a challenge for
any database because data entry and necessary merges and purges of data within the
system can create errors.  Maintaining accurate VRDs is even more difficult considering
the mobility of the U.S. population1 and the wide variety of information sources voting
officials must use to verify registration records.  Further, voting officials must balance
between competing concerns of ensuring that each legally registered voter can cast his or
her vote and preventing ineligible voters from casting votes.  Accuracy concerns often lie
at the center of these debates.  An additional complication is that voter eligibility rules are
determined state-by-state, and VRD design and implementation are likely to differ state-
by-state.
 
Accuracy Recommendations  
 
Voter Verification
 
• Voters should easily be able to determine if they are registered.
• Voters should be able to verify that they are registered through the use of a computer
or handheld device located at any of the polling places in that state.  Responses
should not include personally identifiable information about the potential voter.  
• Voters should be able to view the relevant contents of their voter registration              
records to check for accuracy and should be provided with easy-to-use mechanisms
and contacts for correcting errors.
• Electronic Election Day updates to registration records are risky and should be
implemented only after careful testing, if at all.  Paper forms are a well-understood
alternative.
 
Notice
 
• Whenever a voter or potential voter is determined to be ineligible to vote, the reason
and source of information for the determination of ineligibility should be noted in the
VRD for the potential voter to review and contest, if appropriate.
• Voters should be notified when their records change in any way that affects their
eligibility to vote.  
• Public notice of polling places should be provided well in advance of an election
(e.g., signs in neighborhoods, prominent notices on local web sites).  
• Each registered voter in the VRD should be mailed a postcard with his or her
assigned polling place and registration status in advance of the election.
 
 
                                                
1
 A recent report of the Commission on Federal Election Reform found that “during the last decade, on
average, 41.5 million Americans moved each year.”
9 9
 
Polling Place Lists
 
• Polling place lists (whether paper or electronic) of all registered voters associated
with a particular polling place should be generated automatically by the VRD well
before Election Day.
• Automatically generated lists should be carefully checked by at least two local
officials and far enough in advance of elections to allow time for corrections.
 
Archiving
 
• Ineligibility records should be retained in the VRD for at least twenty-two months
and possibly longer.  
• If for any reason it is determined that an individual is ineligible to vote, that
individual's record should be marked accordingly, not deleted.  
• When information is sufficiently old (we recommend at least 22 months), it should be
moved from the VRD into an offline archival database that is never purged and is
protected against unauthorized disclosure or access.
 
Other Databases
 
• When other databases, such as driver registration databases, are used to check for
eligibility, those databases should be used for screening and not to automatically
enroll or de-enroll voters.   
• An automated check can be used to flag some voters for further scrutiny, but the final
determination of eligibility should be performed only by an appropriate election
official.  
 
Merges, Purges, and Batch Updates
 
• Large-scale automated database merges are error-prone and should be avoided if
possible.  
• If purges are performed, they should be done well in advance of any election.  People
whose names are purged from the VRD should receive notification in sufficient time
for them to be able to correct any errors.
• A greater level of authority should be required to perform a batch update than is
required to make smaller changes.
 
Accountability
 
• There must be well-defined accountability for all changes to the VRD including to
source code, database schemas, database contents, and system configuration.  
• Changes should require approval or sign-off by an authorized individual.
• It should be possible to identify a clear chain of responsibility for each change, and
the VRD should be designed to facilitate tracking of this information.
 
 
 
10 10
 
Audits
 
• A complete audit trail should log all modifications to the VRD.
 
Privacy
 
The public is increasingly aware that personal information in electronic form can pose
new risks, such as identity theft, to personal privacy.  As state and local governments
digitize, centralize, and share this data, the stakes are raised still higher.  While VRDs
may pose threats to privacy, technology also opens up new opportunities to protect
privacy.  As governments design and implement these systems, privacy values must be
considered a fundamental part of the design process, not simply applied as an
afterthought.
Privacy policies for voter registration activities should be based on Fair Information
Practices (FIPs), which are a set of principles for addressing concerns about information
privacy.  FIPs typically address collection limitation, data quality, purpose specification,
use limitation, security safeguards, openness, individual participation, and accountability.  
 
Privacy Recommendations
 
Openness (Transparency)
 
• Publish on the main election board website a complete notice of policies and practices
describing the collection, maintenance, use, and disclosure of voter registration data.  
The notice should include contact information for the office or the officials
responsible for voter registration data.
• Publish a readable summary notice in other places, such as voter registration forms, at
polling places, on sample ballots, and elsewhere as appropriate.
• Provide a copy of the complete notice to any person who requests it.
• Publish any changes to the notice before the changes become effective, and accept
and consider public comments.
• Place a date and version number on notices as they are published.  Maintain, and
make publicly available, copies of all previous notices, including the periods of time
during which they were effective.
 
Data Collection Limitation
 
• All data should be collected by lawful and fair means.
• Data should be collected, where appropriate, with the knowledge or consent of the
subject.
• Registrants and the public should be informed through the published notice of
policies and practices of the sources of all data obtained for voter registration
purposes.
• The types of data elements to be collected should be subject to public scrutiny.
• Data collection should be limited to sources and procedures authorized by law and
properly described in the published notice.
• Only the minimum information necessary for, and relevant to, voter registration
11 11
 
purposes should be collected and maintained.  The reason for collecting each type of
personal information should be explained, and the specific data elements collected
should be subject to public scrutiny.
 
Use and Disclosure Limits
 
• Limit use and disclosure of voter registration data to activities directly related to the
election process or to other activities expressly authorized by law.
• Describe all uses and disclosures in the published notice of information practices.  
Identify publicly all recipients of voter registration data.
• Provide public notice of and, if possible, a chance for public comment on all
disclosures of identifiable voter registration data for any activity not directly required
for voter registration purposes.
• Restrict access to specific records, specific data elements, and specific classes of
voters (e.g., by location) to those election officials who have a need to use those
records, data elements, and classes in the performance of their duties.
• For some or all uses by election officials or disclosures to external parties, maintain a
record of the date, nature, and recipient of all personal information and make the
record accessible to the data subject upon request.
• Restrict disclosures to specific data elements permitted by law and necessary to
accomplish the purpose of the disclosure.  Withhold data elements that are not
essential to accomplish the purpose of the disclosure or that would place data subjects
in excessive jeopardy to identity theft or other improper activities.
• Prevent recipients of data from using or redisclosing the data in ways not specifically
authorized by law.  Asking recipients to sign data use agreements is one way to
accomplish this purpose.
• Allow some non-essential uses and disclosures only with the affirmative consent (opt-
in) or negative consent (opt-out) of the data subject.
• For some data subjects at risk (e.g., victims of spousal abuse, jurors, some public
officials), it may be appropriate to further limit disclosures.
• Even the best use and disclosure policies may be violated by people and software
within the election process.  Therefore, limit access by each person and each system
component.
• Provide access for every voter to a personalized list of those third parties who have
been given or purchased access to his or her voter registration data.
 
Usability
 
VRDs will be used in many ways by a wide variety of people.  Ensuring that well-trained
election officials, minimally trained volunteer poll workers, and voters with little to no
technical skills can all use different and appropriate aspects of VRDs is a key challenge
for designers of these systems.  Poorly designed user interfaces might confuse users or,
worse yet, disenfranchise voters.  This can create the reality or the perception of an
unreliable system, thereby undermining the entire process.
 
12 12
 
Usability Recommendations
 
General Usability
 
• Consider the various types of users, tasks, and environments in which the voter
registration database will be used.  Design user interfaces that address all of these
factors, providing different interfaces for different combinations as necessary.
• Use accepted user interface design techniques to build data entry forms and data
retrieval components that are clear, usable, and interpretable.
 
Design and Features
 
• Involve a wide range of test users of different backgrounds, skills, literacy levels,
ages, and roles (county official, election volunteer, voters, etc.) in all stages of user
interface design, including gathering of usability requirements, design of user
interfaces, and testing and evaluation.  
• Treat user interface design as an iterative process:  use evaluations of user interface
designs to guide revisions that themselves can be evaluated in turn.
• Provide informative feedback (i.e., provide users with detail sufficient for
understanding the impact of their actions, results of queries, and characteristics of the
current operating environment).
• Eliminate unnecessary functionality and data output in favor of simple, minimal user
interfaces.
• Provide online tutorials and help systems for all voter registration database user
interfaces.  For critical applications such as voter verification on Election Day,
appropriate experts should be available to help address any concerns.
• Ensure that public-facing interfaces (e.g., World Wide Web based services) are
vendor-neutral and are designed to meet widely accepted technical standards.
 
Evaluation and Testing
 
• Use a variety of user interface evaluation techniques, including heuristic evaluation
by usability experts, “think-aloud” sessions, and user studies.
• Test interfaces thoroughly with representative users performing tasks under situations
that approximate those likely to be found in real use.
• Test user interfaces under extreme or suboptimal conditions, including high processor
load, network congestion, and noisy or extreme environments.
• Test web-based user interfaces for use by the public on as wide a range of browsers as
possible, including multiple older (and pre-release) versions of popular browsers and
screen-reader systems for people with visual impairments.
• Evaluate user interfaces, particularly web-based interfaces, to determine their impact
on other system goals such as reliability, security, accuracy, and privacy.
 
Security
 
Security underpins each of the issues discussed in this report.  Maintaining accurate and
13 13
 
private information is impossible if a VRD is vulnerable to malicious attack.  Further, the
validity of data within the VRD may be called into question if the system is easily
compromised or lax security policies are established.  Ultimately, an unsecured VRD
could undermine elections.  Good security policies address many different factors.  
Election officials should establish detailed access controls for each user accessing the
VRD, procedures to harden VRDs from attack, and mechanisms to deal with and recover
from security failures.
 
Security Recommendations
 
Designing & Implementing Access Control Policies
 
• Federal, state, and local election officials should work together to establish a common
framework for access control policies, such as common roles and responsibilities of
users and their levels of access, as well as who would be responsible for ultimately
implementing and enforcing access control policies.
• Access control policies should not grant the same privileges to all users; rather the
policies should group people by established roles and geographic areas.  For example,
the security policy might give the same level of privileges to all data entry officials
for a particular county, but privileges should be different for VRD administrators.
• Access control policies should minimize the number of people who receive privileges
both to access each piece of information and to grant access to others.
• Access control policies should ensure that each person is granted only the minimal set
of privileges needed to do his or her job.
• Access control policy should cover all records stored in the VRD including records
on both voters and non-voters.
• VRDs should use access control mechanisms provided in the database management
systems provided; trying to implement access control entirely at the application level
leaves greater opportunity for security mechanisms to be bypassed or compromised.
• VRDs should create public logs of all changes to the list of authorized users and their
access rights, and any changes to either of these should require authorization from
two different persons.
• Authorized users of the system should receive security training, including how to
protect passwords and how to resist social engineering attacks (attempts to deceive
someone into performing certain actions), and the importance of never sharing
passwords.
• Older versions of access control policies should be retained, along with their dates of
applicability, and possibly made available to the public to increase the transparency
of the system.
 
Administrative Privileges and Emergencies
 
• The number of people with administrative privileges for the VRD should be limited;
very few users should have the ability to grant access to others.
• People with administrative access should not be allowed to grant themselves new
access privileges unilaterally; rather, such a change should require the consent of
another administrator.
14 14
 
• Officials should create rules that allow trusted election officials to increase
temporarily the privileges available to others during emergencies in a controlled and
fully audited manner.
• Emergency overrides should require two-person authorization and generation of
detailed audit logs.
 
Security Metrics
 
• Those responsible for managing VRDs should measure how effectively they have
limited VRD users' privileges by determining how many people have access to how
much data and by tracking effectiveness over time using these metrics.
• The EAC or some other appropriate organization should help develop and identify
appropriate metrics.
 
Protecting Against Attack
 
• All communication channels used by the system should be secured.  Anything
transmitted over open communication networks, such as any wireless connection, the
Internet, or the phone system, should be protected using end-to-end cryptography.
• Firewalls should be used to severely limit connectivity between internal and external
networks.
• Mechanisms should be deployed to detect any penetration of system defenses or any
insider misuse.
 
Dealing with Security Failure
 
• It must be possible to recover from security failures (e.g., retaining historical copies
as well as the latest, regular backups with offsite storage, etc.)
• Officials should obtain independent security reviews of the VRD before system
deployment and periodically thereafter.
• Individuals should be notified if an inappropriate person may have obtained their
data.
 
Reliability
 
Because VRDs control access to voting, they must meet a very high standard for
reliability.  If the system fails, it may disenfranchise voters and undermine public
confidence in elections.  VRDs should be designed to be reliable both during the non-
peak times before and after an election, and for high-activity times such as Election Day.  
While reliability issues are often considered in terms of “always on” electronic systems,
registration systems may be economically designed to employ both online VRD and
offline solutions, such as distributing DVD-ROMs of registration data to polling places
for use on Election Day.  State and local governments should assess the entire scope of
reliability issues and design systems that have built in redundancy, replication, and
distribution, but also incorporate mechanisms that allow the voting process to proceed
should the VRD fail.  States may choose to implement the VRD by centralizing the
15 15
 
database at the state level or decentralizing it and spreading responsibility among the
different local jurisdictions; officials must recognize that reliability issues differ
depending on the chosen implementation.  
 
Reliability Recommendations
 
Redundancy
 
• Use redundancy to alleviate failures affecting time-critical operations.  
• Ensure that redundancy actually increases reliability by conducting system failure
tests.  
 
Replicated Data
 
• There should be multiple copies of the database.
• Copies should be physically separated to protect against physical damage.
• Copies should be logically separated (i.e., in different forms/types of systems) to
protect against software failure and attacks.
• The data on physically separate copies (such as DVD-ROMs) should be encrypted.  
Encryption and decryption mechanisms should be tested.
• Different channels, including alternate network providers and routes, physical media,
and printed copies to access different replicas should be provided.
 
Distribution
 
• Evaluate the ability of individual databases to function when other parts of the system
fail.  
• Evaluate distributed database solutions with respect to their ability to meet the
HAVA-mandated goal of a single, uniform, official, centralized, interactive
computerized statewide voter registration list.
 
Centralization
 
• Evaluate the ability of the system as a whole to respond to the unavailability of one or
more copies of the centralized database.  
 
Archives
 
• All changes to the database that affect the ability of an individual to vote must be
logged and archived.
• Archival media, including audit logs and backups, must be write-once or otherwise
protected to ensure that accurate records of changes to the VRD have been
maintained.
 
Election-Day Fallback Processes
 
• Develop fallback processes for registration verification so that elections can proceed
16 16
 
even in the face of system failures.
• Ensure that fallback processes will withstand any failure that would not otherwise
prevent voting.  If a power failure at a polling place does not prevent use of voting
machines, then it should not prevent voter registration checks to be performed.
 
Provisions for Delayed Entry of Registration Information
 
• Develop processes supporting delayed entry of registrations.
• Analyze the impact of near-deadline registration and early/absentee ballots on the
system.
 
Testing
 
• A defined and empowered quality assurance group should be in place from the
beginning of the project.  The group should develop functionality, usability, and
reliability tests.
• Periods of peak stress (e.g., immediately before registration deadlines, during
elections, and registration verification) should be identified for reliability testing, as
should the activity mix during periods of peak stress.  Consider questions such as how
many simultaneous users or operations are expected, and identify all potential
component failures.  Testing should check whether system performance will be
adequate even when some system components have failed.
• Tests for security against likely attacks (e.g., denial-of-service attacks) should be
conducted.
17 17
 
1.  Introduction
 
The Help America Vote Act of 20022 (HAVA) mandates that each state create a single,
uniform, official, centralized, and interactive computerized statewide voter registration
list by 2006.  The requirement that the list be both interactive and computerized implies
that the only compliant implementation will be as a database.  While the goal of
mandating the use of databases is to improve and streamline aspects of voter registration,
inappropriately designed or implemented databases will have serious negative impacts on
the accuracy of elections and on public perception.
In this report, we describe the characteristics that centralized voter registration
databases should possess.  While some recommendations might not be relevant to some
systems, most of our recommendations should be implemented if systems are to be
accurate, usable, secure, reliable, and appropriately protective of voters’ privacy.  In
those cases in which systems have already been designed or built, election officials
should consider modifications if our recommendations have not yet been included.
We start with an overview of voter registration databases and the Help America Vote
Act and then provide technical recommendations.
 
Voter Registration Databases (VRDs).  VRDs are statewide databases of registered
voters.   With the exception of North Dakota, which is the only state that does not have
voter registration, voter registration rules are created at the state level.3  Prior to the Help
America Vote Act, local jurisdictions maintained lists of voters, with list formats and
uses varying from jurisdiction to jurisdiction.  In general, the lists can consist of the
following:  
 
• full legal name,
• date of birth,
• last four digits of the social security number,
• driver’s license number,
• address of residence (to assign the precinct),
• mailing address,
• phone number,
• place of birth,
• party affiliation (so the correct election materials can be sent before primaries, and
correct ballots can be given at primaries), and
• validity status, noting whether the record is for a valid voter, or if the registrant is not
currently allowed to vote.
 
Some jurisdictions may request the full social security number and a digital image of
the individual’s signature for visual verification of mail-in ballots and initiatives.  
Jurisdictions may also retain voting history of registered voters and remove invalid
                                                
2
 Public Law No. 107-252, 116 Stat. 1666 (codified at 42 U.S.C. §§ 15301-15545), available
online at http://www.fec.gov/hava/law_ext.txt.
3
 For more information about state voter registration deadlines, see
http://www.eac.gov/register_vote_deadlines.asp.
18 18
 
registrations from the voting rolls.  Invalid voter registrations can occur if a voter has not
voted in several elections, has died, or has moved outside of the jurisdiction.  If a record
indicates that someone is not currently a valid voter, that individual must reregister.  
Some jurisdictions also include an indicator on a voter’s record as to whether or not the
address and phone number are to be given to outside organizations.
Election officials mail election materials, such as mail-in ballots and polling place
addresses, to the voters listed in the VRD.  Polling books or voter rolls derived from the
VRD enable local officials to verify that a voter is registered in the precinct served by a
particular polling place and that the voter has not previously voted in the election via a
mail-in ballot or early voting.  Polling books can be printed on paper or they can be
digitized and put on personal computers or electronic handheld devices, often called
electronic polling books.  While these devices may differ in design, in general they
connect either by phone lines or a wireless link to a master location that has the polling
information, or they are stand-alone and contain copies of polling information.  VRDs
also may be used to produce lists of voters, including names, addresses, and party
affiliations.  Such lists frequently are used by outside groups to send voters election-
related materials and to call voters in get-out-the-vote campaigns.  VRDs typically are the
basis for Internet-based voter information applications that enable people to determine if
they are registered and where their polling places are located.
 
Standards.  In light of recent events and legislation that have underscored the core
importance of voting and of public confidence in our electoral system, one might
conclude that all VRDs should be built and operated to the highest possible standards.  
While the highest standards of reliability, privacy, accountability, usability, and security
are desirable, they may at times be impractical because of resulting expense or system
response.  Nonetheless, where practical and reasonable, the highest standards should be
applied.
Standards for reliability, privacy, accountability, usability, and security allow for a
wide range of applications and choices.  Conventional commercial products and normal
practices, which may be suitable for business or governmental applications, might not
satisfy the difficult political and operational demands of voter registration systems.  The
cost of failure for a VRD, which may include a major loss of confidence in our political
system and institutions, must be considered in the standards-setting process along with
the other traditional costs that are the normal subject of evaluation.
This report discusses some standards that exceed the average commercial application
for database software.  While a higher standard may be recommended or included in a list
of options for consideration, the ultimate decisions about standards obviously are not ours
to make.  We hope that those decisions will be made with an awareness of and sensitivity
to the requirements essential to maintaining a high degree of public confidence in our
electoral system.
 
The Administration of HAVA.  The U.S. Election Assistance Commission (EAC),
created by HAVA, is charged with, among other things, assisting states in the
administration of Federal elections and establishing minimum election administration
standards.  It also provides states federal grants to replace punch card voting systems and
19 19
 
to establish and maintain statewide voter registration lists.4  The cost of developing and
maintaining voter registration lists could be more than half the overall cost of
administering elections.5  
Prior to HAVA, voter registration records often were maintained on a county or other
local level; these records frequently were not coordinated across counties.  What is new
with HAVA is the aggregation of all records statewide under a central administration and
in electronic form, thereby creating new challenges, risks, and opportunities.   
We address a variety of issues in this report with the understanding that many states
are nearing the completion of the HAVA-mandated implementation.6  As computer
systems are rarely finished, it is likely that the VRD implementations will continue to be
developed and enhanced and that our recommendations will be relevant well beyond the
initial implementations.
 
Other Studies.  This report focuses on the technology aspects of VRDs.  There are
several other studies that discuss different aspects of VRDs.  For example, “Balancing
Access and Integrity, The Report of the Century Foundation Working Group on State
Implementation of Election Reform”7 has an excellent chapter on VRDs.  This study,
while not as detailed as ours, includes more policy-related issues.  
The California Voter Foundation has an outstanding study, “Voter Privacy in the
Digital Age,”8 that details how information on voter registration lists is gathered and
used.  “Assorted Rolls, Statewide Voter Registration Databases Under HAVA” by
Electionline.org, is a complete snapshot of the States’ different plans and
implementations of HAVA-mandated statewide VRDs.  The Appleseed Foundation, in a
joint effort with Latham & Watkins and the Brennan Center for Justice, released a best
practices guide in 2005 offering guidance to states in developing their VRDs.9
 
Scope.  We make some assumptions to narrow the scope of our report to the kinds of
VRDs that are actually being used by the states.10  For example, we assume that the VRD
is implemented as an application using a commercial off-the-shelf database system.   
Commercial database management systems (DBMSs) are reliable, affordable, and have
many features that are needed for the VRD application.  However, the use of a
commercial DBMS is only part of the implementation.  Applications built on top of a
                                                
4
 42 U.S.C. § 15322.  
5
 Ace Project, Voter Registration Overview web page,
http://www.aceproject.org/main/english/vr/vr10.htm.
6
 Electionline.org, 2005, “Assorted Rolls:  Statewide Voter Registration Databases Under
HAVA,” Election Reform Briefing 11, June, available online at
http://www.electionline.org/Portals/1/Assorted%20Rolls.pdf.
7
 Century Foundation Working Group on State Implementation of Election Reform, 2005,
“Balancing Access and Integrity,” available online at
http://www.reformelections.org/publications.asp?pubid=542.
8
  California Voter Foundation, 2004, “Voter Privacy in the Digital Age,” available online at
http://www.calvoter.org/issues/votprivacy/pub/voterprivacy/index.html.  
9
 Appleseed, 2005, “The Database Dilemma: Implementation of HAVA's Statewide Voter
Registration Database Requirement,” available online at
http://www.appleseeds.net/download/Appleseed_Brennan_HAVA_Users_Manual.pdf.
10
 Electionline.org, op. cit.
20 20
 
DBMS include user interfaces, system design, and the implementation of various security
and reliability policies.  
Commercial DBMSs have features that are necessary for the VRD application such as
transaction logs and audit logs that maintain records of changes to the data and database
design.  The systems also provide mechanisms to backup the database.  A backup is a
complete copy of the database at a known point in time.  Transaction logs are used
together with backups to rebuild the system if there is a problem, restoring the data to its
state at the time of the backup.  Audit logs are used to determine if suspicious updates
have occurred.  Commercial DBMSs also provide access protections, so that only users
with the correct authorizations can access given data.  
VRDs may be top-down, bottom-up, or some combination of the two.11  In a top-down
approach, state officials administer a single master computer server; all voter records are
stored on that central server, and all requests to view or modify voter records are
executed on the central server.  In a bottom-up approach, each county may keep its own
database of records for voters within the county, and the county’s records may be
reconciled with a database run by the state on a periodic basis.12  Although these two
approaches have some different properties, most of the issues that we discuss apply
independent of whether the VRD is top-down or bottom-up.  Therefore, when we refer to
the VRD, it is worth keeping in mind that this database may in fact be implemented by a
collection of computer systems working cooperatively to store and maintain voter
registration records.  
 
Software Development.  Sound principles of project management must be followed
when developing software.  The knowledge of the people currently working in the local
offices, who may be experts in voter registration, should be assessed.  A single person
should manage the software development project and also bear responsibility for its
success.
Those working on the development of the VRD must be trained professionals who
have implemented database systems, preferably with the development tools of the chosen
vendor.  In addition, from the beginning there must be a trained quality assurance group
that is continuously testing the design and ultimately the implementation to make sure
that the application is reliable and accurate.
 
                                                
11
 The Electionline.org briefing cited above contains an excellent discussion of the distinction
between the two and why both can be considered HAVA-compliant.
12
 42 U.S.C. § 15483(a)(1)(A)(vi) (“All voter registration information obtained by any local
election official in the State shall be electronically entered into the computerized list on an
expedited basis at the time the information is provided to the local official.”)  The EAC Voluntary
Guidance has interpreted “expedited” as meaning “at least every 24 hours.”
21 21
 
2.  Accuracy
 
Maintaining the accuracy of VRDs requires balancing two opposing concerns.  The first
concern is that a VRD needs to be inclusive to avoid disenfranchising legitimate voters.  
The names of all people who have registered and are duly eligible to vote must be
included in the VRD; any omissions will exclude eligible voters from voting.  The
second, somewhat contrary concern is that the VRD must not be overly inclusive.  To
prevent fraud, only legally registered persons should be listed in the VRD as eligible to
vote.  We will address both of these concerns.
Not only must VRDs be accurate, the public must also believe that they are accurate.  
Because VRDs control access to voting, transparency is critical.  It must be possible to
convince those with interests in elections—including voters, political parties, politicians,
academics, and the press—of the correctness of the VRDs.  To provide transparency,
policies should minimize the possibility of error and facilitate the correction of errors.  
Election officials must also take responsibility for ensuring adherence to these policies.
 
Data Entry and Errors.  Most errors in individual database records occur during data
entry.  Errors include misspelling of names and addresses, incorrect recording of unique
IDs, misidentification of people to whom access to the system should be allowed or
denied, and misdirecting voters to the wrong polling place.
Data is entered into the VRD using one of two methods:  manual entry or via
automatic scanning devices.  An automatic scanning device is a machine that looks like a
copier and is used to scan a document into a computer system.  Once the document is
scanned in, software that can recognize characters transfers the data from the printed
form into the VRD, while providing a clerk with the opportunity to correct mistakes.  For
either manual entry or automatic scanning, a well-designed user interface for the clerk
will reduce errors.  (Chapter 4 on usability contains further discussion of user interfaces.)
While quality control systems and appropriate supervision of data entry may reduce
data entry errors, some errors will inevitably occur.  Problems can arise because of
variations of name spellings (Stevens or Stephens), first and last names that use accent
marks or more than one capital letter (McMullen), and names that have no vowels (Ng).  
Incorrect or incomplete spellings of street names are additional potential sources of
errors.  Changes that are primarily entered in other state databases—such as changes in
marital status and court approved name changes—also compound the challenge to
accuracy.  
 
Voter Verification and Notice.  To minimize the impact of errors in the VRD, voters
should be provided with (1) opportunities and methods to view and verify their data, and
(2) notices about changes to their records.  For example, the system might provide an
Internet website or automated telephone service where voters can examine parts of their
records, check their registration status, and determine their assigned polling places.  
Whenever a voter or potential voter is determined to be ineligible to vote, the reason
and source of information for the determination of ineligibility should be included in the
VRD.  This information should be retained so that someone who has been inappropriately
labeled as ineligible can easily challenge the decision and demonstrate that an error has
occurred.
22 22
 
Finally, election officials should mail each registered voter in the VRD a postcard with
his or her registration information and information necessary for voting, such as polling
place location or instruction for voting by mail.  Voters also should be notified when their
registration status changes.  A voter removed from the rolls or reassigned to a new
polling place should be notified by mail of the change and be provided an opportunity to
seek correction if the change is an error.  A voter recorded as having moved should be
notified by mail sent to both the new address and the old address (similar to the method
the United States Postal Service uses with respect to change of address forms).  
To help correct errors in voting records, contact information for the person or office
responsible for complaints and questions should be provided to voters.  Further, voters
and system administrators should understand how complaints and errors are addressed,
and voters should receive feedback explaining the reasons for a final determination.
One recent survey found that approximately two-thirds of surveyed states do not
notify voters who have been purged from the election rolls.13 Advance notice, which can
be facilitated by the VRD, would provide voters with an opportunity to identify mistakes
prior to an election.  Care must be taken in designing such systems so that violations of
privacy and security do not occur.
Notification processes are not always foolproof.  For example, in 2004, 8,800
Maricopa County, Arizona, residents received election notification cards listing the
wrong polling places in the wrong cities.14      
To help minimize the impact of incorrect notification, we recommend that public
notice be provided well in advance of an election.  That notice should include the polling
place’s geographic location and official name (school, church, library name), a
description of the exterior of the polling place to assist voters in locating the entrance,
times of poll operation, residential boundary lines, and corresponding zip codes.   
Some states allow voters to verify that they are registered through an Internet web site
or by phone.  For states that use Internet verification the user interface should protect
voters’ privacy by requiring the voter to provide his or her name and address and limiting
the response to “yes, you are registered to vote and here is where you go” or “no, you are
not registered to vote.”  The response should not include personally identifiable
information about the potential voter.
Some provision needs to be made to deal with corrections on Election Day because
not all errors can be corrected in advance.  Poll workers are likely to be preoccupied with
running an election and should not be allowed to make changes to the VRD.  Under the
right circumstances, after extensive testing for accuracy and usability, it might be
possible to allow poll workers to send electronic reports of needed changes to election
workers.  If such a system is implemented, the updates would need to satisfy the auditing
and authorization requirements discussed elsewhere in this report.  
A simple alternative is to provide paper forms that are filled out at the polling place
and submitted to election workers after the close of the election.
 
Generating the List of Registered Voters.  A printed voter registration list for those
precincts served by a polling place is typically used to verify registered voters.  While
                                                
13
 Electionline.org, op. cit.
14
 Dennis Wagner, 2004, “8,800 Voting Cards Have Wrong Poll Address,” The Arizona Republic,
October 27, p. B5.
23 23
 
these printed lists are convenient and easy to control, sometimes the wrong list is
provided to a polling place.  To minimize the chance of the delivery of an incorrect list,
we recommend that automated generation of polling place lists be used as much as
possible and that the lists be carefully checked by at least two people.  Local officials can
conduct these checks, but they need to be made far enough in advance of elections to
allow time for corrections.
Incorrect voter lists could be delivered to polling places independent of whether the
data are provided on paper, DVD-ROMs, in a PC, or in a handheld device.  In all of these
cases, a computer operator might provide incorrect directions to the computer, resulting
in the wrong electronic list going to the polling place.  As with paper printouts, we
recommend that electronic versions of voter lists be checked by at least two people well
in advance of elections to allow time for corrections.
 
Information Deletion and Retention.   In addition to being a list of currently registered
voters, a VRD is a comprehensive set of records reflecting voter registration activity and
administration.  Consequently, we recommend that after records appear to be no longer
relevant, they be retained in the VRD at least for the next two Federal elections or for the
statutorily-mandated minimum of twenty-two months.15  The retained record should
include a dated annotation stating that the voter is not eligible to vote, along with the
reason for ineligibility.  Thus, a VRD might contain information about those who have
applied, been approved, been questioned, died, moved, or been denied the right to vote,
as well as those who currently are eligible to vote.  
When records were stored on paper, retaining old records imposed a non-trivial
administrative burden.  Electronic databases have made the cost of retention negligible,
so old information can be retained relatively easily and inexpensively.  When information
is sufficiently old, it should be moved from the VRD into an offline archival database that
is never purged.  Retention of such information will enhance transparency and facilitate
the correction of errors such as those that can occur when voters are thought to have died,
moved, been convicted of a felony, or otherwise determined not to be eligible to
participate in a public election.   
 
Other Databases.   HAVA requires that states authenticate each potential voter by cross-
checking with other state databases—in particular, databases of driver’s licenses.16  If a
potential voter does not have a state driver’s license, then the last four digits of the
voter’s Social Security number must be used for authentication.   
Because other databases can be inaccurate as a result of ambiguous or incorrectly
entered data or computer-related problems, wholly automated procedures are risky.  
Consequently, we recommend that other databases not be used to enroll or de-enroll
voters automatically.  External databases could be used for initial screening, but an
appropriate election official should perform any final determination of voter eligibility or
                                                
15
 The Civil Rights Act of 1960 requires that every officer of elections retain for 22 months
registration and other voting records and papers for federal elections.  42 U.S.C. § 1974.
16
 HAVA provides for coordination of voters lists with other state agency databases (42 U.S.C. §
15483(a)(1)(A)(iv)) and requires that registration applications include either a current and valid
driver's license or the last 4 digits of the applicant's Social Security number (42 U.S.C. §
15483(a)(5)).
24 24
 
ineligibility.  We suggest that every change, addition, or deletion to the VRD require
explicit approval by an individual authorized to make that change.  We discuss how this
might be done in Chapter 5 on security.
Errors can arise because of court-approved changes in legal name that conflict with
existing birth records, motor vehicle records, or other state records.  Name similarities
also can create problems.  For example, a death record database may show that Mr. John
Smith who lives at 254 Vine St. has died.  There may be a Mr. John Smith, Jr. living at
the same address who is eligible to vote.  If the death record database is applied with no
cross checking, John Smith Jr. may learn on Election Day that he has been denied his
right to vote.   
Databases also can be inaccurate or unreliable because of computer viruses,
programming errors, and system failures.  For example, in 2003 the Maryland Motor
Vehicle Administration (MVA) offices were attacked by a computer worm.17  The worm
shut down the MVA’s computers and telecommunication systems, cutting them off from
all forms of remote communication and disrupting operations in all 23 MVA offices
located throughout the state.  A second event occurred on January 20, 2004, when the
MVA could not process work on the mainframe computer for about an hour after
opening.  The problem was characterized as a computer glitch.18
A further risk to the accuracy of databases is insider fraud, involving either the VRD
itself or external databases, such as driver’s license databases, that are used to
authenticate voters.19  Therefore, election officials should carefully consider if the
accuracy and security of external databases is sufficient to meet voter registration needs.  
Risks associated with insider fraud are discussed further in Chapter 5 on security.
 
Avoid Large-Scale Merges and Purges.  Computers make it easy to automate sweeping
batch updates to a VRD; at the same time, errors can be magnified by the use of
automation.  In the context of VRDs, a batch update is a group of updates received from
what is believed to be an authorized source (e.g., a local county).  Because many voter
records could be affected by a single batch transaction, a greater level of authority should
be required to perform a batch update than is required to make individual changes.  As is
the case with all updates, election officials should develop policies and procedures to
ensure the accuracy of large batch updates to the VRD.  For example, a policy might
prohibit batch updates affecting more than a maximum number of voters or jurisdictions
(essentially requiring that large changes be broken down into multiple smaller batches
that can be reviewed more effectively), or a policy might require individualized review
and approval of each voter record that is affected.  A policy might specify that batch
updates be reviewed by several people or mandate that audits of a statistically-significant
                                                
17
 Christian Davenport and Hamil R. Harris, 2003, “MD’s MVA Offices Forced to Shut Down,”
Washington Post, August 13, p. A09.
18
 “Glitch at MVA Branch Offices Delays Some Transactions for an Hour,” 2004, The Baltimore
Sun, January 21, p. B6.
19
 For example, a Maryland MVA employee was charged with conspiring with others to sell more
than 150 state identification cards.  See Eric Rich, 2005, “MD, MVA Employee Charged in ID
Card Sales,” Washington Post, April 23, p. B03.  For a collection of stories of security problems
of motor vehicle records, see Center for Democracy and Technology, Tracking Security at State
Motor Vehicle Offices, available online at http://www.cdt.org/privacy/030131motorvehicle.shtml.
25 25
 
random sample of records in the batch be performed before approving the batch update.
Given the inaccuracies that exist in many governmental databases, large-scale
automated merges between databases increase the risk of errors in a VRD.20  
Consequences of inaccuracies in other databases could result in the widespread
disenfranchisement of eligible voters, the inclusion of ineligible voters in a VRD, or both.  
We recommend special caution in deploying large-scale purges of VRDs.  The move
to a statewide VRD may make it tempting to attempt to automatically eliminate
duplicates by comparing lists of eligible voters across counties, something that previously
could not be done.  However, automatic purges of duplicate entries could disenfranchise
large numbers of legitimate voters.  If large-scale purges occur, they should be done well
in advance of any election, and all people whose names are purged from the VRD should
receive notification in sufficient time for them to be able to correct any errors arising
from the purge.
 
Accountability.  Clearly defined accountability for all changes to the database is a
fundamental requirement for helping instill voter confidence in VRDs.  Voters,
politicians, election officials, the press, and others should be able to determine who is
responsible for changes to the VRD.   
These changes include, changes to the data such as adding new voters, purging voter
records, changing addresses, names, etc.; changes to the software configuration such as
incorporating new software releases into the VRD; changes to the security policy and
access rights; or changes to the database design.  Any of these changes can adversely
affect the data, so in order to provide the desired accountability there must be a record of
each change, when it occurred, and who approved the change.
 
Audit Trail.  The record of the changes to the VRD is called an audit trail.  In order to
ensure accuracy and transparency, VRDs must be auditable.  VRDs that can be
independently verified, checked, and proven to be fair will increase voter confidence and
help avoid litigation.
The audit trail should include the record of all possible changes mentioned, namely,
data changes, configuration changes, security policy changes, and database design
changes.  Although we call this an audit trail, it is not a single entity.  The records of
configuration, policy and design changes, including who approved them, can be kept in
computer files or on paper as long as they are auditable by a third party.  The record of
changes to the data, because there will be many of them, must be kept in computer files
to facilitate auditing.
In DBMS applications, there are typically two files generated because of a change to
the database.  The transaction log records in a file the data values before and after the
change occurred, as well as the time of the change.  The audit log records information
about the user ID of the person who made the change.  The transaction log is used to
provide backup should a system failure occur.  
The content of audit logs varies among DBMSs.  In some, it is possible to configure
the system so that the audit log tracks changes to the security of the system (the
                                                
20
 In 1988, Congress enacted the Computer Matching and Privacy Protection Act to address some
of the unfairness and inaccuracies arising from federal government use of computer matching
techniques. See Public Law 100-503, 102 Stat. 2507 (codified at 5 U.S.C. §552a).
26 26
 
permissions given to particular users), changes to the data, and changes to the database
design.  For the purposes of the VRD auditing requirements, this is not sufficient.  The
VRD should record not only which user made the change, but also the identification of
the person who authorized the change.  Therefore, it may not be possible to rely on the
commercial DBMS’s auditing capabilities alone for the audit trail that a VRD requires.  
VRD implementers will need to augment the application code of the commercial database
audit log to provide a complete audit trail.
Well-maintained audit trails are critical because they may allow reconstruction of the
circumstances of a system failure, thereby facilitating future improvements to access
policies and possibly to the database itself.
 
Approval Mechanism.  Given that there is an audit trail that records whose approval was
given for each change, state or local officials must set policies on who is actually
authorized to make changes.  Access control polices are discussed in more detail in
Chapter 5 on security.  We assume that the person with ultimate authority to make the
changes is an election official, and we recommend that the responsibilities and authorities
of such election officials be clearly defined and publicly available.
For system changes, we recommend that there be a formal change control process that
states how changes to the system configuration, security policy, and database design are
reviewed, approved, and recorded.  
Summary reports or excerpts from audit trails should be provided to supervisors and
made available to external auditors.  These reports should be inspected frequently for
unusual or suspicious activities such as access from unexpected Internet Protocol
(commonly referred to as "IP") addresses or at unusual times of day, surges in the number
of accesses by a single user, and other anomalous activity.
 
Conclusion.   Well-designed accuracy features must be accompanied by appropriate
training and resources.  Even the best designed VRD will be of little value if officials do
not monitor and verify that only authorized changes are made to the VRD.  Log files that
are never read and system quality control processes that are not supervised will not
ensure database accuracy.  Since accuracy should be viewed as an ongoing responsibility,
election officials should assign specific staff to oversee these continuing activities.
 
27 27
 
3.  Privacy
 
Policies for voter registration activities should include appropriate protections for the
privacy of identifiable data about individuals.  A privacy policy should be based on Fair
Information Practices (FIPs), a set of principles for addressing concerns about
information privacy.  FIPs typically address issues such as how data is collected, secured
and used, and how policies regarding data practices are disseminated.  Specific
implementation recommendations are included in the discussion.
The increased computerization and sharing of voter registration records raises the
stakes for privacy.  While paper records also affect the privacy of data subjects, the risks
are greater with electronic records, which may be more vulnerable to improper
disclosures by more people.  Furthermore, the scope of the disclosures can be much
greater.  A thief can carry only so many paper records, but an entire electronic database
can fit unnoticed in someone’s pocket.
Technology also brings opportunities for privacy improvements, making it easier to
obtain and enforce the preferences of each voter for the use and disclosure of the voter’s
personal data.  Technological tools also facilitate the tracking of data.  To minimize the
threats and maximize the benefits of technology for privacy, it is necessary to build the
proper capabilities into VRDs.
Fair Information Practices, which form the basis of many privacy laws in the United
States and around the world, help to assure that any system of personal information
addresses all appropriate privacy elements.  The Privacy Act of 1974,21 a law that applies
to federal agencies, was the first statutory implementation of FIPs anywhere in the world,
and federal agencies have been operating under that law for more than 30 years.22  
Although there have been numerous restatements and versions of FIPs,23 core principles
address collection limitation, data quality, purpose specification, use limitation, security
safeguards, openness, individual participation, and accountability.  
While FIPs provide a useful framework for information privacy, the principles are not
self-implementing.  How they are implemented depends on the type of data, the record
keeper, the purpose of processing, the manner in which data is to be used and disclosed,
the costs, the technology, and the traditions of the jurisdiction or record keeper.  There
are often several strategies for implementing the same principle.  What is most important
is that any privacy policy should consider and address in an appropriate way all elements
of FIPs.  Some FIPs principles also reflect good record management policies.
The prevalence of identity theft illustrates why any sharing of personal information
can be a threat to an individual.  There is already some evidence that concerns about
privacy affect voter behavior:  one survey found that 23 percent of California non-voters
                                                
21
 5 U.S.C. § 552a (2002).
22
 Fair Information Practices were invented in America.  See Secretary's Advisory Committee on
Automated Personal Data Systems (Department of Health, Education & Welfare), 1973, Records,
Computers, and the Rights of Citizens, available online at
http://aspe.os.dhhs.gov/datacncl/1973privacy/tocprefacemembers.htm.
23
 The leading international statement of FIPs is by the Organisation for Economic Cooperation
and Development.  See Council Recommendations Concerning Guidelines Governing the
Protection of Privacy and Transborder Flows of Personal Data (1980), available online at
http://www.oecd.org/document/18/0,2340,en_2649_34255_1815186_1_1_1_1,00.html.
28 28
 
say they haven’t registered to vote because they want their information to remain
private.24  If voter records are perceived to be a source of data that contributes to the
widespread trafficking in personal information and to identity theft, some potential voters
may be discouraged from registering and voting.  Larger or centralized databases may
exacerbate these concerns.  Further, any inadvertent or malicious release of data can
affect millions of people and will attract considerable publicity.  The move to statewide
VRDs raises the privacy stakes considerably.
Privacy values, which too often are an afterthought for collections of personal
information, are fundamental for voter registration.  For this reason, some privacy issues
are intertwined with basic design standards and do not need to be addressed separately.  
This chapter addresses only those privacy policy matters of openness, data collection
limitation, and use and disclosure limits, which are not otherwise considered in this
report.  
 
Openness (Transparency).  Policies and practices for the collection, maintenance, use,
and disclosure of voter registration databases should be transparent, published, and
available to all upon request.   
 
Implementation Strategies
 
• Publish on the main election board website a complete notice of policies and practices
describing the collection, maintenance, use, and disclosure of voter registration data.  
The notice should include contact information for the office or the officials
responsible for the voter registration data.
• Publish a readable summary notice of policies and practices in other places such as on
voter registration forms, at polling places, on sample ballots, and elsewhere as
appropriate.
• Provide a copy of the complete notice to any person who requests it.
• Publish any changes to the notice before the changes become effective, and accept
and consider public comments.
• Place a date and version number on notices as they are published.  Maintain, and
make publicly available, copies of all previous notices, including the periods of time
during which they were effective.
 
Discussion.  A notice of policies and practices for the collection, maintenance, use, and
disclosure of personal information informs registrants, the public, and interested parties
of the relevant policies.  It also informs the staff of the election agency about the policies
and the need to conform to those policies.  Finally, clear notice imposes a discipline on
agencies helping prevent them from making ad hoc choices about their data processing
activities.  By requiring that these activities be properly disclosed in advance, privacy
policies prevent agencies from undertaking new data gathering or disclosures without
going through a formal process, thereby helping agencies resist pressures to use personal
information in new ways without sufficient oversight.
                                                
24
 California Voter Foundation, 2005, “California Voter Participation Survey,” available online at
http://www.calvoter.org.  
29 29
 
Formal privacy notices, like other legal notices, are often necessarily long and detailed
– likely longer and more complex than an average voter will care to read.  Consequently,
we recommend that a summary notice that is more accessible to the average voter and
brief enough to fit on commonly distributed forms be made available.
 
Collection Limitation.  The following principles should apply to the collection of
personal data.  
 
• All data should be collected by lawful and fair means.
• Data should be collected, where appropriate, with the knowledge or consent of the
subject.
• Registrants and the public should be informed through the published notice of the
policies and practices of all the sources of data obtained for voter registration
purposes.
• Data collection should be limited to sources and procedures authorized by law and
properly described in the published notice.  
• Only the minimum information necessary for and relevant to voter registration
purposes should be collected and maintained.  The reason for collecting each type of
personal information should be explained, and the specific data elements collected
should be subject to public scrutiny.
 
Discussion.  There are several reasons why the public should be informed in advance of
the collection and the source of the data, when such data about voters is obtained from
third party sources for purposes of updating, correcting, verifying, or amending the
database.  First, the public should know what data sources are being used so that it can
assess the validity and utility of the data sources.  Second, public disclosure may uncover
errors (e.g., use of inappropriate or outdated sources).  Third, the election agency will be
required to justify its choices, thereby reducing the chance that unnecessary data will be
collected.  For example, there is no reason for voter registration records to reflect
religious or sexual preference.
The collection of data with the knowledge or consent of the individual will be
accomplished in most instances through the published notice of policies and practices.  
The public identification of data sources normally will be sufficient to meet the
knowledge standard.  However, if data on a specific individual is being collected as part
of an examination of that individual’s eligibility, it may be appropriate to inform the
individual, seek consent for the collection, ask for cooperation in the examination, and
provide due process rights before taking any action that affects the individual.  It will not
always be possible to satisfy the consent standard.  For example, if voter registration
records are examined in an investigation of voting irregularities, notice or consent to the
subject of the investigation may be inappropriate.  However, in other circumstances, the
data subject may be the best source of information.
 
Use and Disclosure Limits (Purpose Specification and Use Limitation).  There should
be limits to the uses and disclosures of voter registration data by the agencies that collect
and maintain the data.  Personal data should not be shared with anyone outside the
election process without legal authority or the consent of the data subject.  Within the
30 30
 
election process, use of personal information should be limited to those officials who
have a need for the information in the performance of their duties.  All uses and
disclosures should be specified at the time of collection.  
 
Implementation Strategies
 
• Limit use and disclosure of voter registration data to those activities directly related to
the election process or expressly authorized by law.  
• Describe all uses and disclosures in the published notice of information practices.
• Identify publicly all recipients of voter registration data.
• Provide public notice of and, if possible, a chance for public comment on all
disclosures of identifiable voter registration data for any activity not directly required
for voter registration purposes.
• Restrict access to specific records, specific data elements, and specific classes of
voters (e.g., by location) to those election officials who have a need to use those
records, data elements, and classes in the performance of their duties.
• For some or all uses or disclosures, maintain a record of the date, nature, and recipient
of all personal information and make the record accessible to the data subject upon
request.
• Restrict disclosures to specific data elements permitted by law and necessary to
accomplish the purpose of the disclosure.  Withhold data elements that are not
essential to accomplish the purpose of the disclosure or that would place data subjects
in excessive jeopardy to identity theft or other improper activities.
• Prevent all recipients of data from using or disclosing the data in ways not
specifically authorized by law.  Asking recipients to sign data use agreements is one
way to accomplish this.  
• Allow some non-essential uses and disclosures only with the affirmative (opt-in) or
negative consent (opt-out) of the data subject.
• Limit disclosures to the greatest extent possible for data subjects at risk (e.g., victims
of spousal abuse, jurors, some public officials).
• Even the best use and disclosure policies may be violated by people and software
within the election process.  Therefore, limit access by each person and each system
component.  Chapter 5 on security provides further discussion on access policies.
• Provide access for every voter to a personalized list of those third parties who have
been given or purchased access to his or her voter registration data.
 
Discussion.  Use refers to the utilization of data internal to the operation of the election
agency.  Disclosure refers to any sharing of data with an external party.  Controlling both
use and disclosure is essential to maintain proper control over data and to prevent the data
from being used in inappropriate ways.  Controlling use and disclosure through formal
procedures and public notice will help limit function creep, which is the use of data for a
purpose unrelated to the purpose for which it was originally collected.
Whenever possible, use or disclosure should include only those data elements that are
necessary for the required purpose.  Limits on the disclosure of some data elements are
constitutionally required.  The principle is illustrated by a successful challenge in 1993 to
the disclosure of Social Security numbers from Virginia voter registration records
31 31
 
(Greidinger v. Davis25).  The plaintiff challenged the public disclosure requirement of
Social Security numbers as an unconstitutional burden on the right to vote.  The plaintiff
argued that the privacy interest in the number is sufficiently strong that the right to vote
cannot be predicated on disclosure of the number to the public or to political entities.  
The Fourth Circuit Court of Appeals agreed.  Following the decision, Virginia changed
its law.  The importance of restricting disclosure of some or all data elements has only
been highlighted by the epidemic of identity theft in recent years.  The Greidinger
decision was issued in 1993, well before identity theft had become a common crime and
concern.
The Greidinger decision also highlights the sensitivity of the use of any identification
number as part of the voter registration process.  While Congress mandated that a
registration application include a driver’s license number or the last four digits of the
Social Security number, excessive reliance on numbers for identity verification in voter
registration may not be successful, may create new risks to data subjects, and may expand
pressures for the use of identification numbers or identification cards in other contexts.  
While some secondary uses and disclosures of voter data are authorized by law, the
political process may impose limitations on what secondary activities are to be permitted.  
Some states make voter registration records public, while other states strictly restrict
secondary activities.  There are no clear right or wrong choices, but privacy standards
argue for limiting secondary data sharing to the greatest extent possible.   
Middle ground may be helpful at times.  While registration records will appropriately
be used for voting purposes, it is possible to offer each individual a choice with respect to
some secondary uses or disclosures.  The federal Driver’s Privacy Protection Act26
provides a model.  It describes a series of activities for which use and disclosure is
permitted without the consent of the data subject.  For other activities, the affirmative
consent of the data subject is a requirement.
Many methods can be used to give voters a choice about how their data will be
handled.  Under an affirmative consent (opt-in) model, personal information can be used
or disclosed for particular purposes only if the data subject agrees.  Consent can be
obtained orally or in writing.  Under a negative consent (opt-out) model, a use or
disclosure is permissible unless the data subject has stated an objection.  Individuals can
be offered choices through check boxes on applications or websites or in other ways.  
Sometimes it may be possible to ask each individual to make a choice about a use or
disclosure without establishing a default option.  For example, on a website, an individual
can be required to make a selection before moving on to the next screen.
The value of individual choice is that it gives the individual a voice in how his or her
records may be used for purposes that are not directly related to the purpose for which
information was originally obtained.  It is a way to resolve conflicts between data
subjects who desire privacy and officials and others who seek to use information in new
ways.  It is a middle ground between saying that records are never available and that
records are freely available.  The preference of the individual is a reasonable and
significant factor to consider when making decisions.  With computerized information  
 
                                                
25
 988 F.2d 1344 (4th Cir. 1993).
26
 18 U.S.C. § 2721 et seq. (2002).
32 32
 
systems, it is easier as well as practical to keep track of individual choices and to abide by
those choices.
 
 
 
33 33
 
4.  Usability
 
VRDs will be used by voters, election workers, and authorized officials from state and
local governments to perform crucial tasks.  As problems in data entry and interpretation
can easily disenfranchise voters, user interfaces for these systems must be designed to
minimize opportunities for error.
User interfaces that provide users with inadequate and unclear feedback can lead to the
entry of inaccurate data.  Displays that fail to provide indicators of system state (e.g., the
name of the currently authorized user) can introduce opportunities for malicious users.  
Data displays that include identifying information beyond the minimum level needed to
complete a task might compromise voter privacy.  Poorly designed voter registration
database user interfaces might confuse users and reduce confidence in the system, thus
creating a perception, if not a reality, of reduced reliability.  
 
General Usability.  User interfaces for voter registration database systems should be
designed to help all users complete their tasks confidently and correctly.  The design,
development, and testing process should explicitly account for wide ranges in user
training, backgrounds, and physical abilities, as well as the physical environments in
which these user interfaces will be used.
VRDs will be used by voters, election workers, and other authorized officials to
accomplish numerous tasks, including (but not limited to) registering voters, updating
registration information, verifying eligibility for a given election, and extracting summary
reports.  Each of these tasks involves one or more user interfaces that bridge the gap
between user tasks and the underlying database.
The range of possible users and uses make user interface design particularly
challenging.  Although some people—for example, county and state elections staff—are
likely to be frequent users who receive detailed training, many others—namely polling
place volunteers and voters—will use these systems infrequently, possibly without any
training at all.  Large variations in background, literacy, computer experience, and
physical capabilities (including disabilities) throughout the general voting population
complicate matters further.  User interfaces should be designed to be easily usable by a
wide variety of users in a variety of challenging environments employing strategies such
as providing text in multiple languages and providing alternative input and output
methods for people with disabilities.
The environments in which these systems will be used present additional challenges.  
Unlike systems that are only used in one well defined work context such as an office,
VRDs might be used in many places, including municipal offices, polling places, and in
homes or libraries via the Internet.  These differing use contexts require different user
interfaces.
The computing environment may also influence usability.  Computing platforms for
VRDs may have relatively minimal requirements for processor performance, network
bandwidth, memory, and display capabilities.  However, user interfaces that seem to be
functional when a system is not stressed can encounter usability difficulties when there is
a high system load, network congestion, or other demanding situations.  These issues are
discussed in more detail in Chapter 6 on reliability.
Human-computer interaction professionals know that simply adding an interface to an
34 34
 
already-designed system does not work well.  Interface design development,
documentation, and training materials should be addressed at the beginning of a project
and throughout its course of development and implementation.  While an early focus on
interface design and testing allows more time for refinement, user interface evaluation
can provide useful information at almost any stage in the software development process.
The needs of the wide range of likely users should be evaluated during the interface
design process.  Although it is clear that there will be many different types of users for
VRDs, not all types of users initially can be defined or identified completely.  Input from
classes of many potential users including voters, public officials, poll workers, and others
can help clarify user needs.  Serious consideration for user concerns also can have the
added benefit of building good will toward the project.
Before any user interfaces are designed, techniques such as interviews, group
discussions, and observations of users completing typical tasks with existing systems
(computerized or paper-based) can be employed to gather usability requirements and help
developers understand the contexts of use.  Such activities also will help developers
understand the difference between classes of users and how those differences will impact
user interface design.
Usability requirements can act as a starting point for an iterative cycle of design and
feedback.  Initially, simple mockups of proposed layouts will stimulate more input from
users and further clarify usability requirements.  In addition to being inexpensive to
produce, paper prototypes and other informal presentations of design proposals can make
some users feel freer to make critical comments than if they are presented with an almost-
finished version.  Feedback can be used to inform subsequent, more fully-realized
designs, with further iterations eventually leading to convergence on acceptable designs.
Structured evaluations can be useful for identifying specific usability issues that may
not arise in discussions with users.  Usability experts can examine user interfaces for
consistency, proper feedback, error handling, and other criteria.  Known as heuristic
evaluation, this technique is often very effective after just a few evaluations.  Direct
observation of potential users attempting typical tasks with proposed designs can also be
very helpful.  In so-called “think aloud” sessions, users are asked to tell observers what
they are doing and why.  This feedback helps developers identify potentially confusing or
disorienting aspects of a proposed design.  If multiple alternative designs are being
considered, a user study involving measurement of user performance (in terms of task
completion time, accuracy, or other objective measures) on meaningful tasks can help
clarify the strengths and weaknesses of the alternatives.
These measures may seem excessive to some, but frequent, early evaluations increase
the chances of finding problems with interface designs and other system features before
fixes become prohibitively costly.
The process of evaluating and refining user interfaces should continue after the
systems have been deployed.  As various users—including many who were not involved
in the design discussions and evaluations—work with the system, usability difficulties
and challenges will likely be identified.  Developers should assume that ongoing
feedback will lead to further user interface revisions.   
Although specific user interfaces will vary from state to state, all of the VRDs will
face similar usability problems.  Mechanisms for sharing insights gained during user
interface design and evaluation (while still respecting proprietary designs) can help
35 35
 
improve overall usability.  
 
Usability in the Service of Accuracy, Security, Reliability, and Privacy.  All user
interfaces should be explicitly designed to support the goal of building VRDs that are
accurate, secure, reliable, and sensitive to voter privacy concerns.
To be successful, user interface specification and design must be an integral part of the
software development process.  As mechanisms for ensuring accuracy, reliability,
security, and privacy sensitivity are developed, their impact on user interactions should
be carefully considered and user interfaces designed accordingly.  
Clear and useful feedback regarding the state of the system and the impact of user
actions is a crucial component of successful user interface design.  Such feedback can
play a role in guaranteeing system security and privacy sensitivity.  For example, user
interfaces used by polling workers or county officials might display a photo of the
currently logged in user at all times, allowing onlookers to verify that a task is being
performed by the appropriate person.  Prominent displays of system date and time can
show both users and (when appropriate) voters that the systems are configured correctly.  
Status alerts listing active network connections, along with indications of any that involve
unknown hosts, can be used to identify possible intrusion attempts.  Dialog boxes and
other alerts that warn users of the potentially undesirable outcomes of their action should
be displayed.  Well-designed displays of summaries regarding accesses to the system and
changes to voter records can help managers ensure that the system is functioning reliably
and securely.
User interfaces for VRDs should be minimal, containing only displays and
functionality that are necessary for the completion of specific tasks.  Because displays of
personal information create risks for invasion of voter privacy, these displays should only
contain information that is necessary for the task at hand.  For example, if the last four
digits of the Social Security number are used to verify identity, displays should contain
only those four digits, not the full number.  
When extraneous functionality is removed from an interface, opportunities for
malicious hacking, data theft, or entry of inaccurate data are also removed.  For example,
hardcopy printouts of voter registration data might contain unnecessary information that
violates voter privacy.  Proper privacy protection would mandate protecting and
destroying the printouts.  As modern printers generally receive data over a network
connection, hardcopy print facilities also have the potential to introduce security
vulnerabilities.  Limiting print functionality to cases where it is absolutely necessary can
reduce these privacy and security risks.
Eliminating extraneous user interface components can have other benefits as well.  
Simple user interfaces are often less cluttered and therefore easier to use, particularly for
novice users.  Decreasing the complexity of the interface also can simplify the underlying
implementation, potentially reducing development costs.
Usability considerations must factor in tradeoffs as well.  Supporting privacy,
accuracy, security, and reliability can sometimes reduce usability as can happen with
security measures that are explicitly designed to make systems unusable by unauthorized
users.  For example, systems that are used in public places might have forced logouts
after very short idle times to prevent unattended workstations from becoming inviting
targets, even though this will, in some cases, result in annoyance for the authorized users.  
36 36
 
Appropriate evaluations and user tests might identify aspects of interface design that
could negatively impact other design goals.  Each display and control can be evaluated to
determine if it might introduce potential problems or if it simply can be removed.  
Testing user interfaces under extreme or suboptimal conditions can provide insight
into the interplay between user interfaces and reliability.  Systems that simply freeze or
lock-up under extreme operating conditions are neither usable nor reliable.  Wherever
possible, systems should respond gracefully to stressful conditions, provide users with
appropriate feedback, and degrade to reduced functionality if some services are
unavailable.  
 
Usability for Election Staff and Government Workers.  Because errors in data entry,
retrieval, and interpretation by election workers and government officials can lead to
voter disenfranchisement, the VRDs should be designed to maximize the usability for
election officials while reducing these common problems.  The challenge of constructing
user interfaces to minimize these errors is complicated by the nature of the user
population.  County election officials and other municipal employees regularly use the
voter registration system.  These users can be provided with training that would enable
them to effectively use a reasonably complex system.  Volunteer election officials, on the
other hand, might use the system infrequently (perhaps one day per year) with minimal
training.  These users might also be relatively unfamiliar with some election jargon.
Polling places are often crowded, busy, and noisy on Election Day.  Noise,
interruptions, and other distractions can increase cognitive load on users, potentially
leading to an increased error rate.  Any election technology user interfaces that will be
used during polling should account for Election Day stresses.
Known user interface design techniques can reduce the frequency of errors in data
input, retrieval, and interpretation.  Data input forms should be designed with layouts that
clearly indicate the meaning of each field.  When possible, data provided on these forms
should be immediately validated for accuracy and consistency.  Error messages should be
as clear as possible, providing information that can help users respond appropriately, for
example, by correcting the input or by accessing external resources, such as
documentation or personnel, to clarify any confusion.  However, as mentioned in the
previous section, messages should avoid disclosing unnecessary information.
Modifications to voter record fields such as address or party affiliation can change a
voter’s precinct or render the voter ineligible to vote in some primaries or for certain
offices.   Functionality that might change the ability of one or more citizens to vote
should be available only to authorized users, but access controls are only the first step in
preventing harmful changes.  Exactly as desktop operating systems require users to
confirm potentially damaging actions before they are executed (“Are you sure you want
to delete this file?”), user interfaces for VRDs should require explicit confirmation from
the user before making any changes that would restrict or modify an individual's ability
to vote.  This confirmation might come in the form of a dialog box, or by requiring that a
certain check box be selected.  For changes that have wider impact, particularly batch
updates, displays should indicate the number of affected records.  Confirmation for these
changes should make users think twice before making significant changes.  Possible
approaches include multiple, sequential requests for confirmation, request for
reauthentication via retyping of the user name and password, or requiring that users type
37 37
 
a word embedded in an image (a so-called CAPTCHA™ test, commonly used for
registration on web sites).  Larger batch updates should require confirmation by the
current user and a colleague who confirms the action separately.  Where possible, undo
facilities should be provided.
User interfaces for specifying data retrieval parameters are similar to data entry forms:  
users must specify one or more values for each of several fields.  Once data has been
retrieved, it should be presented clearly on screens that indicate both the values of the
specified parameters and the fields that match those parameters.  Such a presentation will
help users distinguish between input errors and result interpretation errors.  Important
fields such as registration status should be highlighted.  Detailed feedback, including
appropriate contextual information and links to relevant rules and policies, should be
provided especially on problems and policies that might disenfranchise voters.  To
minimize the risk of infringing upon voter privacy, all displays of personally identifiable
information should be limited to include only details that are necessary for the task at
hand.   
Different users might require different user interfaces and training materials.  An
interface for election officials might provide information that is more detailed and use
specialized language that would be inappropriate for election volunteers.  Infrequent, less
well-trained users might benefit from training sessions, online tutorials, and online help.  
The context of use is also an important factor in interface design.  While audio indication
of input errors may be fine for office workers, noisy conditions in polling places might
render such output useless.  
Interface designs should be tested thoroughly, with representative users performing
typical tasks under situations that simulate as closely as possible those of real use.  These
challenging tests may identify usability problems that might not have been found during
testing under idealized conditions.
 
Usability for Voters.  Usable interfaces for individual voters have the potential to
educate voters, provide necessary information, and build confidence in the election
process.  Voters who are unable to perform voting tasks effectively might require help
from election officials.  If assistance is not available, a voter might simply walk away,
effectively disenfranchised by bad design.  
The deployment platform for voter user interfaces is an important concern.  Systems
for use by election officials and workers are likely to be dedicated, stand-alone packages
with completely custom user interfaces.  As the deployment of custom software to
individual voters is not practical, voters are likely to use web browsers to access
registration information.  Although the use of standard browsers offers many advantages,
including the ease of linking to relevant contextual data, browsers can be somewhat
limited in the types of feedback that they can display.  
The use of web browsers for general public-access user interfaces also presents testing
challenges.  These systems need to work with many different hardware and software
configurations.  Such systems need to have their performance verified on many web
browsers, including multiple older (and pre-release) versions of popular browsers and
screen-reader systems for people with visual impairments.  Designing to generic, vendor-
neutral standards is one way of achieving maximum portability; conversely, using one
vendor’s proprietary extensions is an almost certain way to restrict portability and access
38 38
 
by the full public.
Web-based user interfaces should be designed to maximize privacy and security.  
Retrieval of information about polling places and election policy should be based on a
minimal specification:  if the street address is sufficient for identifying a polling place,
the voter’s name should not be requested.   
 
Conclusion.  The importance of ease of use with VRDs cannot be overemphasized.  
User-friendly interfaces are essential if the systems are to be effective and credible.
 
 
 
 
 
 
 
39 39
 
5.  Security
 
This chapter examines the security mechanisms that enforce the decisions made about
who may read or update VRDs.  It also addresses ways of protecting against malicious
actions by both insiders and outsiders.
VRDs need to control who may access different kinds of information stored in the
VRD and under what circumstances they are authorized to do so.  Accordingly, the first
part of this chapter discusses access controls.  Careful control over who is allowed to read
or update the VRD reduces the possibility of intentional abuses and unintentional
mistakes by authorized users of the system.   
The right to view or modify some portion of the VRD is called an access privilege.  
The list of rules specifying who has which access privileges is called an access control
policy.   We examine the following aspects of data access:
 
• deciding who should specify which parts of the access control policy;
• determining who should have which access privileges;
• enforcing access control policies; and
• authenticating that people are who they say they are so the system can identify what
access privileges each user should receive when the system is in use.
 
Generally speaking, four broad classes of access privileges are commonly found in any
database system:
 
• Read privileges.  The authority to view, inspect, read, print, or otherwise access
certain records without modifying them in any way.
• Write privileges.  The authority to modify, update, add, or delete certain records.
• Administrative privileges.  The authority to specify what privileges are made
available to other users.  This includes the ability to create new user accounts, to
assign user accounts to specific employees, to specify or change the privileges
available to users, and to delete users.  In some systems, this category might also
include related privileges such as the authority to modify or patch software, the
database schema, and other administrative functions.
• Execution privileges.  Operations that the user is allowed to perform.  Execution
privileges are often enforced by another system component called the application
server.
 
Access control policies should minimize the number of people who receive privileges
either to access each piece of information or to grant access to others.  They should also
ensure that each person is granted only the minimal set of privileges needed to do his or
her job.  Following these guidelines can provide significant protection.
The second part of this chapter discusses how to harden a VRD against attack.  If a
VRD is not secured adequately, technical attacks by insiders who have access privileges
or by outsiders via hacking may undermine the VRD—for example, by inserting the
names of ineligible voters into the VRD or by removing names of eligible voters from the
VRD.  Since there are many ways that an attacker might try to subvert the system, one
needs processes that encourage secure system design and detect and close significant
40 40
 
vulnerabilities in the deployed system.  We discuss the following:
 
• providing security against technical attacks and other attempts to subvert the system
(system security); and
• dealing with security failures should they occur.
 
Dividing the Responsibility of Choosing an Access Control Policy.  Access control
policies provide an automated way for state and local officials to implement the accuracy
and privacy policies discussed in Chapters 2 and 3, respectively.  Access control can help
ensure that only authorized users are allowed to make authorized transactions.  
Establishing access control policies will likely require the cooperation of state election
officials and election officials from each local jurisdiction.  For example, state officials
might not have detailed knowledge of the staff and their responsibilities in each
jurisdiction; county officials are more likely know which county employees should
receive which kind of access.  However, county officials are unlikely to be able to set
statewide policy.  Therefore, we believe it will be productive if all relevant offices work
together in setting VRD access control policy.  We discuss some of the options for
structuring this process.
One possibility is a partially centralized model.  State officials might identify certain
common job roles, suggest a reasonable set of access privileges for each role, and perhaps
even require that local registrars adopt these roles and privilege sets.  For example, roles
might include (1) data entry clerk (who receives access privileges that permit the creation
of new records and editing of existing records subject to approval by other officials), (2)
election judge (who approves modifications to voter records for all voters within the
judge’s jurisdiction), or (3) registrar of voters (who receives access privileges that allow
him or her to create accounts for new users, assign these users to roles, and change the
role assignments for existing users).  To allow for local autonomy, localities might be
allowed to modify the roles and their privileges.
Alternatively, the partitioning of access privileges could be decentralized and left up to
county election officials, leaving the state officials with only tasks such as the following:
 
• Specifying the access rights that officials in one jurisdiction have to data belonging to
others.  This policy could be rigid, or subject to revision by the jurisdictions involved.
• Managing a list of job roles and purposes, so that people in different jurisdictions all
use the same terminology.  In other words, in situations where practices are the same,
make the vocabulary the same.
• Specifying (or recommending) maximum privileges that can be granted to each job
role and purpose.  A jurisdiction would be free to specify narrower privileges, if the
jurisdiction’s officials felt this was appropriate for their setting.
 
It is likely that even a centralized scheme will require some aspects of authorization to be
decentralized.  For example, the roles of authorized users are more suitably managed
locally, such as by a county registrar, than from afar by, say, the Secretary of State.  In
many cases a local registrar knows who local users are and thus is much less likely to be
deceived by an impersonator.
There is an opportunity for the EAC, or some other nationwide organization, to
41 41
 
provide sample roles and levels of privilege as suggestions to states and local
jurisdictions, leading to a more uniform vocabulary and starting point for states.  
Some composite actions might require privileges from more than one of the four
categories of access privileges (read, write, administrative, and execution).  For example,
moving a voter from one jurisdiction’s voter rolls to another’s might require both write
privilege (to delete the voter from the former jurisdiction’s voter rolls) and read privilege
(to obtain the information needed to add the voter to the new jurisdiction’s rolls).  
Normally, a user should be permitted to take a composite action only if the user has all
relevant access privileges.  Alternatively, such situations can be handled by access rules
that state who may execute the action.  The rules can be specified by an authorized user
who administers all the necessary underlying privileges and enforced in either a DBMS
or an application server.
The process used to assign categories of access privileges need not be the same.  For
example, it would be possible to assign administrative privileges via a semi-centralized
model, yet assign read and write privileges in a decentralized fashion.  One could also
separate administration of felony status from administration of addresses.
Determination of the access control policy does not need to be tied to details of how
data is physically distributed.  Access control policy might be determined in a centralized
or decentralized fashion regardless of whether the VRD data is stored at a centralized
location or is physically distributed.
 
Assigning Access Privileges.  The access control policy’s scope should  include all types
of access to the VRD including records on both voters and non-voters, database schema,
and so forth, and the VRD should be designed so that such a policy can be enforced.  To
reduce the overhead of administering privileges, we recommend the approach of
grouping people by their roles.  Most DBMSs and application servers support this
approach.  One might define groups of people, groups of data, groups of actions, and
specify rules for whole groups.  Election officials should specify very detailed rules on
who can access what.
It is advisable not to grant all users the same access privileges.  Instead of thinking in
terms of access to whole databases (e.g., the list of eligible voters or the database from
which the eligible voter list was derived), officials should determine specific access rights
for each user or group, limiting each user to appropriate data fields, subsets of voter
records, and purposes, as well as appropriate access modes (e.g., read, modify, delete,
create).  One can specify privileges for individual fields of all voters’ records (e.g.,
authority to modify party affiliation and preferred contact method but not the mailing
address).  One also can specify access privileges for sets of voter records (e.g., authority
to modify any part of the voter record for voters in Boston).  Separately, one can specify
access privileges in terms of groups of people (e.g., all data entry clerks receive the same
set of access privileges) or in terms of individual employees (e.g., a privilege granted
only to Alice Jones).   
The basic principle underlying a sound access control policy is to minimize the
number of people who have routine access (read or write) to each data item, and to
minimize the amount of data that each person has access to.  The rule of thumb is to give
each user of the system the minimum amount of access privileges he or she legitimately
needs to get the job done and nothing more.  This is often known as the Principle of Least
42 42
 
Privilege.
A related guideline is that users’ tasks should be structured to minimize the amount of
access they need and to minimize the number of people allowed to access information.  
For example, processes should be organized so that poll workers do not require routine
access to voters’ Social Security numbers or criminal conviction information.
The Principle of Least Privilege helps reduce the likely impact of security failures and
abuse should they occur.  For example, if some user’s password is discovered by a
hacker, then the hacker might gain access to everything to which the user has access.  In
this case, the damage will be far less if the user has only a limited degree of access to the
system.  By comparison, if every user receives full privileges to read and write every
voter record within the state, then penetration of a single user account could lead to
almost unlimited harm to the VRD.  The Principle of Least Privilege also helps reduce
the likelihood of insider abuse of privileges.
A user’s access rights should usually depend on his or her role, location, current
purpose, and so forth:
 
• User access privileges should be limited by jurisdiction.  Election officials normally
should not be granted privilege to read or modify records for voters registered outside
of their jurisdiction.  For example, San Diego election officials would normally not
need to read or modify the records of a San Francisco voter, so they should not be
given access privileges that would let them do so.  As a special case for voters who
move, a San Diego election official might be permitted to read the record of a San
Francisco voter when performing a transfer transaction that moves the voter to San
Diego County.  Initiating such a transfer also might require approval by a San
Francisco election official.
• An employee who processes registration forms might be allowed only to change a
voter’s driver’s license or phone number, while an official responsible for
determining eligibility might be allowed only to update whether or not a voter is
eligible.
• Access might also be limited by field.  For example, on Election Day poll workers
need read access to some information from the voter rolls (including voter names,
addresses, and party affiliations for some elections) to check voter eligibility at the
polls.  However, poll workers normally would not be granted any access to other
fields of the voter record because such access is not needed to perform their jobs and
because poll workers are not vetted as carefully as other users of the system.  The
access control policy should codify such privileges and restrictions.
 
Administrative privileges should be particularly restrictive; very few users should
have the ability to grant access to others.  Privileges also might be limited to account for
organizational relationships.  In certain circumstances, preventing municipal employees
from increasing the access levels of their supervisors might remove the possibility of
conflicts between database access policies and manager-employee relationships.  
Similarly, users with administrative privileges should never be allowed to grant
themselves new access privileges; requiring the consent of another administrative user
increases accountability.
Use of software that extracts and prints voter information, including the creation of
43 43
 
DVD-ROMs for political parties or poll workers, should be governed by the privileges of
the ultimate recipient.  In other words, documents or DVD-ROMs should contain only
data that all of the recipients are allowed to view, even if the creators of the documents
have additional privileges.  
It is likely that access control policies will need to be updated periodically.  As with
privacy policies, older versions of access control policies should be retained, along with
their dates of applicability.  Furthermore, officials may wish to consider making their
access control policies public in some form in the interests of transparency and to make
the chain of responsibility clear.
We recommend that those responsible for managing VRDs attempt to measure how
effectively they have limited privilege by characterizing how many people have access to
how much data and by tracking progress over time using these metrics.  For example, one
might count for each voter record how many people have some kind of access privilege
to at least part of this record and compute the average of this across all voter records.  
More refined metrics might reflect access to only some of the fields (e.g., affiliation but
not full SSN).  One might perform separate analyses for read access (to assess privacy
risk) and write access (as a risk to accuracy).  We stress that we mention these metrics
only as examples of what is possible.   
The EAC, or other nationwide voting administration organizations, could play a
helpful role in coordinating an effort to develop suitable metrics.  Ideally, such metrics
would be published by each state, enabling independent analysts to evaluate each state’s
effectiveness at setting access control policies and facilitating comparisons of practices
among states in a meaningful way.
Adding election workers to the system in an appropriate fashion is a crucial step in the
operation of a VRD.  It does no good to have restricted access rights if a corrupt official
can add new personnel with arbitrary access privileges.  There are two complementary
solutions:  public logs of all changes to the list of authorized parties including their access
rights, and a dual signature requirement for any changes to the list (also known as two-
person control).  Both should be adopted for most users of the system.  An exception
might be made in the case of poll workers with very limited read access to the system
(e.g., ability to view redacted records of only voters within their precinct) and no write
access.  In this case, approval by a single full-time election official might replace the
dual-signature requirement.
 
Access During Emergencies.  Provisions also need to be in place for handling
emergencies.  Officials should create rules that allow trusted election officials to
temporarily increase privileges available to others.  This might be achieved by creating
rules that enable additional privileges under emergency conditions, together with a
separate mechanism to declare to the system that an emergency exists.  Emergency
overrides should be tightly controlled, for example by two-person authorization,
generation of detailed audit logs regarding such events, notification of the person whose
privileges are delegated, and periodic proactive inspection of such audit logs.  No single
user should be permitted to declare an emergency and elevate his or her access privileges
during the declared emergency; instead, exercise of an emergency override should require
the active cooperation of at least two people.
Recognizing that people will occasionally be absent or overloaded with work, it will
44 44
 
sometimes be necessary to grant one employee some privileges belonging to another.  If
access control policies are based on roles, this can be done by temporarily assigning a
new role to the appropriate individual.  In any case, this should be done without revealing
either employee’s password to the other employee.  Emergency or unanticipated
delegation of access privileges should be temporary, preferably with automated
procedures to remove the extra authority.
 
Enforcing Access Policies.  DMBS and application server security provide several
mechanisms for specifying and enforcing policies with the goal of keeping administration
manageable.  First, DBMSs provide mechanisms for describing the set of users.  One can
 
• Define groups and assign users to them.  Groups, rather than individuals, then become
the basic unit of authorization.  Similarly, one may define a role to represent a
specific set of privileges (e.g., those associated with a job description).
• Give users additional descriptive properties that may be used for decisions.  For
example, officials might be associated with a list of zip codes for which they are
responsible.
 
Second, DBMSs provide the means for assigning privileges to users and enforcing the
access control policy.  One can  
 
• Grant a privilege for a group to access a field or specified fields of the database (e.g.,
encoding a policy that states that this user is permitted to view the voter’s address but
not the voter’s full SSN).   
• Grant access to a view that filters or summarizes the data but hides many details.  
Some views might filter by locality, while others might provide statistical summaries
that are widely releasable.  
• Grant access in which some items in a database are automatically filtered out based
on the current user or task.
 
Application servers offer some of these capabilities, together with privileges to execute
programs that implement business functions larger than a single DBMS request.  
The VRDs should use access control mechanisms provided in the DBMS; trying to
implement access control entirely at the application level leaves greater opportunity for
security mechanisms to be bypassed or compromised.  There should be no way for users
to bypass the access control mechanisms.  For each user request, either the application
server policy must approve the entire operation or the DBMS must enforce access
controls on each data access or both.  This requires examining the user’s individual
credential and the privileges associated with his or her job.  Implementing an access
control rule in the DBMS guarantees that the rule applies to all operations that developers
create.
 
Authentication:  Verifying Identity.  In any system with restricted access rights,
authentication is crucial.  The system needs a way for people to prove who they are; from
this, their access rights must be determined and enforced.
Authentication can be done in many different ways.  The most common form of
45 45
 
authentication is by user name and password.  While superficially attractive, password
authentication is subject to many failure modes including password guessing,
inappropriate sharing of passwords, and inadvertent or deliberate password leakage.   
Authentication schemes based on physical devices can be considerably more secure.  
Systems based on smart cards or timer-based tokens require the presentation of an
appropriately encoded electronic device (possibly within a defined time period) for
authentication.  Biometrics such as fingerprints or eye scans may also provide greater
security than simple textual passwords.
The potential advantages of these alternative authentication techniques may be offset
by increases in cost and complexity.  Lost smart cards are likely to be more expensive to
replace than lost passwords.  Biometrics systems may have difficulties in enrollment:  
difficulties in the initial capture of the finger, eye, or voiceprint may cause later problems
with authentication.
Security breaches in authentication mechanisms might be exploited to achieve
unfettered access to the underlying systems.  To avoid this scenario, authentication
mechanisms should be carefully designed and tested.  Authentication servers must be
highly secured, both physically and technically, and appropriate cryptographic techniques
should be used.  VRDs should not utilize any authentication techniques that have not
been validated by extensive use in production environments.
Biometric systems are especially tricky, because many current deployments have been
implemented improperly.  The use of fingerprints, retinal scans, facial features, and other
biometrics all rely on the conversion of these characteristics into strings of bits that can
be stored and processed by computers.  If these digitized versions of the biometrics are
transmitted across networks or stored on multiple computers, security weaknesses in the
networks or remote computers might be exploited to capture the biometrics.  A malicious
attacker who captures digitized biometrics might be able to use them to gain access to the
system.  In addition to reducing the security of the VRD, such attacks might compromise
the use of the specific biometric by the affected users in any other domain.  As a result,
biometric data should be stored as close to the user as possible, perhaps used only to
unlock a smart card.  In this scenario, the user’s fingerprint, for example, might be used
to verify that she is the authorized user of a smart card that would then be used to access
the VRD.  As the biometric data would be stored only on the smart card (which is
generally under the physical control of the authorized user), there are no network
connections or remote hosts to tempt malicious intruders.  
Biometrics also should be used only in a supervised setting to foil various forms of
spoofing attack.  There have been many reports of successful attacks on unsupervised
biometric authentication.  For example, with some facial recognition systems, holding up
a glossy photograph of an authorized user to the camera is sufficient to fool the system.  
There also have been published reports stating it is possible fool a fingerprint recognition
system by lifting the fingerprints of an authorized user off of a surface touched by that
person and creating a fake “gummy finger” made out of gelatin that bears the authorized
users’ fingerprint.27
Different authentication schemes might be appropriate for different users or different
                                                
27
 Tsutomu Matsumoto, 2002, “Gummy and Conductive Silicone Rubber Fingers: Importance of
Vulnerability Analysis,” pp. 574-575 in Advances in Cryptology - ASIACRYPT 2002, Lecture
Notes in Computer Science, Vol. 2501.
46 46
 
tasks.  The type of authentication being used should be determined by the type of task
that the user is performing, the expense and complexity of the authentication scheme, and
the potential harm that may be caused if the authentication system is breached.  
Advanced authentication schemes are more appropriate for election workers and
government officials with access to greater privileges over a wide range of voter records.  
In these cases, multi-factor authentication (such as requiring both a biometric and
password) may be warranted, despite its higher costs or inconvenience.
Another style of authentication relies on a technology known as certificates.  Apart
from authenticating the user, certificates allow for operation in the absence of access to a
permission database.  A certificate can contain a user's access rights in a form that is
mathematically protected from change.  When a certificate is presented to a system, that
system can enforce the user’s access rights using only the data presented.  Because
certificates are too long to be memorized or typed, they frequently are stored on smart
cards.
Once a user has been authenticated to the system, each operation on the database
should check that the person’s privileges allow him or her to perform that operation.  
Similarly, the database should create an audit trail for all requests that modify the
database.  Both of these goals are straightforward to achieve.  Logging read operations
may be feasible and useful though careful engineering is needed to ensure that the
logging system can handle the data volume.  As previously discussed, to guarantee that
these access controls cannot be bypassed, access control restrictions should be
implemented in the database itself, where possible.
The importance of security training cannot be overstated.  Authorized users of the
system must be taught about protection of passwords, how to resist social engineering
attacks—attempts to deceive someone into performing certain actions—and the
importance of never sharing their passwords, even with their colleagues and other
authorized users.  Training should include how to cope with failure scenarios such as how
to proceed when normal authentication mechanisms are for some reason not functioning.  
Because procedures that seem arbitrary are often ignored, users should also learn how
and why failure to follow procedures could lead to security breaches.  Knowing why a
rule is in place is the best motivation for following it.
 
Operational Security.  If a partial or whole database is transferred from a central site to
another location, protection becomes more difficult, especially if the data is transferred to
system with different security controls.  Digital signature techniques can protect the
integrity of database dumps; thus, a county system that receives a copy of its database on
a DVD-ROM could verify that the copy was properly created by the statewide system.  
Further, a combination of encrypted media and procedural controls (i.e., the presence of
two people to decrypt the data) can help.
 
Security Against Technical Attacks.  VRD systems must be secured against technical
attacks, including attacks both by outside “hackers” and by insiders.  When any system is
connected to an open communication network, including the Internet, a wireless network,
or the phone system, the risk from hackers becomes substantial.  Any network-connected
VRD will be exposed to attacks from anyone anywhere in the world who cares to attack
it; therefore, system security needs to be sufficiently robust to survive the inevitable
47 47
 
onslaught of attacks.  It is imperative that security be considered starting very early in the
software development lifecycle so that design decisions can be made in ways that
maximize security.  Trying to add security as an afterthought to a completed system often
leads to catastrophic security failures.
First, all communication channels should be secured.  Anything transmitted over open
communication networks such as the Internet, wireless network, or the phone system
should be protected using end-to-end cryptography (such as a VPN or an encrypted
network tunnel).  This cryptography requirement applies to all channels of
communication including those between local election officials and the central database.  
It may also be prudent to cryptographically protect all data sent over internal networks to
limit the damage if a hacker is able to break into the internal network or if an insider
seeks to attack the system.  Cryptography is especially important if wireless networks are
employed, because otherwise anyone within radio range can effectively gain insider
access to the wireless network.
Second, defenses should be applied to prevent outsiders from penetrating internal
systems.  Firewalls should be used to severely limit connectivity between internal and
external networks.  One simple strategy might be to completely disconnect voting
registration systems from all open networks.  For example, county officials might
communicate with central servers by sending authenticated DVD-ROMs through the
mail.  Alternatively, if network connectivity is necessary, firewalls should be used to
minimize the set of communication protocols, network services, and destination
addresses allowed to cross the firewall communicate from the internal network to the
external network or vice versa.
Mission-critical machines should be hardened as much as possible, and they should be
professionally administered.  All relevant security patches should be applied, and virus
scanners should be used where appropriate.  Unnecessary network services should be
disabled.  These machines and networks should be used only for voter registration.
Third, mechanisms should be deployed to detect any penetration of system defenses,
as well as any insider misuse.  For example, application-specific intrusion detection
systems could be used to monitor the number of updates to the VRD.  Any large spike in
activity, whether by an authorized user or in the aggregate, might warrant human
attention.  In addition, officials could consider contracting with a third-party network
security monitoring service to detect network intrusions and attempted attacks on the
system.
Fourth, care should be taken to ensure that it is possible to recover from security
failures.  Regular backups are a simple and effective method for recovering from known
failures.  All modifications to the database should be logged to write-once media to
provide a trustworthy audit trail and enable after-the-fact forensic investigations.  Offsite
storage of backups can reduce the risk of catastrophic loss of voter registration data.  
However, backups themselves must be secured, possibly including encryption, so that
their loss does not compromise voter privacy or reveal information.
Denial-of-service attacks are particularly vexing.  Such an attack could render the
VRD unreachable or non-functional when it is most needed.  Election officials should be
aware that systems connected to open networks are almost invariably subject to malicious
denial-of-service attacks that render the system unavailable or unreachable.  Because it is
beyond the state-of-the-art to completely prevent denial-of-service attacks, either officials
48 48
 
should have a plan prepared for how to ride out and survive such attacks, or they should
avoid the use of open networks.  For example, one might arrange to use DVD-ROMs if
the network has been rendered unusable.  Because of the threat of Election Day denial-of-
service attacks, officials should ensure that it is possible to function without any network
connectivity on this day.  Options might include downloading all critical data to polling
places several days in advance or distributing copies of the registration list printed on
paper.  These issues are also discussed in Chapter 6 on reliability.
Fifth, officials should obtain an independent review of their system before
deployment.  We recommend hiring a group of skilled experts to evaluate VRD security.
These experts will conduct a thorough risk analysis of system requirements, architecture,
security processes, and all other aspects of the system.  These reviews should check for
flaws that would allow attackers to obtain privacy-sensitive information, to compromise
the integrity of the database by modifying information without authorization, or to mount
denial-of-service attacks that would render the VRD inoperable.  The use of technical,
physical, and human procedural measures to attempt to penetrate a system can also
identify security problems that might otherwise have been overlooked.
Officials should consider including an independent security review and publication of
the software as part of the acceptance testing for the system.  Claims that the security of
the system will be endangered by such a review should be treated with extreme
skepticism or rejected outright.
Sixth, the technical security of the system needs to be viewed as an ongoing
responsibility, with resources devoted to it accordingly.  Election officials may find it
useful to perform periodic security audits of their system to ensure that system security is
kept up to date as technology and attacks change.  As the system will evolve over time,
and as the threats will change with time, it is important that the system be tested for
security issues on a periodic basis.  In particular, the system should be fully evaluated
after any major upgrades and after recovery from any significant incident
 
Dealing with Security Failures.  In spite of good security measures, there is always
some possibility that an attacker will carry out a successful attack.  When successful
attacks do occur, the system should protect the ability of users (including both election
officials and voters) to carry out their activities with as little disruption as possible.  
Additionally, because prosecution of attackers can act as a deterrent to future attackers, it
is important that systems be designed to support potential identification and prosecution
of attackers, for example, by keeping audit logs and maintaining a proper chain of
custody for relevant records.
Electronic registration databases heighten the need for well-designed recovery
mechanisms, because a statewide electronic database potentially introduces opportunities
for more, and more significant, failures.  To the extent possible, existing policies and
laws should be applied.
We discuss three categories of security failures:
 
• unauthorized disclosure of data in which some data is seen by someone who is not
authorized to see the data;
• breaches of integrity, in which ineligible voters are wrongly registered and/or actually
vote or in which eligible voters are disenfranchised or wrongly prevented from
49 49
 
voting; and
• breaches of reliability, possibly occurring on Election Day, in which legitimate users
of the database are unable to get necessary results.
 
Unauthorized Disclosure of Data.  Disclosure can occur by accident or on purpose.  
Unauthorized disclosure can happen when an authorized user of the system exceeds his
privileges, or when an outsider gains unauthorized access.  VRDs should incorporate
audit logs (discussed in Chapter 2 on accuracy) that record all attempts to read
registration data.  With appropriate scrutiny of these audit logs, it may be possible to
detect many cases of unauthorized disclosure.
To the extent possible, individuals should be notified if it is determined that data about
them has been or may have been obtained inappropriately.  Security breach notification
laws in California and other states are already having a beneficial effect in this regard.
 
Breaches of Integrity.  The intentional corruption of official records is both a federal
and state crime falling under many different statutes, giving prosecutors a number of
options.  However, unless appropriate audit trails, procedures, and detective controls are
in place, security breaches are unlikely to be noticed and identified as potential criminal
acts.
Because of the high legal and public relations cost of disenfranchising legitimate
voters or allowing ineligible people to vote on Election Day, states should have
procedures for auditing and quantifying the accuracy of registration data before an
election.  For example, election officials could perform an audit of a statistically-
significant random sample of all changes to the voter registration database since the last
election to look for anomalies, followed by a more thorough audit if anomalies are found.  
Such an audit should be performed sufficiently in advance that corrective actions can be
taken before Election Day if errors are discovered.
To avoid disenfranchisement of legitimate voters on Election Day, it is also important
to avoid creating a culture among poll workers that assumes that the computer is always
right.  In particular, it should be possible for someone who thinks she is a registered voter
but is not in the database to cast a provisional ballot that can be counted later, if it is
subsequently determined that she is an eligible voter.
 
Breaches of Reliability.  Unlike breaches of data and integrity, which can go undetected,
breaches of reliability are easily detectable.  Audit logs, including firewall logs, are
crucial for tracing and perhaps prosecuting malicious attackers.  To limit the impact of
reliability breaches on Election Day, we suggest that each polling place be given a
backup copy of the data that will be needed to validate eligible voters within that
precinct.  This list should contain only the information needed for validating voters.  For
example, Social Security numbers might be redacted from the backup list.  Existing
policies allow the polls to be kept open beyond the scheduled closing time if failures
occur; we recommend these policies be followed.  Reliability issues and fallback
procedures are discussed in more detail in the next chapter.
 
50 50
 
6.  Reliability
 
Reliability is often thought of as system availability (i.e., whether the system is up and
running 24×7).  However, to better understand reliability, we need to understand the
goals of reliability in a statewide VRD.
While 24×7 operation may achieve these goals, solutions that are more economical are
possible because reliability can often be achieved without continuous online access to the
database.  For example, if regulations impose a deadline for registration or registration
changes sufficiently in advance of an election, static snapshot copies of the database may
be adequate for supporting Election Day verification of voter registration.  Static copies
may well prove more reliable than attempting to guarantee reliable network access from
each polling place.
We assume that VRDs will have more intense usage in the months immediately prior
to the election, with a very large spike in usage during and immediately following the
election itself.  Activity before an election includes absentee voting, in-person absentee
voting, and early voting.  Absentee and in-person absentee voting occurs anywhere from
10 to 45 days before Election Day, and early voting usually occurs 10 to 14 days before
Election Day.
With this in mind, we divide the recommendations for design of a VRD into two
classes—namely, technical and operational mechanisms for ensuring reliability.  We also
give recommendations for ensuring reliability during the development of the database.
 
Technical Mechanisms for Reliability.  The hardware/software combination used to
access the VRD needs to provide good response and reliable service.  It should be
designed to work well both in non-election times, when the major activity is voter
registration, and in the high-activity times, immediately prior to and during the election
itself.
We list several design choices that can be used to improve reliability and discuss
recommendations and caveats to be considered when evaluating choices.
 
Redundancy.  While redundant communications systems (e.g., multiple network
connections from different providers) have been used successfully,28 care must be taken
to ensure that the systems are truly redundant.  For example, a modem and ADSL
connection29 over the same phone line provides little redundancy; two ADSL lines from
different providers probably provides less still, as they likely utilize the same central
                                                
28
 The Federal Aviation Administration, for example, makes frequent use of redundant systems
for air-traffic control.  This includes both alternate communication links such as redundant fiber
links for Airport Lighting Control and Monitoring Systems (see AC 150/5345-56) and
independent approaches such as using Flight Service Station communications as a backup for
relaying Air Route Traffic Control Center instructions if direct ARTCC contact is lost (see
Aeronautical Information Manual).
29
 “ADSL, which stands for Asymmetric Digital Subscriber Line, is a broadband communication
technology designed for use on regular phone lines. It has the ability to move data over the phone
lines at speeds up to 140 times speedier than the fastest analog modems available today.” From
http://www.dsllife.com/tutorial/faq.htm.
 
51 51
 
switch leased from the local telephone company.
A more robust form of redundancy is to support independent approaches to
accomplish the same task.  For example, using online access to a centralized statewide
database as the primary means of entering voter registrations allows immediate
verification of registration.  However, a power failure affecting a central database
immediately before a registration deadline could prevent registration workers from
entering registrations in time.  Allowing local entry, followed by later online
validation/verification of the entered values, could provide operational reliability similar
to redundant power sources for the central database, but at less cost.
 
Replication.  Replicating data in multiple places has value, but the impact of likely or
anticipated types of failures must be evaluated to ensure that replication significantly
increases reliability.  Replicating the database may not protect against software failures
that cause errors to spread to all copies, and keeping the replicated databases in different
physical locations has the added cost of space for the replicated system and
communication lines between the locations for updating the replicas.  Additionally,
replicated data may not be useful if communications problems at polling places make
network access unavailable.  Careful archival procedures combined with adequate
fallback procedures may be more cost effective and provide as effective reliability as
replication.
For example, sending DVD-ROM copies of the relevant part of the database to polling
places shortly before an election would provide both a high degree of replication and a
fallback procedure for access to the data if either centralized database or communication
failures occur.  However, the use of DVD-ROM copies must be tempered by the
increased risk of disclosure of information.  The information stored on such copies should
include only the data that would otherwise be available to the polling place and no more.  
As discussed in Chapter 5 on security, encryption and digital signatures, along with
appropriate policies for their use, should be used to protect these copies.
Building and including redundancy is not sufficient.  The system must also be tested
under realistic situations as discussed in the testing section of this chapter.
 
Distribution.  As was discussed in the introduction, statewide VRDs are being
implemented as top-down, in which the master copy of the database is stored in a
centralized location, or bottom-up, in which the master copy of the database is actually
distributed among many databases.  A properly designed distributed database can provide
a centralized list of voters as HAVA mandates.  The design of a distributed VRD must be
evaluated to ensure both that no single failure (hardware or software) can bring down all
the connected databases and that fallback procedures are adequate in each county to
protect against localized failure.
Distributed databases can serve as a good backup and contain damage caused by
failures, including software failures and actions of malicious insiders.  However,
designers must be aware that distributed database systems can be vulnerable to mass
propagation of errors if processes are designed to apply to all the databases at once.  
Another potential problem is to design a distributed database system so that individual
parts cannot act independently.  For example, one can design a system that requires that a
county database coordinate with a central database for every transaction.  It is important
52 52
 
to design a distributed database so that these possibilities are minimized.
Database distribution also increases the difficulty of ensuring the accuracy of the data,
unless the system is designed to coordinate the data in the individual databases.  One of
HAVA’s main requirements is that data should be coordinated between VRDs and other
databases; therefore, this element should be part of every distributed VRD’s design.
 
Centralization.  Centralized databases face a different set of reliability challenges.  If the
entire database is stored in a central location, this location becomes a single point of
failure.  Power difficulties, network problems, or other reliability problems with the
central location might bring voter registration activities to a halt throughout the state.  
Although replication and redundancy can help reduce such risks, additional costs may be
involved.  The use of alternative methods to access and input data, including DVD-
ROMs, printed voter lists, and paper forms, may be particularly important when
centralized databases are used.
 
Archives.  When data is backed up, the backup files can be recycled or can be retained as
long-term archives.  Archives safeguard against loss from software failures, intrusion, or
malicious insiders who could damage less resilient kinds of backup.  Consequently, an
archive must be protected from modification through write-once media such as DVD-
ROM to ensure against both accidental and intentional erasure or modification.
A second use of archival material is for forensics—that is, identifying what went
wrong when a failure occurs, correcting the problem, and preventing new failures (this
includes both human- and system-caused failures).  To ensure detection of malicious
action, it is important to log and archive all changes to the database.  With the decreasing
cost and increasing density of backup media, long-term maintenance of such logs, which
we recommend, can be achieved at reasonable cost.
 
Operational Mechanisms for Reliability.  Reliability will not be achieved solely
through technical means.  Provisions must exist to ensure the integrity of the election
process in spite of possible Election Day failure of the registration database.  Since it
should always be assumed that something could go wrong, a system must include
operational procedures, or fallback processes, that ensure reliability in spite of technical
failures.  While these procedures are often tied to the technical design decisions, it is
necessary to document the operational procedures to be followed in the event of database
failures.
We recommend that for each process there be at least one specified alternate process
to follow in case of failure.  In particular, there should be a fallback procedure for each
process that could affect the ability of people to vote on Election Day.  For example,
suppose the process requires that voters physically sign a voter registration list.  In case
the correct list is not sent to the polling place, we recommend as a fallback that there be a
back-up computer system and communication line available at the polling place, so that
people’s names can be looked up online.  If the process requires that voters’ names be
looked up online, then a fallback would be to provide paper copies of the list in case the
computers or their connections go down.  Further, Election Day verifications can be done
(1) via paper systems, (2) via personal computers or handheld devices with DVD-ROMs,
or other methods of holding static copies of the voter list, or (3) via personal computers
53 53
 
or handheld devices connected by electronic communication links to central VRDs.  
Regardless of the method used, a fallback process should be devised to deal with its
failure.  When appropriate, these processes should operate in tandem with provisional
balloting and other measures designed to protect a voter’s right to vote.
 
Provisions for Delayed Entry of Registration Information.  While direct entry of voter
registration information into the database may be desirable, allowing immediate
confirmation of registration that requires direct entry could undermine the registration
process in case of system failure.  As discussed previously, fallback procedures must be
developed to support alternate means of registration.
 
Testing Issues.  A VRD must be tested to ensure that it will function reliably when
placed into service.  The problem is that it is impossible to do a true stress test on a VRD
because there is no way to completely replicate the stress of an Election Day except to
have an election.  However, through effective modeling of the system and its capabilities,
it is possible to design tests that effectively simulate the stress of actual use.  This
imposes the requirements on the contracting agency of ensuring that sufficient
information is available for vendors/developers and quality assurance groups to
adequately model the system.   
Technical measures designed to increase greater reliability also should be tested.  
When used, replication and redundancy facilities might be tested by trying to operate the
system when all or part of the system is unexpectedly taken offline.  In accordance with
EAC recommendations, archival backups should be tested regularly.30
The system also should be secured against external network-based attacks (see
Chapter 5 on Security).  Tests that simulate denial-of-service and related attacks can be
used to evaluate the robustness of the VRD and possibly identify weaknesses that should
be addressed.
 
 
 
 
 
 
 
 
 
 
 
 
                                                
30
 U.S. Election Assistance Commission, 2005, Voluntary Guidance on Statewide Voter
Registration Lists, available online at
http://www.eac.gov/docs/Statewide_Registration_Guidelines_072605.html.  
54 54
 
 
Appendix A:  Glossary
 
Following is a relatively non-technical glossary of terms referred to in the report.  Our
intent is for the report to be readable by as many people as possible; for that reason, many
of the definitions below are not as technically detailed as they might be.  For more
exhaustive technical definitions or explanations of these and other related terms, please
refer to one of the two documents noted at the end of the glossary.
 
Access control policy – A list of rules assigning access privileges to system users.  
Access privilege – The right to read or update a particular kind of data, or to execute a
particular operation.
Application – One or more computer programs developed to provide specific
functionality.  Examples include such things as word processing applications, web
browsers, database software, and so on.
Authentication – The process of verifying that a person is who he or she claims to be –
for example, specific knowledge of a personal identification number (or PIN) is often
used to authenticate ATM card users.
Backups – Copies made for the purpose of safeguarding information; making regular
backups of important data is a widely recognized best-practice.
Batch update – A group of additions, modifications, or deletions to a database received
from what is believed to be an authorized source (e.g., a local county).
Biometrics – Authentication techniques that rely on an individual’s physical attributes
(for example, fingerprints, iris scans, facial recognition, and so on).
Bottom-up – Approach to managing voter registration data whereby each county or
municipality may keep its own database of records for voters within the county, and the
county’s records may be reconciled with a database run by the state on a periodic basis.  
See also “top-down.”
CAPTCHA™ (Completely Automated Public Turing Test to Tell Computers and
Humans Apart) – is a mechanism used to verify that a human user is completing a form,
as opposed to a computer program.  Generally, CAPTCHA tests consist of an image that
contains distorted text that is easy to read for humans, but very difficult for computer
software to interpret.
Certificate – A cryptographic tool used to verify such things as the identity of a
computer, the source of a program, the integrity of a message, or the identity of the
source of a message.
Ciphertext – Information rendered unintelligible except to those who can decrypt it;
(encrypted plaintext).
Data element – A basic data structure in a database (for example, “last name,” “address,”
“city,” and so on).  
DBMS – A database management system is a computer program (or a suite of programs)
55 55
 
that enables users to store, modify, and retrieve information from a database.
Decryption – The process of turning ciphertext back into plaintext.  See Encryption.
Denial of service attack – An attack on a system where the objective is to prevent the
normal use of that system, often by overwhelming the system with a large volume of
seemingly normal transactions or requests for data.
Digital Signature – An electronic signature based upon cryptographic methods of
originator authentication, computed by using a set of rules and a set of parameters such
that the identity of the signer and the integrity of the data can be verified.
DVD-ROM – Digital versatile disk (originally “digital video disc”) is an optical storage
disk similar to compact disks (CDs).  However, DVDs are capable of storing much more
data.  ROM, or read-only memory, refers to disks that are capable of being written to
only once.
Encryption – The process for turning plaintext (e.g., a person’s name and address) into
ciphertext, where the meaning of the encrypted plaintext is obfuscated.  See also
Decryption.
FIPs – Fair Information Practices, a widely accepted set of principles (e.g., notice,
security, minimization, and so on) for addressing concerns about information privacy.
Firewall – A means for preventing unauthorized access to a given system.  Firewalls
(both hardware and software firewalls) allow administrators to regulate the kind of traffic
and data that flow into and out of a system.
HAVA – The Help America Vote Act of 2002 (P.L. 107-252).  Election reform
legislation that mandated statewide VRDs.
Heuristic evaluation – A strategy for evaluating user interface designs.  In heuristic
evaluations, usability experts examine user interfaces for consistency, proper feedback
and error handling, and other criteria.  Heuristic evaluation can often be a cost-effective
alternative to more rigorous evaluation via controlled user studies.
Internet Protocol (commonly referred to as "IP") – is a connectionless, best-effort
packet-switching protocol and makes up part of the TCP/IP suite of protocols that enable
machines to communicate with each other on the Internet.
Intrusion detection system – An application designed to detect attacks on a network or
computer system.
Logs – Records of actions within a system, often contained in specific files (for example,
audit log files, error log files, and so on).  Information found in logs generally includes a
description of what was done, when it was done, who did it, and other details necessary
to construct and accurate and complete record of what happened.
Merges/purges – Batch updates that involve the integration, alteration, or removal of
large amounts of data in an automated fashion (for example, updating voter records in a
database by comparing data with a driver’s license database, or removing records in a
voter database based on records added to a death record database).
Plaintext – Intelligible information; generally in a form readable by a person (decrypted
ciphertext).
56 56
 
SSN – Social Security number.
Top-down – An approach to managing voter registration data whereby state officials
administer a single master computer server; all voter records are stored on that central
server, and all requests to view or modify voter records are executed on the central
server.  See also “bottom-up.”
Truncation – The practice of displaying only part of an identifying number (e.g., a
Social Security number) for the purposes of identity verification.
VPN – Virtual private network.
VRD – Voter registration database.
Web-based – Applications that are accessed via the Internet (or an intranet), generally
using a web browser (e.g., web-based email services like Google’s Gmail or Yahoo!
Mail).
 
Note:  Other relevant resources include the glossary associated with Volume One of the
U.S. Election Assistance Commission’s Voluntary Voting System Guidelines, which is
available online at http://eac.gov/vvsg_intro.htm, and the Consolidated Security Glossary
by the NIST IEEE POSIX P1003.6 Security Working Group, which is available at
http://www-08.nist.gov/posix/framework_wg/glossary.asc.  
 
 
 
57 57
 
Appendix B:  Biographies of Committee Members
 
Paula Hawthorn, Ph.D., Co-Chair
 
Dr. Hawthorn received her Ph.D. in Electrical Engineering and Computer Science from
the University of California in 1979.  Her thesis topic was on the performance of database
systems.  She has spent much of her career as a manager of database development,
including Vice-President of Software Development for start-ups such as Britton Lee and
Illustra, and both management and individual contributor positions at Hewlett-Packard
(working on database performance issues) and Lawrence Berkeley National Laboratory.  
She is now mostly retired, with occasional consulting and continuing involvement with
U.C. Berkeley.
 
Barbara Simons, Ph.D., Co-Chair
 
Dr. Simons earned her Ph.D. from U.C. Berkeley and was a computer science researcher
at IBM Research, where she worked on compiler optimization, algorithm analysis, and
scheduling theory.  A former President of the Association for Computing Machinery
(ACM), Dr. Simons founded ACM’s U.S. Public Policy Committee (USACM) and
served for many years as chair or co-chair of USACM.  She was a member of the
National Science Foundation panel on Internet Voting, the security peer review group for
the DoD’s Internet voting project (SERVE), and the President’s Export Council’s
Subcommittee on Encryption.  She is on several boards of directors, including the U.C.
Berkeley Engineering Fund and the Electronic Privacy Information Center, as well as the
Advisory Board of the Oxford Internet Institute and the Public Interest Registry’s .ORG
Advisory Council.  She has testified before both the U.S. and the California legislatures.  
Dr. Simons is currently co-authoring a book on voting machines and related issues.
 
Steven M. Bellovin, Ph.D.
 
Dr. Bellovin is a Professor of Computer Science at Columbia University.  He recently
joined the faculty after many years at Bell Labs and AT&T Labs Research.  He is an
AT&T Fellow and a member of the National Academy of Engineering.  Dr. Bellovin is
the coauthor of Firewalls and Internet Security: Repelling the Wily Hacker (2d ed. 2003)
and holds several patents on cryptographic and network protocols.  He has served on
many National Research Council (NRC) study committees and is a member of the
Department of Homeland Security’s Science and Technology Advisory Committee.  He
has been a member of the Internet Architecture Board and co-director of the Security
Area of the Internet Engineering Task Force.
 
Chris Clifton, Ph.D.
 
Professor Clifton has a Ph.D. in Computer Science from Princeton University, and
Bachelor's and Master's degrees from the Massachusetts Institute of Technology.  He first
worked on reliability and availability of database systems at IBM Research in the 1980s.  
He also worked on data mining and database security issues while at the MITRE
58 58
 
Corporation and, more recently, has been leading research on privacy-preserving data
mining since joining the faculty of Purdue University.
 
Lillie Coney
 
Ms. Coney is Associate Director with the Electronic Privacy Information Center (EPIC).
Her issue areas include nanotechnology, surveillance, children's privacy, civil rights and
privacy, coalition development, spectrum, census, and electronic voting.  Ms. Coney also
serves as Coordinator of the recently established National Committee on Voting Integrity
(NCVI).  NCVI was created in 2003 in response to growing concerns about the reliability
of electronic voting systems.
 
Robert Gellman
 
Robert Gellman is a privacy and information-policy consultant in Washington, D.C.  He
advises companies, government agencies, and other institutions on how to address
privacy concerns on the Internet, implement the federal medical-privacy rules, and
integrate privacy law and policy in their national and international operations.  A
graduate of Yale Law School, Gellman has worked on information-policy issues for more
than 25 years.  He spent 17 years as chief counsel to a subcommittee in the U.S. House of
Representatives responsible for privacy, freedom of information, government information
dissemination, health-record confidentiality, and other information-policy matters.  He
also served as a member of the U.S. Department of Health and Human Service’s National
Committee on Vital and Health Statistics (1996-2000), a federal advisory committee with
responsibilities for health-information infrastructure matters, including the Health
Insurance Portability and Accountability Act.
 
Harry Hochheiser, Ph.D.
 
Dr. Hochheiser received his Ph.D. in Computer Science from the University of Maryland,
and bachelor’s and master’s degrees from the Massachusetts Institute of Technology.  His
research interests include information visualization, bioinformatics, human-computer
interaction, universal usability, and privacy.  A former member of the board of directors
of the Computer Professionals for Social Responsibility (CSPR), Dr. Hochheiser wrote
CPSR's FAQ on Internet filtering systems.  He has also written about the policy
implications of Internet privacy protocols.  He is a founding member of the ACM
SIGCHI Committee on U.S. Public Policy.
 
Ralph Spencer Poore
 
Ralph Spencer Poore (Principal Consultant at Inovè LLC and Senior Partner at Pi "R"
Squared Consulting LLP) has over thirty years of information technology experience
with emphasis on privacy, security, audit and control in electronic commerce, enterprise
systems, and enabling technologies.  His involvement in national and international
standards for electronic commerce includes participation on two Internet Engineering
Task Force (IETF) working groups and chairmanship of an ad hoc working group of the
59 59
 
Accredited Standards Committee X9, Financial Services, subcommittee X9F Data and
Information Security.  He founded and chaired the Standards Review Committee of the
Information Systems Security Association (ISSA) and participates on the Global
Executive Committee of the Generally Accepted Information Security Principles
(GAISP) Committee.  Mr. Poore has developed and patented security and privacy
products, taught cryptographic security courses, and provided assurance services across a
broad range of private sector and governmental organizations.  He is an inventor, author,
and frequent speaker on topics ranging from privacy to transnational data flows.  Mr.
Poore is a Certified Fraud Examiner (CFE), Certified Information Systems Auditor
(CISA), Certified Information Systems Security Professional (CISSP), and Certified in
Homeland Security-Level III (CHS-III).
 
Arnon Rosenthal, Ph.D.
 
Dr. Rosenthal is a Principal Scientist at The MITRE Corporation, doing consulting and
research on databases and distributed systems.  In recent years, his research and
consulting has focused on data sharing, privacy, and security.  He received a Ph.D. in
1974 from U.C. Berkeley.  He was on the faculty of the University of Michigan and
worked at Sperry Research and Computer Corporation of America.  He has held visiting
positions at the Swiss Federal Polytechnic (ETH Zurich) and IBM Research.  He has
served on numerous conference program committees and is an Associate Editor of the
ACM Transactions on Database Systems.
 
David Wagner, Ph.D.
 
Professor Wagner is an Assistant Professor in the Computer Science Division at the
University of California at Berkeley with extensive experience in computer security and
cryptography.  Dr. Wagner is an Alfred P. Sloan Research Fellow and a CRA Digital
Government Fellow.  Dr. Wagner was a co-designer of one of the Advanced Encryption
Standard finalists, and he remains active in the areas of computer security, cryptography,
and e-voting.  In the past, Dr. Wagner has served as a member of the Security Peer
Review Group for the SERVE Internet voting project and as a technical advisor to the
ACLU Ad-Hoc Committee on Touchscreen Voting.  Currently, Dr. Wagner is a member
of the California Secretary of State's Voting Systems Technical Assessment Advisory
Board.
 
Rebecca N. Wright, Ph.D.
 
Dr. Wright is an Associate Professor in the Computer Science Department at Stevens
Institute of Technology in Hoboken, New Jersey.  Her research spans the area of
information security, including cryptography, privacy, foundations of computer security,
and fault-tolerant distributed computing.  Dr. Wright serves as an editor of the Journal of
Computer Security (IOS Press) and the International Journal of Information and
Computer Security (Inderscience), and she is a former member of the board of directors
of the International Association for Cryptologic Research.  She received a Ph.D. in
60 60
 
Computer Science from Yale University in 1994 and a B.A. from Columbia University in
1988. 

Related Articles

Global Technology Policy Newsletter – March 2017
ACM PUBLIC POLICY HIGHLIGHTS ACM provides independent, nonpartisan, and technology-neutral research and resources to policy leaders, stakeholders, and the public about public policy issues, as drawn from the deep technical expertise of the computing community. Apply for the new A ...Read More

  • (Posted on 12-Mar-17)
  • ACM Joint Task Force on Cybersecurity Education Grabs Spotlight at U.S. Congressional Hearing
    The ACM Joint Task Force on Cybersecurity Education seized the spotlight during a congressional hearing on “Strengthening U.S. Cybersecurity Capabilities” on Capitol Hill on February 14, 2017. The hearing before the House Science, Space, and Technology Subcommittee on ...Read More

  • (Posted on 18-Feb-17)
  • Global Technology Policy Newsletter – February 2017
    ACM PUBLIC POLICY HIGHLIGHTS ACM seeks to educate policymakers, the computing community, and the public about policies that will that foster and accelerate innovations in computing, computing education, and related disciplines in ways that benefit society. ACM Statement on U.S. E ...Read More

  • (Posted on 12-Feb-17)
  • ACM Sponsors Data Sciences Education Roundtable at the U.S. National Academies of Sciences
    ACM is sponsoring a new 3-year initiative by the National Academy of Sciences on data science postsecondary education. A series of roundtable discussions will bring together representatives from academia, industry, funding agencies, and professional societies to explore the trans ...Read More

  • (Posted on 17-Jan-17)
  • Global Technology Policy Update – December 2016
    ACM PUBLIC POLICY HIGHLIGHTS Cybersecurity Education and Research in Europe – The ACM Europe Policy Committee released a policy white paper “Advancing Cybersecurity Education and Research in Europe.” Committee Chair Fabrizio Gagliardi recently presented the find ...Read More

  • (Posted on 12-Dec-16)
  • Global Technology Policy Update – October 2016
    ACM PUBLIC POLICY HIGHLIGHTS Computer Science Education and Research in Europe – ACM Europe Policy Committee members will be attending the European Computer Science Summit in Budapest, Hungary on October 24-26, which features programs on the challenges and opportunities in ...Read More

  • (Posted on 09-Oct-16)