David Jefferson's Comments on the FEC's Voluntary
Standards for Computerized Voting Systems
Submitted to the Federal Election Commission, September,
In response to the FEC's Voting
System Standards draft
Ms. Penelope Bonsal, Director
Office of Election Administration
Federal Election Commission
This letter is in respose to the request for comments on proposed revisions to the
1990 national voluntary performance standards for computerized voting systems published
in the Federal Register on July 10, 2001. I am sending my personal comments on the
VSS, appended below. I am also part of the WOTE '01 group, led by David Chaum and
Ron Rivest, and many of my concerns will be reflected in that group's response. I
am also on the Board of Directors of the California Voter Foundation, so some of
my comments are reflected in Kim Alexander's letter as well.
I'd be happy to discuss any of these issues further with you, either formally or
informally, if that would be of value. Just let me know.
Dr. David Jefferson
Compaq Systems Research Center
130 Lytton Ave.
Palo Alto, CA 94301
on the FEC Draft Voting Systems Standards
Let me first note that there are many things I like about the proposed standards.
To the extent I have studied them, they are on the whole excellent. One point that
I believe is particularly vital and courageous--since it is a big and possibly costly,
but necessary departure from past standards--is the requirement that any Internet
voting system must be re-examined annually to see if they should remain certified.
And there are many other points on which I think great progress has been made.
However, as is usually the case in a document like this, there is no time or need
to say much about all of the places where I agree with the document. What I am appending,
obviously, is my list of concerns--where I think it does not go far enough to safeguard
1) Extend the comment deadline: My strongest recommendation
is that the deadline for commenting on the VSS, Sept. 10, 2001, should be extended,
perhaps to Dec. 31. The VSS document is very lengthy and technical, but has been
public for only 60 days, and only during the maximally inconvenient summer period
when people are on vacation. Under the circumstances, 60 days does not seem long
enough for all of the relevant parties to study and make considered comments. I personally
feel very rushed on this schedule, and I have been part of the process and knew more
or less what to expect! Ideally, my response would have been more like 20 pages,
but in this time frame these general comments are all I can manage.
In addition, I want to point out that the computing security community has finally
begun paying attention to election security issues, and there is a large amount of
new work and new expertise that should be considered. A more extended comments period
would give this vital community time to digest the standard and respond appropriately.
See David Chaum's letter.
2) Continuous standards process: The standards
process for electronic and Internet voting systems should be made continuous, i.e.
the VSS process should not end for the foreseeable future. All digital technology
is changing with tremendous speed, and digital voting technology will be no different.
No standards written today are likely to remain reasonable for even 4 years; and
some standards that cannot be written today (e.g. for remote Internet voting--see
3 below) might become reasonable to contemplate at that time. As heavy a process
as that may seem, a continuous standards process is the only way to prevent the current
proposed standard from either stifling innovation or freezing in outmoded security
Remove remote Internet voting standards: The proposed standards for
remote Internet voting should be removed from the VSS document entirely at this point.
There is general agreement in the technical community that the security problems
with remote Internet voting are many and profound, and not likely to be remedied
satisfactorily any time soon. I realize that the standards are written in anticipation
of the day when security technology and infrastructure improves. But if standards
are published now for remote Internet voting, before it is actually possible to meet
them, vendors will surely endeavor to make the case that because the FEC standards
exist, it must be possible to satisfy them. It is just to early for even proposed
standards on remote Internet voting.
Instead, the FEC should create a continuous standards process, (see 2 above) and
add standards for remote Internet voting at some future date when and if technology
4) Operation in the face of total communication failure:
Pollsite Internet voting systems should be required to be able to operate normally,
with no interruption of service or attention by poll workers, even if all Internet
communication is lost and is never re-established for the duration of the election.
In effect this requirement would means that pollsite Internet voting systems must
be able to behave as DRE systems when pollsite Internet access is down or under attack,
etc. In fact, poll site Internet voting systems would reduce to simply a type of
DRE systems, i.e. those that have the capability of securely sending votes back to
the county frequently during election day, rather than just once at the end. The
difference between pollsite Internet voting and DRE systems is rather small, in my
5) Public source code: In all electronic voting
systems or subsystems, I believe that all software, firmware, scripts, and design
documents that have any relevance to the security of the election process should
be "public source", i.e. the source code should be open to the public for
inspection. It may still be proprietary, in that patent, copyright, and perhaps other
intellectual property rights may be held privately, and licensing restrictions may
be imposed upon its use. But the actual source code of the software should be open.
In particular, this requirement for public source code must apply to all security-relevant
code, including operating systems, device drivers, browsers, and other code which,
even though "off the shelf", and notwithstanding the fact that it might
be a widely-used product, might nonetheless have security holes that endanger the
security of the election.
6) Public design documents: The design,
specification and API documents for all components, hardware and software, of a voting
system should be available to the public. These documents should be detailed enough
that anyone in the business of building similar systems could create new equipment
to interoperate or replace the original systems. In other words, vendors should not
be able to exclude competition on the basis of design secrecy (though exclusion on
the basis of patent protection is, of course, permitted); and vendors can, of course,
compete on other bases, such as functionality, innovation, service, price, etc.
7) No single point of failure: There should
be no single point of failure in a precinct. This standard is actually mentioned
in the VSS document, in the one-sentence section 4.6.1 (which is a software section,
so the requirement is mislocated).We do not want the transition from paper to electronic
voting systems to lead to much greater accuracy, but much less reliability!
An election should be able to be conducted normally despite the total failure of
any single piece of equipment at a precinct. For example, the ability to continue
with total loss of Internet access (4 above) can be interpreted in this light. Similar
comments might be made about power failure requirements (e.g. require battery backup
and/or spare batteries). Likewise, the small but sometimes vital pieces of equipment
that may be part of some voting systems (e.g. printers, scanners, modems, hubs, clerk's
computers, etc.) should be required to be duplicated, and their consumables (paper,
ink cartridges, batteries, etc.) should all have spares.