Archives for May 2006

Today, I gave a keynote at the SANE (System Administration and Network Engineering) conference, in Delft, the Netherlands. SANE has an interesting group of attendees, mostly high-end system and network jockeys, and people who like to hang around with them.

At the request of some attendees, I am providing a PDF of my slides, with a few images redacted to placate the copyright gods.

The talk was a quick overview of what I used to think of as the copyfight, but I now think of as the technologyfight. The first part of the talk set the stage, using two technologies as illustrations: the VCR, and Sony-BMG’s recent copy-protected CDs. I then switched gears and talked about the political/regulatory side of the techfight.

In the last part of the talk, I analogized the techfight to the Cold War. I did this with some trepidation, as I didn’t want to imply that the techfight is just like the Cold War or that it is as important as the Cold War was. But I think that the Cold War analogy is useful in thinking about the techfight.

The analogy works best in suggesting a strategy for those on the openness/technology/innovation/end-to-end side of the techfight. In the talk, I used the Cold War analogy to suggest a three-part strategy.

Part 1 is to contain. The West did not seek to win the Cold War by military action; instead it tried to contain the other side militarily so as to win in other ways. Similarly, the good guys in the techfight will not win with lawyers; but lawyers must be used when necessary to contain the other side. Kennan’s definition of containment is apt: “a long-term, patient but firm and vigilant containment of [the opponent’s] expansive tendencies”.

Part 2 is to explain. This means trying to influence public opinion by explaining the benefits of an open and free environment (in the Cold War, an open and free society) and by rebutting the other side’s arguments in favor of a more constraining, centrally planned system.

Part 3 is to create. Ultimately the West won the Cold War because people could see that ordinary citizens in the West had better, more creative, more satisfying lives. Similarly, the best strategy in the techfight is simply to show what technology can do – how it can improve the lives of ordinary citizens. This will be the decisive factor.

In the break afterward, somebody referred to a P.J. O’Rourke quote to the effect that the West won the Cold War because it, unlike its opponents, could provide its citizens with comfortable shoes. (If you’re the one who told me this, please remind me of your name.) No doubt O’Rourke was exaggerating for comic effect, but he did capture something important about the benefits of a free society and, by analogy, of a free and open technology ecosystem.

Another American approached me afterward and said that by talking about the Cold War as having been won by one side and lost by the other, I was portraying myself, to the largely European audience, as the stereotypical conservative American. I tried to avoid giving this impression (so as not to distract from my message), calling the good side of the Cold War “the West” and emphasizing the cultural rather than military aspects of the Cold War. I had worried a little about how people would react to my use of the Cold War analogy, but ultimately I decided that the analogy was just too useful to pass up. I think it worked.

All in all, it was great fun to meet the SANE folks and see Delft. Now back to real life.

Susan Crawford reports that the ICANN board has voted not to proceed with creation of the .xxx domain. Susan, who is on ICANN’s board but voted against the decision, calls it a “low point” in ICANN’s history.

[Background: ICANN is a nonprofit organization that administers the Domain Name System (DNS), which translates human-readable Internet names like “www.freedom-to-tinker.com” into the numeric IP addresses like 192.168.1.4 that are actually used by the Internet Protocol. Accordingly, part of ICANN’s job is to decide on the creation and management of new top-level domains like .info, .travel, and so on.]

ICANN had decided, some time back, to move toward a .xxx domain for adult content. The arrangements for .xxx seemed to be ready, but now ICANN has pulled the plug. The reason, apparently, is that the ICANN board was worried that ICM, the company that would have run .xxx, could not ensure that sites in the domain complied with all applicable laws. Note that this is a different standard than other domain managers would have to meet – nobody expects the managers of .com to ensure, proactively, that .com sites obey all of the national laws that might apply to them. And of course we all know why the standard was different: governments are touchy about porn.

Susan argues that the .xxx decision is a departure from ICANN’s proper role.

ICANN’s mission is to coordinate the allocation of domain names and numbers, while preserving the operational stability, reliability, and global interoperability of the Internet. The vision of a non-governmental body managing key (but narrow) technical coordination functions for the Internet remains in my view the approach most likely to reflect the needs of the Internet community.

[…]

I am not persuaded that there is any good technical-competency or financial-competency reason not to [proceed with .xxx].

The vision here is of ICANN as a technocratic standard-setter, not a policy-maker. But ICANN, in setting the .xxx process in motion, had already made a policy decision. As I wrote last year, ICANN had decided to create a top-level domain for adult content, when there wasn’t one for (say) religious organizations, or science institutes. ICANN has put itself in the position of choosing which kinds of domains will exist, and for what purposes. Here is Susan again:

ICANN’s current process for selecting new [top-level domains], and the artificial scarcity this process creates, continues to raise procedural concerns that should be avoided in the future. I am not in favor of the “beauty contest” approach taken by ICANN thus far, which relies heavily on relatively subjective and arbitrary criteria, and not enough on the technical merits of the applications. I believe this subjective approach generates conflict and is damaging to the technically-focused, non-governmental, bottom-up vision of ICANN activity. Additionally, both XXX and TEL raise substantial concerns about the merits of continuing to believe that ICANN has the ability to choose who should “sponsor” a particular domain or indeed that “sponsorship” is a meaningful concept in a diverse world. These are strings we are considering, and how they are used at the second level in the future and by whom should not be our concern, provided the entity responsible for running them continues to comply with global consensus policies and is technically competent.

We need to adopt an objective system for the selection of new [top-level domains], through creating minimum technical and financial requirements for registries. Good proposals have been put forward for improving this process, including the selection of a fixed number annually by lottery or auction from among technically-competent bidders.

One wonders what ICANN was thinking when it set off down the .xxx path in the first place. Creating .xxx was pretty clearly a public policy decision – though one might argue about that decision’s likely effects, it was clearly not a neutral standards decision. The result, inevitably, was pressure from governments to reverse course, and a lose-lose choice between losing face by giving in to government pressure, on the one hand, and ignoring governments’ objections and thereby strengthening the forces that would replace ICANN with some kind of government-based policy agency, on the other.

We can only hope that ICANN will learn from its .xxx mistake and think hard about what it is for and how it can pursue its legitimate goals.

A report by Harri Hursti, released today at BlackBoxVoting, describes some very serious security flaws in Diebold voting machines. These are easily the most serious voting machine flaws we have seen to date – so serious that Hursti and BlackBoxVoting decided to redact some of the details in the reports. (We know most or all of the redacted information.) Now that the report has been released, we want to help people understand its implications.

Replicating the report’s findings would require access to a Diebold voting machine, and some time, so we are not in a position to replicate the findings at this time. However, the report is consistent with everything we know about how these voting machines work, and we find it very plausible. Assuming the report is accurate, we want to summarize its lessons for voters and election administrators.

Implications of the Report’s Findings

The attacks described in Hursti’s report would allow anyone who had physical access to a voting machine for a few minutes to install malicious software code on that machine, using simple, widely available tools. The malicious code, once installed, would control all of the functions of the voting machine, including the counting of votes.

Hursti’s findings suggest the possibililty of other attacks, not described in his report, that are even more worrisome.

In addition, compromised machines would be very difficult to detect or to repair. The normal procedure for installing software updates on the machines could not be trusted, because malicious code could cause that procedure to report success, without actually installing any updates. A technician who tried to update the machine’s software would be misled into thinking the update had been installed, when it actually had not.

On election day, malicious software could refuse to function, or it could silently miscount votes.

What can we do now?

Election officials are in a very tough spot with this latest vulnerability. Since exploiting the weakness requires physical access to a machine, physical security is of the utmost importance. All Diebold Accuvote machines should be sequestered and kept under vigilant watch. This measure is not perfect because it is possible that the machines are already compromised, and if it was done by a clever attacker, there may be no way to determine whether or not this is the case. Worse yet, the usual method of patching software problems cannot be trusted in this case.

Where possible, precincts planning on using these machines should consider making paper backup systems available to prepare for the possibility of widespread failures on election day. The nature of this technology is that there is really no remedy from a denial of service attack, except to have a backup system in place. While voter verified paper trails and proper audit can be used to protect against incorrect results from corrupt machines, they cannot prevent an attack that renders the machines non-functional on election day.

Using general purpose computers as voting machines has long been criticized by computer scientists. This latest vulnerability highlights the reasoning behind this position. This attack is possible due to the very nature of the hardware on which the systems are running. Several high profile studies failed to uncover this. With the current technology, there is no way to account for all the ways that a system might be vulnerable, and the discovery of a problem of this magnitude in the midst of primary season is the kind of scenario we have feared all along.

Timeline and Perspective

This is not the first time Diebold has faced serious security issues – though this problem appears to be the worst of them all. Here is a capsule history of Diebold security studies:

None of the previously published studies uncovered this flaw. Did SAIC? It might exist in the unredacted report, but to date, nobody outside of Maryland officials and SAIC has been able to see that report.

We believe that the question of whether DREs based on commodity hardware and operating systems should ever be used in elections needs serious consideration by government and election officials. As computer security experts, we believe that the known dangers and potentially unknown vulnerabilities are too great. We should not put ourselves in a position where, in the middle of primary season, the security of our voting systems comes into credible and legitimate question.

Freedom to Tinker is hosted by Princeton's Center for Information Technology Policy, a research center that studies digital technologies in public life. Here you'll find comment and analysis from the digital frontier, written by the Center's faculty, students, and friends.