Re: Observations on the new VVSG Guidelines

From: Ron Crane <voting_at_lastland_dot_net>
Date: Sun Jul 24 2005 - 16:58:49 CDT

Alan Dechert wrote:

> Ron,
>> 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 law).
> 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
> OpenTest.

EAC is not overstepping any "states' rights" limitations. Remember what
the Supreme Court did on 12/12/2000? Basically it held that the
guarantees of the 14th Amendment's equal protection clause precluded
Florida's approach to recounts (at least in cases where the plaintiff is
named "Bush"). Now s.5 of the 14th Amendment gives Congress authority to
"enforce, by appropriate legislation, the provisions of this article."
Thus, when Congress thinks there's an equal protection problem, it can
override state election procedures -- at least for federal elections,
and arguably for all elections, since the right to vote is a
"fundamental" right guaranteed by the 14th Amendment. This is both an
opportunity (if we can get Congress (or Congress via the EAC to enact
good law) and a danger (if they enact bad law).

> 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.

Of course it would be expensive. Is it expensive for Nevada to rip
gambling machines to shreds? Sure. Is it worth it? Are our votes worth
more than our chips? Is our republic worth more than money? We should
hammer this until the hammer shatters, then get a bigger one and keep
hitting. Both the states and the federal government (should) be
overjoyed to pay for real voting security. Of course they're not -- yet.
It's our job to make them. By the way, they seem overjoyed to pay
$50/vote for Diebold DREs. Why is there money for that but not for real

>> 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.

Ditto by comments.

>> 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.

They don't. As my notes indicate, the VVSG are awfully ambiguous about
what has to be recertified and what doesn't. It would appear, for
example, that so-called OS patches don't have to be. 'Course a vendor
could just modify a "Microsoft" OS patch to include whatever it wants.

>> 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)

Please read my comments on the VVSG. I wrote them to stimulate
discussion here and to provide the seeds for our response to the VVSG.
Anyway, to summarize, the VVSG contains procedures covering some of this
area, but they're ineffective. For example, there's no requirement that
jurisdictions check authenticity, and the VVSG does not mention (or even
recognize the possibility) that a vendor-provided "authenticity check"
program could fake its results.

>> 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)

The vendor must build its software (no mention of firmware) under the
"supervision" of the test lab. The test lab needn't build it again.

>> 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.

So what if they don't have the stomach for it. Let's push it. If enough
credibile people push it, they'll develop the stomach for it. If we
don't push it, they'll get the idea that the VVSG are fine as-is, which
will make our job that much harder later on.

>> 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.

They should encourage VVPB. HAVA doesn't require it, so EAC probably
couldn't require it even if it wanted to. However, EAC can encourage it.
Right now it doesn't even explicitly recogize it.

>> 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.

We should go whole-hog against wireless, but still point out that every
network connection expands the required security perimeter and
introduces security risk -- both from malicious vendors (via malware
loaders) and from hackers.

>> 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.

Yes, that's a problem. But why can't we (the people) organize and fund a
REAL test lab? Then random assignment would have some meaning. 'Course
the vendors would have significant incentives to push the assigner to
avoid that lab....

> 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?

10,000 companies is not going to happen. There isn't enough money in
voting systems to support anything like that, and very few potential
vendors are motivated by anything but money.

> 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).

Ah, but Bush v. Gore changed that, as noted above.

> 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 possible.
> We need to be very wary of making voting system certification a highly
> centralized expensive process.

Well, certificaiton is already a highly-centralized expensive process.
The vendors and Big Government already control it. It could hardly get
worse -- except if it's revised to disallow paper and/or open e-voting

Anyway, I think we need to push for much tighter security and
transparency now, when we have the chance. It will only become harder later.


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