E-Voting Company Agrees To Let California See Its Source Code... But Includes Angry Threats

from the how-nice-of-them dept

In the ongoing effort to make sure that electronic voting machines used in public elections actually have some sort of real scrutiny, we've never had anyone convincingly explain why the source code for these voting machines shouldn't be made public. You may recall that a while back, in a post about some of the limitations being put on security experts trying to examine some of the machines, a representative from the firm Election Systems & Software Inc. (ES&S) showed up in our comments and responded to our questions not with any good reasons, but with insults to everyone here saying we couldn't possibly understand. When asked, point blank, about why he wouldn't let experts like Ed Felten and Avi Rubin test the machines, he responded by claiming that such experts are misleading in their reports and are publishing things solely for a profit motive (which is pretty laughable, if you've ever read either's writings and analysis -- which come across as exceptionally even-handed on these issues). The same guy also claimed that the e-voting companies have always willingly handed over source code to gov't agencies. Specifically he stated: "The companies have always complied with legitimate requests to test and inspect the software. They handed over their source code for review on multiple occasions and have never denied the request of any U.S. government authority to review the code or test the equipment." Of course, he didn't say they did so happily. When California came asking for the source code, ES&S certainly wasn't happy about it.

You may recall that back in March, California's Secretary of State decided that anyone providing e-voting machines in California had to withstand independent testing from a group of security experts. This seems perfectly reasonable, and it's hard to come up with any reason not to do this... unless you're a company like ES&S whose machines have been caught counting votes in triplicate, among other things. Despite the claim that they "never denied the request of any U.S. government authority," ES&S certainly resisted the requests and only handed in the code three months late, along with an angry, petulant, threatening letter to the Secretary of State warning her that the company will hold the Secretary of State personally responsible "for any prohibited disclosure or use of ES&S' trade secrets and related confidential and proprietary information." Frankly, this should be reason enough to ban the company from having its e-voting machines used in elections. If the company is so worried about having its machines tested by security experts, then it shouldn't be in the business. Furthermore, for a free and fair election, there's simply no reason that the company shouldn't be required to make the core of its system freely available so that the voters of this country can actually trust that their votes are being accurately counted. It's not a crazy request. It's about protecting our fundamental right to vote. Apparently, ES&S doesn't respect that enough to prove to anyone that it can actually build a safe and secure machine that counts votes accurately.

Reader Comments

Subscribe: RSS

View by: Time | Thread

  1. identicon
    Rich Kulawiec, 29 Jun 2007 @ 11:15am

    Even source code's not good enough

    Suppose the source code's disclosed. Suppose (and this is
    highly optimistic assumption #1) that it's published for open
    peer review, and that, amazingly, it's found to be bug-free.

    Not good enough.

    Q1: How do we know that the compiled executable
    was built from that source code?

    Q2: How do we know that the compiled executable
    was built correctly, and without build system-installed
    back doors? (See "Reflections on Trusting Trust" by
    Ken Thompson.)

    Q3: How do we know that the executable is being
    executed properly? That is, that the hardware hasn't
    been modified or replaced in order to subvert the code?

    Q4: How do we know that the counting systems "upstream"
    from the voting machines are tallying correctly?

    And so on.

    The point being that not just the source code, but the
    entire system (the voting machines, the tallying machines,
    the communication networks connecting them, the processes
    used to operate them, etc.) needs to be secure/accurate.

    Moreover, it needs to withstand concerted, clueful, very
    well-funded attacks (See "How to Steal an Election" at
    Ars Technica as well as Bruce Schneier's analysis of the
    likely level of funding available to attackers.)

    I don't think that's possible at this time -- and it's certainly
    not possible while vendors of such systems are content to
    lie, lie, lie rather than candidly admit and promptly address
    the issues.

    Time for pencil and paper. Yes, it's onerous, and yes it
    too can be subverted by sufficiently-clever attackers --
    but it's much more robust. And I think preserving
    confidence in the integrity of the voting process --
    REAL confidence, not ersatz confidence based on the
    statements of the well-paid professional spokesliars
    working for voting machine vendors -- is worth the
    supposed inconvenience.

    I don't mind waiting 3-4 days for presidential election
    results if that's what it takes to ensure that the correct
    candidate is declared the winner.

Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here

Subscribe to the Techdirt Daily newsletter

Comment Options:

  • Use markdown. Use plain text.
  • Remember name/email/url (set a cookie)

Follow Techdirt
Techdirt Gear
Shop Now: I Invented Email
Report this ad  |  Hide Techdirt ads
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Report this ad  |  Hide Techdirt ads
Recent Stories
Report this ad  |  Hide Techdirt ads


Email This

This feature is only available to registered users. Register or sign in to use it.