Re: Observations on the new VVSG Guidelines

From: Alan Dechert <dechert_at_gmail_dot_com>
Date: Sun Jul 24 2005 - 14:06:49 CDT


> I think we ought to be more ambitious than that. We ought
> to push for the Guidelines to ...
I like your demands. Under the rubric of "demand more than you can get
and settle for what we can get" it makes sense.

One major issue with what you have here is that your are taking major
excursions into election law and procedures (sometimes there is a fine
line between law and procedures ... In CA we have the Voting System
Procedures Panel that decides things that almost have the effect of

For example, #6 you suggest OpenTest, which we are promoting in various
ways including state laws. While the EAC may be overstepping their
authority (states rights) to require OpenTest, they also need to take
into account the fact that they will be (in Illinois soon, other states
later) in conflict with state laws if their guidelines preclude

To achieve a really secure voting system has much to do with the
procedures surrounding the use of the technology. It doesn't matter
that much what the technology is if the procedures are faulty. The VVSG
doesn't have much to do with procedures. It probably should get into
that more, but how much can they do without re-writing states' laws?

Transparency is not valued in the VVSG. We should hammer on this point.

> 1. Not just recognize, but positively encourage, the use of open
> source software, firmware, et al. The purpose is, of course, to
> obtain full public review of as much of every system as possible.
> Let's avoid conflating this with the notion of "free software" (i.e.,
> software that those other than the developers may incorporate
> into their own products without limitation). ....
I agree that the EAC is probably not the place to fight the "free
software" for elections fight (I like to say "Public software for public
elections"), we also don't want the EAC and NIST (with their VVSG) to
impose barriers for to truly free software.

> 2. Require routine random hardware inspections, in which
> roving bands of inspectors seize a machine and determine
> what software, OS, firmware, etc. it's running -- tearing it to
> shreds if necessary. The Nevada Gaming Commission does
> this with electronic gaming machines. Do we value our votes
> as much as our gambling chips? This is, BTW, a great
> rhetorical point.
If thoroughly done, it would be expensive. Who does this work? How is
it funded? If it's done with very small samples, it might not be worth
much -- or even give a false sense of security.

> 3. Require parallel testing in a statistically-significant set of
> randomly-selected precincts during every election.
As with #2, this is potentially expensive. Ditto comments from #2.

> 4. Require *all* voting software, OS software, firmware, etc.,
> to be inspected before it's deployed, no matter how "minor"
> the changes from previous versions. ........
I think they'd argue that they already have that covered.

> No software or data should flow from a vendor directly to a
> jurisdiction unless (a) it's been inspected, signed off, and given
> an appropriate digital signature; and (b) the jurisdiction has
> the appropriate tools to check its authenticity (not provided
> by the vendor) and does so.
How does this compare with what's in the VVSG now? (yes, I'm lazy)

> 5. Require someone other than the vendor or test lab to build
> the system's software and firmware from sources, using
> publicly-known build tools not provided by the vendor and
> determine whether the resulting software/firmware is identical
> to that submitted by the vendor. It's too easy to cheat by
> instrumenting a compiler or linker to add malware.
Good points. How does this compare with what's in the VVSG now? (yes,
I'm lazy)

> 6. Require completely open testing and the publication
> of all test results.
Yes, but as noted earlier, this may not be (or maybe it is) the venue
for that battle. I'm pretty sure that EAC/NIST doesn't have the stomach
for this battle. But we should point out that OpenTest is coming and
they need to allow for that.

> 7. Require at least VVPAT with random recounts, if not VVPB.
Again, this is mostly a matter of state law. Ditto comments from #7.
Mainly, we want to remove things from the VVSG that might be barriers
for VVPAT. Especially, we want to remove any barriers for the
Electronic Ballot Printer (EBP) architecture. If we really want to
return the capability of the people to meaninfully participate in
counting the vote, we want EBP -- not VVPAT with sealed paper path.

VVPAT with sealed paper path is still a "trust us" voting technology
that few people can ever be involved in auditing. The design is not
conducive to easy paper handling by people. It is a machine-friendly
admin-friendly design -- not voter-friendly.

> 8. Outlaw wireless devices, period. And networked DREs,
> too -- because parallel testing can't be conducted on them
> without clueing them into the fact that they're being tested.
I think there are more reasons to outlaw wireless devices (than
outlawing networked DREs). This is something (outlawing wireless) that
may be doable under the VVSG. It doesn't look like they're thinking
that right now. The loss of transparency is not worth the convenience
of wireless.

The original Aussie system utilizing open source voting software with
commodity PCs in the voting stations was a paperless networked
architecture. I definitely think that's a bad design. However, if the
voting system prints a paper ballot that the voter can verify and put in
the ballot box -- and there are procedures in place to verify the
electronic record with the paper -- networking seems possible (although
it may fail on transparency, robustness, and other grounds). I think
standalone is better, but I'm not sure we should try to preclude
networked voting stations at this point.

> 9. Require systems to be randomly assigned to test labs,
> rather than vendors choosing any lab they like. Require
> test labs to be paid by the EAC, not by vendors, to
> reduce conflicts of interest.
Only SysTest and Wyle have applied for the new qualification of Voting
System Test Laboratory ("ITA"s qualified under NASED will not be
recognized within the next year or so).

I think there should be more test labs qualified, but the nature of the
industry will probably limit the number to only a few. So, I don't know
how much value random assignment would have. Where will the EAC get the
money to underwrite certification testing? Keep in mind that the first
chair of the EAC quit because they had a lot they were supposed to do
but no money with which to do it.

While it would be great in a way to have the FedGov pay certification
costs (these costs are a major obstacle to developers like us), it would
also mean that every Tom, Dick, and Harry, would be submitting systems
for certification as voting machines. So FedGov, if they took on this
resposibility, could see the budget for this balloon while providing
little benefit to secure voting. What if they did that with a blank
check for testing and certification costs, and over the next 10 years,
10,000 companies had systems certified for use in elections but only a
few of them had the marketing and organization strength to actually get
contracts with jurisdictions?

I'm sure there is a proper role for NIST and the EAC in all this.
However, we need to keep the big picture in mind too. For most of our
history, the voting system in America has been largely county-based.
State and Fed governments didn't have that much to do with it. As crappy
as it was revealed to be in 2000, it did have a positive quality of
decentralization. Part of the balance of power in the Constitution is
that states conduct federal elections (while that states in turn have
handed most authority to local jurisdictions).

HAVA has had the effect of shifting power from local jurisdictions to
states' and federal government. Do we really want the federal
government running federal elections? If we're not careful, that's what
we'll wind up with. I'm for decentralization as far as it makes sense
to do so. I think local jurisdictions can and should be in charge as
much as possible. Making voting systems inexpensive will help make this

We need to be very wary of making voting system certification a highly
centralized expensive process.

Alan D.

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Jul 31 23:17:19 2005

This archive was generated by hypermail 2.1.8 : Thu Sep 15 2005 - 11:43:09 CDT