October 6, 2022

Archives for June 2006

Does the Great Firewall Violate U.S. Law?

Clayton, Murdoch, and Watson have an interesting new paper describing technical mechanisms that the Great Firewall of China uses to block online access to content the Chinese government doesn’t like.

The Great Firewall works in two parts. One part inspects data packets that cross the border between China and the rest of the world, looking for “bad” content. The other part tries to shut down cross-border connections that have contained “bad” content. I’ll focus here on the shutdown part.

The shutdown part attacks the TCP protocol, which is used (among many other things) to transfer Web pages and email. TCP allows two computers on the Net to establish a virtual “connection” and then send data over that connection. The technical specification for TCP says that either of the two computers can send a so-called Reset packet, which informs the computer on the other end that some unspecified error has occurred so the connection should be shut down immediately.

The Great Firewall tries to sever TCP connections by forging Reset packets. Each endpoint machine is sent a series of Reset packets purporting to come from the other machine (but really coming from the Great Firewall). The endpoints usually respond by shutting down the connection. If they try to connect again, they’ll get more forged Reset packets, and so on.

This trick of forging Reset packets has been used by denial-of-service attackers in the past, and there are well-known defenses against it that have been built into popular networking software. However, these defenses generally don’t work against an attacker who can see legitimate traffic between the target machines, as the Great Firewall can.

What the Great Firewall is doing, really, is launching a targeted denial of service attack on both ends of the connection. If I visit a Chinese website and access certain content, the Great Firewall will send denial of service packets to a machine in China, which probably doesn’t violate Chinese law. But it will also send denial of service packets to my machine, here in the United States. Which would seem to implicate U.S. law.

The relevant U.S. statute is the Computer Fraud and Abuse Act (18 U.S.C. 1030), which makes it an offense to “knowingly cause[] the transmission of a program, information, code, or command, and as a result of such conduct, intentionally cause[] damage without authorization, to a protected computer”, as long as certain other conditions are met (about which more below). Unpacking this, and noting that any computer that can communicate with China will meet the definition of “protected computer”, the only part of this requirement that requires any discussion is “damage”. The statute defines “damage” as “any impairment to the integrity or availability of data, a program, a system, or information”, so that the unavailability to me of the information on the Chinese website I tried to visit would count as damage.

But the offense has another requirement, which is intended to ensure that it is serious enough to merit legal attention. The offense must also cause, or attempt to cause, one of the following types of harm:

(i) loss to 1 or more persons during any 1-year period (and, for purposes of an investigation, prosecution, or other proceeding brought by the United States only, loss resulting from a related course of conduct affecting 1 or more other protected computers) aggregating at least $5,000 in value;

(ii) the modification or impairment, or potential modification or impairment, of the medical examination, diagnosis, treatment, or care of 1 or more individuals;

(iii) physical injury to any person;

(iv) a threat to public health or safety; or

(v) damage affecting a computer system used by or for a government entity in furtherance of the administration of justice, national defense, or national security;

This probably wouldn’t apply to an attack on my computer, but attacks on certain U.S. government entities would trigger part (v), and there is a decent argument that the aggregate effect of such attacks on U.S. persons could add up to more than $5000 in damage, which would trigger part (i). I don’t know whether this argument would succeed. And I’m not a lawyer, so I’m relying on real lawyers to correct me in the comments if I’m missing something here.

But even if the Great Firewall doesn’t violate U.S. law now, the law could be changed so that it did. A law banning the sending of forged packets to the U.S. with intent to deny availability of content lawful in the U.S., would put the Great Firewall on the wrong side of U.S. law. And it would do so without reaching across the border to regulate how the Chinese government interacts with its citizens. If we can’t stop the Chinese government from censoring their own citizens’ access to the Net, maybe we can stop them from launching denial of service attacks against us.

(link via Bruce Schneier)

Long-Tail Innovation

Recently I saw a great little talk by Cory Ondrejka on the long tail of innovation. (He followed up with a blog entry.)

For those not in the know, “long tail” is one of the current buzzphrases of tech punditry. The term was coined by Chris Anderson in a famous Wired article. The idea is that in markets for creative works, niche works account for a surprisingly large fraction of consumer demand. For example, Anderson writes that about one-fourth of Amazon’s book sales come from titles not among the 135,000 most popular. These books may sell in ones and twos, but there are so many of them that collectively they make up a big part of the market.

Traditional businesses generally did poorly at meeting this demand. A bricks-and-mortar book superstore stocks at most 135,000 titles, leaving at least one-fourth of the demand unmet. But online stores like Amazon can offer a much larger catalog, opening up the market to these long tail works.

Second Life, the virtual world run by Cory’s company, Linden Lab, lets users define the behavior of virtual items by writing software code in a special scripting language. Surprisingly many users do this, and the demand for scripted objects looks like a long tail distribution. If this is true for software innovation in general, Cory asked, what are the implications for business and for public policy?

The implications for public policy are interesting. Much of the innovation in the long tail is not motivated mainly by profit – the authors know that their work will not be popular. Policymakers should remember that not all valuable creativity is financially motivated.

But innovation can be deterred by imposing costs on it. The key issue is transaction costs. If you have to pay $200 to somebody before you can innovate, or if you have to involve lawyers, the innovation won’t happen. Or, just as likely, the innovation will happen anyway, and policymakers will wonder why so many people are ignoring the law. That’s what has happened with music remixes; and it could happen again for code.

21st Century Wiretapping: Risk of Abuse

Today I’m returning, probably for the last time, to the public policy questions surrounding today’s wiretapping technology. Thus far in the series (1, 2, 3, 4, 5, 6, 7, 8) I have described how technology enables wiretapping based on automated recognition of certain features of a message (rather than individualized suspicion of a person), I have laid out the argument in favor of allowing such content-triggered wiretaps given a suitable warrant, and I have addressed some arguments against allowing them. These counterarguments, I thnk, show that content-triggered wiretaps be used carefully and with suitable oversight, but they do not justify forgoing such wiretaps entirely.

The best argument against content-triggered wiretaps is the risk of abuse. By “abuse” I mean the use of wiretaps, or information gleaned from wiretaps, illegally or for the wrong reasons. Any wiretapping regime is subject to some kind of abuse – even if we ban all wiretapping by the authorities, they could still wiretap illegally. So the risk of abuse is not a new problem in the high-tech world.

But it is a worse problem than it was before. The reason is that to carry out content-triggered wiretaps, we have to build an infrastructure that makes all communications available to devices managed by the authorities. This infrastructure enables new kinds of abuse, for example the use of content-based triggers to detect political dissent or, given enough storage space, the recording of every communication for later (mis)use.

Such serious abuses are not likely, but given the harm they could do, even a tiny chance that they could occur must be taken seriously. The infrastructure of content-triggered wiretaps is the infrastructure of a police state. We don’t live in a police state, but we should worry about building police state infrastructure. To make matters worse, I don’t see any technological way to limit such a system to justified uses. Our only real protections would be oversight and the threat of legal sanctions against abusers.

To sum up, the problem with content-triggered wiretaps is not that they are bad policy by themselves. The problem is that doing them requires some very dangerous infrastructure.

Given this, I think the burden should be on the advocates of content-triggered wiretaps to demonstrate that they are worth the risk. I won’t be convinced by hypotheticals, even vaguely plausible ones. I won’t be convinced, either, by vague hindsight claims that such wiretaps coulda-woulda-shoulda captured some specific badguy. I’m willing to be convinced, but you’ll have to show me some evidence.

Freeing the Xbox

When Microsoft shipped its Xbox game console, Linux programmers salivated. The Xbox was a pretty nice computer, priced at $149. The Xbox had all the hardware needed to run Linux and its applications. Problem was, Microsoft had tried to lock down the Xbox hardware to prevent unauthorized programs – such as the Linux kernel – from running on it. An article at xbox-linux.org explains how this lockdown plan failed. The technical details are quite interesting, but nontechies can learn from this story too.

Microsoft had two reasons for locking down the hardware. It wanted to stop people from running Xbox games that had been illegally copied. And it wanted to stop people from running other (noninfringing) software such as Linux. The latter goal is the more interesting one. Microsoft did this because it wanted to sell the Xbox hardware at a loss, and make up the difference by charging a premium for games. To do this, it needed to stop unauthorized software – otherwise people might buy the Xbox, install another operating system on it, and never buy an Xbox game.

A group of clever engineers, calling themselves the Xbox Linux Project, set out to discover how Microsoft had tried to lock down the Xbox hardware, and how they could overcome Microsoft’s lockdown and install Linux. We would expect them to succeed – in computer security, physical control of a device almost always can be leveraged to control the device’s behavior – and indeed they did. The bulk of the Xbox-Linux article describes the technical details of how Microsoft’s lockdown worked, how they reverse engineered it, and the tricks they discovered for capturing effective control of the Xbox and installing Linux on it.

Opponents of this kind of tinkering often argue that it is really just a front for copyright infringement – that the tinkerers really just want to run illegally copied games. But the article describes a group of people who just want to run Linux on their Xboxes, and are willing to take steps to stop their work being misappropriated by game copiers. For example, the article says that once they had figured out a trick, which the article calls a “hack”, for installing new software on the Xbox, they tried to use it responsibly:

But the Xbox Linux Project did not blindly release this hack. The first … proof of concept exploit had been finished in January 2003. After that, a lot of energy was invested in finding out a way to free the Xbox for homebrew development and Linux, but not allowing game copies. Microsoft was contacted, but without any success. They just ignored the problem.

Finally in July, the hack was released, with heavy obfuscation, and lockout code for non-Linux use. It was obvious that this would only slow down the “hacking of the hack”, so eventually, people would be able to use this vulnerability for copied games, but since Microsoft showed no interest in finding a solution, there was no other option than full disclosure. The suggestion of the Xbox Linux Project would have been to work together with Microsoft to silently close the security holes and, in return, work on a method to let homebrew and Linux run on the Xbox.

What should public policy have to say about this? Given that the Xbox Linux folks apparently weren’t trying to copy games but simply wanted to run noninfringing software on lawfully purchased hardware, and given that they took steps to hinder the use of their work for infringing purposes, it’s hard to object to their work on copyright grounds. The real action here is in Microsoft’s strategy of selling the Xbox hardware as a loss leader, and the tendency of the Xbox Linux work to frustrate this strategy. Xbox Linux creates value for its users. Should public policy be willing to destroy this value in order to enable Microsoft’s pricing strategy? My instinct is that it should not, though there is a plausible argument on the other side.

What is clear, though, is that this is not really a copyright issue. At bottom, it’s not about the right of Microsoft to be paid for the Xboxes it builds, or about the right of game authors to be paid for the copies of their games that users get. Instead, it’s about whether Microsoft can control how people use its products. In general, the law does not give the maker of a product the right to control its use. Why should the Xbox be any different?

How I Spent My Summer Vacation

Ah, summer, when a man’s thoughts turn to … ski jumping?

On Sunday I had the chance to try ski jumping, at the Swiss national team’s training center at Einsiedeln. My companions and I – or at least the ones foolish enough to try, which of course included me – donned thick neoprene bodysuits, gloves, helmets, and ski boots. We clumped up a short path then strapped on our skis and set off down the jumping track. Having skied only twice before – and that twenty-five years ago – I found this a real adventure, about which more below.

Ski jumping, it turns out, is a popular summer sport, probably more popular in the summer than the winter. I can understand why the spectators would prefer summer weather, but the jumpers’ gear felt better suited for winter than for the 25-degree Centigrade (80-degree Fahrenheit) day we had. The bodysuits are so hot, in fact, that every male jumper, whether expert or rookie, unzipped his suit and peeled it back to the waist when not jumping, exposing a tanned muscular torso, in some cases.

Skiing in summer requires a special surface. On the jumping ramp, the skis ride in two parallel tracks made of a ceramic material speckled with pea-sized bumps sticking upward so that the skis touch only the bumps. The landing area is thatched with countless thin, green plastic sticks about 20 cm (eight inches) long, anchored on one end with the other end pointing downhill. These are hosed down with water to reduce friction. At the bottom of the hill is a stopping area covered with wood chips.

After our own attempts at jumping (be patient; I’ll tell all below), we watched some expert Swiss jumpers practicing, from several vantage points. (YouTube video) From the top where the jumpers start, the ramp seems impossibly steep and stretches far below. It must take considerable courage to look down the ramp and then let oneself go. As the coach told us, once you start, there’s no turning back – you’re going to end up at the bottom of the hill one way or another. You have to be fearless. Unsurprisingly, the jumpers we saw all looked like seventeen-year-old young men.

Though the jumpers go fast, they never get very high above the ground. At the jump point, the ramp is 1.5 meters (five feet) above the ground. Below the jump point, the hillside curves down parabolically, parallel to the flight path that a jumper would follow in the absence of air resistance. So a jumper who doesn’t spring upward is never more than 1.5 meters off the ground. A skilled jumper might reach three meters (ten feet) above the ground. But then again he’ll be going very fast and will fly more than 100 meters (330 feet) down the hill.

The best view is from the takeoff point. You see the jumper start, far above. As he accelerates down the ramp toward you, his body locked in a compact crouch, you hear a ferocious clattering as his skis drum over the bumps in the ceramic tracks. Suddenly the ramp vanishes beneath him as he springs upward. At that moment he flashes past you, and the clattering is replaced all at once with an insistent whooshing, hissing sound as the jumper floats down the hill, his ski tips spread, his body leaning forward like a more aerodynamic Superman. In a second he vanishes behind the downward curve of the hill, and you wait for the faint but firm slapping noise of a safe landing. He returns to view at the base of the hill as he coasts to a stop on a flat grassy area. Nonchalantly, he removes his helmet, gloves, and skis, and half-unzips his body suit, as the next jumper begins.

The jump used by our group of rookies was maybe one-tenth the size of the big jump. Still, it looked distressingly long and steep from the top. On our first trip down the hill, we started just below the jump point, to practice skiing down the landing ramp. The trick is to maintain your balance on the strange green-stick surface as the hill curves sharply downward and then levels out again. Without ski poles, and with your ankles held rigid by the ski boots, you have little leverage to shift your weight forward or backward. Side to side balance is easy, but that’s not the problem.

As I awaited my first run, one of my companions jokingly (in German) asked the onsite medical expert how far it was to the hospital. Not to worry, she answered, the hospital was practically at the bottom of the hill. With that reassurance, I levered my skis out onto the top of the landing ramp and faced down the hill, as the coach held me motionless.

And then I was moving jerkily downhill as my skis fought the initial friction of the green sticks. I recovered my balance and picked up speed as the hill reached what seemed like a 45-degree angle. For a moment I tried to remember whether skiing on snow felt like this, but the thought was thrust aside by a rush of adrenaline and the sense that I was starting to lose my balance. As I reached the bottom of the hill any illusion of balance was gone, and I tumbled to a stop on the wood chips. I lay on my side, my skis angled awkwardly behind me, still attached to my feet. But I was unhurt and decided to try again.

On my second run, things went awry almost immediately. As I started I sensed that I was leaning ever so slightly backward. The downward curve of the hill started to tilt me backward even more. I struggled to get my center of gravity over my feet but it was hopeless. I ended up laying myself down on one hip and sliding comfortably down the last part of the hill. I was none the worse for wear, but my bodysuit was drenched from sliding over recently-watered green sticks.

I felt fine but decided not to try again. Two falls is enough for a guy of my age. I cheered on my companions as some of them managed to make short jumps and reach the bottom of the hill gracefully. Then we headed off for a delightful lunch and a tour of the Einsiedeln monastery and a stunningly restored church crowded, for some reason, with thousands of visiting Sri Lankans.

Having learned firsthand how hard ski jumping is, I was even more amazed to see the skilled jumpers casually launch themselves off the big jump. Next Winter Olympics, ski jumping will be a must-watch.

(My companions are invited to identify themselves and/or tell their own stories, in the comments.)