Re: code validation?

From: Ron Crane <voting_at_lastland_dot_net>
Date: Thu Feb 24 2005 - 23:21:24 CST

On Feb 24, 2005, at 8:15 PM, Edward Cherlin wrote:

> On Wednesday 23 February 2005 09:03, Ron Crane wrote:
>> Eek! Such a proliferation of vendors will fragment the
>> open-source review community and thereby make it much more
>> likely that there won't be enough interested people available
>> to know about and review every change. And law is often a
>> remarkably weak tool to enforce compliance with complex
>> procedures. How would you write a statute requiring a vendor
>> to incorporate all significant security fixes? How would the
>> enforcement clause read? Could you get a TRO (temporary
>> restraining order) forcing the inclusion of a fix? Is a judge
>> going to understand what the hell you're talking about, or
>> will she refuse the TRO and let the case go to trial behind
>> 2 years' worth of criminal docket?
> In 2000 we saw the courts handle the election cases quite
> expeditiously.

And in 2004 we saw them handle the election cases which were much
heavier on technology issues than the 2000 cases quite slowly and
sloppily. The main Ohio recount case was mooted by Congressional
confirmation of the electors before it was even argued. Then the Ohio
attorney general tried (is still trying) to fine the lawyers who
brought it, arguing that it had been a "frivolous" action. . I have
little faith that most judges (or, for that matter, most administrative
agencies charged with implementing the procedures you describe below)
will understand the need to incorporate all legitimate security fixes.
They'll listen to the vendors and leave the public out in the cold.

>> Speaking of which, will
>> there be criminal penalties? Will they really be enforced?
> Wrong lever. Instead of mandating a development procedure, you
> put in a standard and mandate compliance. The software has to
> pass the standard test suite, including all known attacks, or it
> doesn't qualify for government purchase. If somebody discovers
> and publishes a new attack, all vendors must submit to public
> testing by anybody who feels like making the effort.
> So the security problem must be solved, whether or not the vendor
> chooses to use somebody else's published fix. A vendor that
> mucks up on security will also find that all of the known
> attacks on its code go into the test suite for the next cycle.

This would work well if electronic voting were starting from scratch.
Alas, many jurisdictions already have electronic voting equipment for
which they paid top dollar. If their vendors do not, somehow, pass the
tests, they'll have to buy a whole new set of equipment, for which
money just isn't in the budget. The personal penalties likely to be
experienced by the elections officials who bought failing equipment
will motivate them to do everything in their power to keep their
existing equipment, including certifying equipment that should be
certified only for disposal as toxic waste. We've already seen many
local officials resist security measures, even in progressive

> Just imagine if Internet Explorer/Outlook/Microsoft Exchange
> Server had to pass such tests to qualify for government
> purchases. How fast do you think Microsoft would clean up its
> act?

It would never happen. MS has much too large an installed base in
government for government to stop purchasing its software, let alone to
stop using it and to replace it with something else.

>> The question of legal enforceability is far from a theoretical
>> issue. During Ohio's presidential recount, local boards of
>> elections violated the recount statutes in numerous important
>> ways, yet, because of timing, the lack of appropriate
>> enforcement provisions, and/or the lack of certain public
>> officials' will to enforce the law, nothing was done about it.
>> The result was that "randomly" (as in "randomly choose which
>> precinct to recount") was defined as "whichever one we
>> choose", "recount" was defined as "run through the tabulator
>> as many times as is necessary to get the result to match the
>> election day total", "observe" (as in "citizen observers") was
>> defined as "be locked out of the building where the tabulation
>> occurred", etc. Many of these violations are felonies under
>> Ohio law, but I haven't heard a peep about prosecutions.
> The biggest flaw in the entire system. State governments hate to
> prosecute their own officials, especially those of the same
> party. Only public pressure can make it happen, and we don't
> have enough of it in Ohio.

Yes, alas. But that problem isn't confined to Ohio. Most states, and
the federal government so far, but HR 550 might change that don't
understand enough about the issue, nor care enough, to do much about
it. Some Ohio, Florida, and South Carolina come to mind are
positively retrograde. I recall Florida's governor actually deriding
e-voting security concerns.

>> Basically you have to trust the vendor to incorporate
>> suggested changes.
> Don't trust, verify.

That works only if the procedures you describe are vigorously enforced
[1]. But I think politics will curtail the level of enforcement to the
point of uselessness, just as politics put insecure voting platforms
into polling places in the first place, and just as it keeps them there

I think we need to pioneer the field by actually producing a complete
voting platform: software, turn-key hardware, support, and all via
voluntary use of the (very good) procedures you described. That would
not only provide a proof of concept and thus bolster the political will
to enforce such procedures, it might, of itself, drive many of the bad
machines off the market and out of polling places, particularly if we
were able to make our platform available at cost [2].


[1] And, even then, crafty vendors determined to cheat can do so via
hardware. See my replies to David Mertz from the afternoon of 2/23 for
some icky thoughts on this topic.

[2] Yes, this does raise the terribly thorny issue of financing. I have
some ideas for that.

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 Feb 27 17:17:13 2005

This archive was generated by hypermail 2.1.8 : Sun Feb 27 2005 - 17:17:13 CST