November 26, 2024

Rethinking the voting system certification process

Lawsuits! Everybody’s filing lawsuits. Premier Election Systems (formerly Diebold) is suing SysTest, one of the EAC’s testing authorities (or, more properly, former testing authorities, now that the EAC is planning to suspend their accreditation). There’s also a lawsuit between the State of Ohio and Premier over whether or not Premier’s voting systems satisfy Ohio’s requirements. Likewise, ES&S is being sued by San Francisco, the State of California, and the state of Oregon. A Pennsylvania county won a judgment against Advanced Voting Systems, after AVS’s systems were decertified (and AVS never even bothered showing up in court to defend themselves). And that’s just scratching the surface.

What’s the real problem here? Electronic voting systems were “certified”, sold, deployed, and then turned out to have a variety of defects, ranging from “simple” bugs to a variety of significant security flaws. Needless to say, it takes time, effort, and money to build better voting machines, much less to push them through the certification process. And nobody really understands what the certification process even is anymore. In the bad old days, a “federally certified voting system” was tested by one of a handful of “independent testing authorities” (ITAs), accredited by the National Association of State Election Directors, against the government’s “voluntary voting system guidelines” (the 2002 edition, for the most part). This original process demonstrably failed to yield well-engineered, secure, or even particularly usable voting systems. So how have things improved?

Now, NASED has been pushed aside by the EAC, and the process has been glacial. So far as I can tell, no electronic voting system used in the November 2008 election had code that was in any way different from what was used in the November 2006 election.

Regardless of whether we jettison the DREs and move to optical scan, plenty of places will continue using DREs. And there will be demand for new features in both DREs and optical scanners. And bug fixes. The certification pipeline must be vigilant, yet it needs to get rolling again. In a hurry, but with great caution and care. (Doesn’t sound very feasible, I know.)

Okay, then let’s coerce vendors to build better products! Require the latest standards! While brilliant, in theory, such a process is doomed to continue the practical failures (and lawsuits) that we’re seeing today. The present standards are voluminous. They are also quite vague where it matters because there is no way to write a standard that’s both general-enough to apply to every possible voting system and specific-enough to adequately require good development practices. The present standards err, arguably correctly, on the vague side, which then requires the testing authorities to do some interpretation. Doing that properly requires competent testing labs and competent developers, working together.

Unfortunately, they don’t work together at all (never mind issues of competence). The current business model is that developers toil away, perhaps talking to their customers, but not interacting with the certification process at all until they’re “done,” after which they pitch the system over the wall, write a big check, and cross their fingers that everything goes smoothly. If the testing authority shoots it down, they need to sort out why and try again. Meanwhile, you’ve got the Great States of California and Ohio doing their own studies, with testers like yours truly who don’t particularly care what the standards say and are instead focused on whether the machines are robust in the face of a reasonable threat model. Were the problems we found outside of the standards’ requirements? We don’t care because they’re serious problems! Unfortunately, from the vendor’s perspective, they now need to address everything we found, and they have no idea whether or not they’ll get it right before they may or may not face another team of crack security ninjas.

What I want to see is a grand bargain. The voting system vendors open up their development processes to external scrutiny and regulation. In return, they get feedback from the certifying authorities that their designs are sound before they begin prototyping. Then they get feedback that their prototypes are sound before they flesh out all the details. This necessarily entails the vendors letting the analysts in on their bugs lists (one of the California Secretary of State’s recommendations to the EAC), further increasing transparency. Trusted auditors could even look at the long-term development roadmap and make judgments that incremental changes, available in the short term, are part of a coherent long-term plan to engineer a better system. Alternately, the auditors could declare the future plans to be a shambles and refuse to endorse even incremental improvements. Invasive auditing would give election authorities the ability to see each vendor’s future, and thus reach informed decisions about whether to support incremental updates or to dump a vendor entirely.

Where can we look for a a role model for this process? I initially thought I’d write something here about how the military procures weapon systems, but there are too many counter-examples where that process has gone wrong. Instead, let’s look at how houses are built (or, at least, how they should be built). You don’t just go out, buy the lumber and nails, hire people off the street, and get banging. Oh no! You start with blueprints. Those are checked off by the city zoning authorities, the neighborhood beauty and integrity committee, and so forth. Then you start getting permits. Demolition permits. Building permits. Electrical permits. At each stage of construction, city inspectors, the prospective owners, and even the holders of the construction loan, may want to come out and check it out. If, for example, there’s an electrical problem, it’s an order of magnitude easier to address it before you put up the interior walls.

For voting systems, then, who should do the scrutiny? Who should scrutinize the scrutineers? Where’s the money going to come from to pay for all this scrutiny? It’s unclear that any of the testing authorities have the deep skills necessary to do the job. It’s similarly unclear that you can continually recruit “dream teams” of the best security ninjas. Nonetheless, this is absolutely the right way to go. There are only a handful of major vendors in the e-voting space, so recruiting good talent to audit them, on a recurring part-time basis, is eminently feasible. Meta-scrutiny comes from public disclosure of the audit reports. To save some money, there are economies of scale to be gained from doing this at the Federal level, although it only takes a few large states to band together to achieve similar economies of scale.

At the end of the day, we want our voting systems to be the best they can be, regardless of what technology they happen to be using. I will argue that this ultimately means that we need vendors working more closely with auditors, whether we’re considering primitive optical scanners or sophisticated end-to-end cryptographic voting schemes. By pushing the adversarial review process deeper into the development pipeline, and increasing our transparency into how the development is proceeding, we can ensure that future products will be genuine improvements over present ones, and hopefully avoid all these messy lawsuits.

[Sidebar: what about protecting the vendors’ intellectual property? As I’ve argued before, this is what copyrights and patents are about. I offer no objection to vendors owning copyright on their code. Patents are a bit trickier. If the auditors decide that some particular feature should be mandatory and one vendor patents it, then every other vendor could potentially infringe the patent. This problem conceivably happens today, even without the presence of invasive auditors. Short of forbidding voting machine patents as a prerequisite for voting system certification, this issue will never go away entirely. The main thing that I want to do away with, in their entirety, are trade secrets. If you want to sell a voting machine, then you should completely waive any trade secret protection, ultimately yielding a radical improvement in election transparency.]

Being Acquitted Versus Being Searched (YANAL)

With this post, I’m launching a new, (very) occasional series I’m calling YANAL, for “You Are Not A Lawyer.” In this series, I will try to disabuse computer scientists and other technically minded people of some commonly held misconceptions about the law (and the legal system).

I start with something from criminal law. As you probably already know, in the American criminal law system, as in most others, a jury must find a defendant guilty “beyond a reasonable doubt” to convict. “Beyond a reasonable doubt” is a famously high standard, and many guilty people are free today only because the evidence against them does not meet this standard.

When techies think about criminal law, and in particular crimes committed online, they tend to fixate on this legal standard, dreaming up ways people can use technology to inject doubt into the evidence to avoid being convicted. I can’t count how many conversations I have had with techies about things like the “open wireless access point defense,” the “trojaned computer defense,” the “NAT-ted firewall defense,” and the “dynamic IP address defense.” Many people have talked excitedly to me about tools like TrackMeNot or more exotic methods which promise, at least in part, to inject jail-springing reasonable doubt onto a hard drive or into a network.

People who place stock in these theories and tools are neglecting an important drawback. There are another set of legal standards–the legal standards governing search and seizure–you should worry about long before you ever get to “beyond a reasonable doubt”. Omitting a lot of detail, the police, even without going to a judge first, can obtain your name, address, and credit card number from your ISP if they can show the information is relevant to a criminal investigation. They can obtain transaction logs (think apache or sendmail logs) after convincing a judge the evidence is “relevant and material to an ongoing criminal investigation.” If they have probable cause–another famous, but often misunderstood standard–they can read all of your stored email, rifle through your bedroom dresser drawers, and image your hard drive. If they jump through a few other hoops, they can wiretap your telephone. Some of these standards aren’t easy to meet, but all of them are well below the “beyond a reasonable doubt” standard for guilt.

So by the time you’ve had your Perry Mason moment in front of the jurors, somehow convincing them that the fact that you don’t enable WiFi authentication means your neighbor could’ve sent the death threat, your life will have been turned upside down in many ways: The police will have searched your home and seized all of your computers. They will have examined all of the files on your hard drives and read all of the messages in your inboxes. (And if you have a shred of kiddie porn stored anywhere, the alleged death threat will be the least of your worries. I know, I know, the virus on your computer raises doubt that the kiddie porn is yours!) They will have arrested you and possibly incarcerated you pending trial. Guys with guns will have interviewed you and many of your friends, co-workers, and neighbors.

In addition, you will have been assigned an overworked public defender who has no time for far-fetched technological defenses and prefers you take a plea bargain, or you will have paid thousands of dollars to a private attorney who knows less than the public defender about technology, but who is “excited to learn” on your dime. Maybe, maybe, maybe after all of this, your lawyer convinces the judge or the jury. You’re free! Congratulations?

The police and prosecutors run into many legal standards, many of which are much easier to satisfy than “beyond a reasonable doubt” and most of which are met long before they see an access point or notice a virus infection. By meeting any of these standards, they can seriously disrupt your life, even if they never end up putting you away.

New USACM Poilcy Recommendations on Open Government

USACM is the Washington policy committee of the Association for Computing Machinery, the professional association that represents computer scientists and computing practitioners. Today, USACM released Policy Recommendations on Open Government. The recommendations offer simple, clear advice to help Congress and the new administration make government initiatives—like the pending recovery bill—transparent to citizens.

The leading recommendation is that data be published in formats that “promote analysis and reuse of the data”—in other words, machine-readable formats that give citizens, rather than only government, the chance to decide how the data will be analyzed and presented. Regular Freedom to Tinker readers may recall that we have made this argument here before: The proposed Recovery.gov should offer machine-readable data, rather than only government-issue “presentations” of it. Ed and I both took part in the working group that drafted these new recommendations, and we’re pleased to be able to share them with you now, while the issue is in the spotlight.

Today’s statement puts the weight of America’s computing professionals behind the push for machine-readable government data. It also sends a clear signal to the Executive Branch, and to Congress, that America’s computing professionals stand ready to help realize the full potential of new information technologies in government.

Here are the recommendations in full:

  • Data published by the government should be in formats and approaches that promote analysis and reuse of that data.
  • Data republished by the government that has been received or stored in a machine-readable format (such as as online regulatory filings) should preserve the machine-readability of that data.
  • Information should be posted so as to also be accessible to citizens with limitations and disabilities.
  • Citizens should be able to download complete datasets of regulatory, legislative or other information, or appropriately chosen subsets of that information, when it is published by government.
  • Citizens should be able to directly access government-published datasets using standard methods such as queries via an API (Application Programming Interface).
  • Government bodies publishing data online should always seek to publish using data formats that do not include executable content.
  • Published content should be digitally signed or include attestation of publication/creation date, authenticity, and integrity.

Obama's CTO: two positions?

Paul Blumenthal over at the Sunlight Foundation Blog points to a new report from the Congressional Research Service: “A Federal Chief Technology Officer in the Obama Administration: Option and Issues for Consideration”.

This report does a good job of analyzing both existing positions in federal government that have roles that overlap with some of the potential responsibilities of an “Obama CTO” and the questions that Congress would want to consider if such a position is established by statute rather than an executive order.

The crux of the current issue, for me, is summed up well by this quote from the CRS report’s conclusion:

Although the campaign position paper and transition website provide explicit information on at least some of the duties of a CTO, they do not provide information on a CTO’s organizational placement, structure, or relationship to existing offices. In addition, neither the paper nor website states whether the president intends to establish this position/office by executive order or whether he would seek legislation to create a statutory foundation for its duties and authorities.

The various issues in the mix here lead me to one conclusion: an “Obama CTO” position will be very different from the responsibilities of a traditional chief technology officer. There seem to be at least two positions involved: one visionary and one fixer. That is, one person to push the envelope in a grounded-but-futurist style in terms of what is possible and then one person to negotiate the myriad of agencies and bureaucratic parameters to get things done.

As for the first position, I’d like to say a futurist would be a good idea. However, futurists don’t like to be tethered so much to current reality. A better idea is, I think, a senior academic with broad connections and deep interest and understanding in emerging technologies. The culture of academia, when it works well, can produce individuals who make connections quickly, know how to evaluate complex ideas and are good at filling gaps between what is known and not known for a particular proposal. I’m thinking a Felten, Lessig, etc. here.

As for the fixer, this desperately needs to be someone with experience negotiating complex endeavors between conflicting government fiefdoms. Vivek Kundra, the CTO for the District of Columbia, struck me as exactly this kind of person when he came to visit last semester here at Princeton’s CITP. When Kundra’s name came up as one of two shortlisted candidates for “Obama CTO”, I was a bit skeptical as I wasn’t convinced he had the appropriate visionary qualities. However, as part of a team, I think he’d be invaluable.

It could be possible that the other shortlisted candidate, Cisco’s Padmasree Warrior, would have enough of the visionary element to make up the other side of the team; I doubt she has (what I consider to be) the requisite governmental fixer qualities.

So, why not two positions? Does anyone have both these qualities? Do people agree that these are the right qualities?

As to how it would be structured, it’s almost as if it should be a spider position — a reference to a position in soccer that isn’t tethered by role. That is, they should be free from some of the encumbrances that make government information technology innovation so difficult.

Please participate in research project — requires only one click

As part of a research project on web browser security we are currently taking a “census” of browser installations. We hope you’ll agree to participate.

If you do participate, a small snippet of JavaScript will collect your browser’s settings and send them to our server. We will record a cryptographic hash of those settings in our research database. We will also store a non-unique cookie (saying only that you participated) in your browser. We will do all of this immediately if you click this link.

(If you want to see in advance the Javascript code we run on participants’ machines, you can read it here.)

[I revised this entry to be more clear about what we are doing. — Ed]