from the network-neutrality dept
In the first post in my network neutrality series, I discussed the fear that without network neutrality rules, major telecom companies would engage in censorship of their customers' communications. I pointed out that if the government of Iran has trouble restricting the flow of information to its citizens, it's hard to imagine a company like AT&T or Verizon being able to do so. Today I'm going to expand on this point by looking at the more general assumption that the owner of a communications network has fine-grained control over the kind of traffic that gets transmitted across the wire. It's common for people on both sides of the debate to talk about network owners blocking, filtering, promoting, speeding up, or slowing down various content and applications. It's almost always taken for granted that if you own a pipe, it's straightforward to decide how that pipe will be used. I don't think that's as obvious as it might seem at first glance.
This is illustrated by a story that came out a couple of weeks ago: AOL is opening its IM network to third-party developers. This seems like a smart move, although as Matt Asay argues, they could have gone a lot further than they actually did. What's really interesting about this development is the back story. In reality, AOL's instant messaging network has been a de facto open network for years, despite the best efforts of AOL. During the first half of this decade, AOL became embroiled in "an elaborate game of cat and mouse" with third-party clients like Trillian. AOL would make changes to its own software designed to shut third-party clients out of their networks. The other clients would respond within hours with patches that restored compatibility. This went on for months, and Microsoft and Yahoo! tried similar tactics. Ultimately, all three companies gave up. The constant upgrades were annoying their own users and it became increasingly clear that the third party developers weren't going to back down.
This isn't technically a network neutrality question because AOL's IM "network" isn't a network in the traditional computer science sense. But I think the story has some important lessons for the network neutrality debate. One is that we should be skeptical of claims that ownership of physical infrastructure gives companies unlimited control over how that infrastructure will be used by users. One might have thought that AOL's ownership of its IM servers would give it the ability to lock out third-party clients it didn't approve of, but that's not how things worked out. Third party clients found it relatively easy to evade AOL's efforts to lock them out. And AOL was constrained in its options because it needed to preserve a reasonable level of service for its official client.
Second, the story suggests that not only can users evade blocks by network owners, but in many cases, the evasion techniques can be downright user-friendly. I was using a Mac OS X client called Fire at the time, and all I had to do to restore connectivity after AOL made one of these changes was download an updater and install it. I assume the Trillian experience was similar. While there are certainly some people who don't know how to download and install an update, there are millions of people who do, and these people served as the customer base for the third-party client.
Finally, it's worth noting how the third-party clients were able to respond so quickly when one of the IM networks tried to shut them out. Over time, the various third-party clients began sharing the libraries they were using to achieve interoperability with various IM networks. That meant that when AOL made a change to its protocol, just one person needed to make the necessary changes to the shared library, which was then quickly integrated into all the other clients. This allow them to respond much more quickly than if each client had to develop its own workarounds, and it was especially helpful for niche clients that might otherwise have lacked the manpower to keep up with AOL's changes.
Of course, it would be over-stating things to say that this proves that a network provider could never block applications or content it didn't approve of. But I think it does suggest that network providers would find content or application blocking more challenging than is commonly supposed. A broadband provider that began filtering its customers' traffic would get locked into a cat-and-mouse game with its customers, with the customers developing new ways to evade the filters and the network owners beefing up its filtering software. This would, at a minimum, be a headache for the firm's engineers and a source of bad publicity. At worst, it might begin to cut into the network owner's bottom line, because efforts to block certain applications would degrade the quality of Internet access in general and spark cancellations.
Indeed, we're already starting to see hints of the kinds of difficulties ISPs will face with Comcast's war against BitTorrent. One of the major results of Comcast's policy has been to accelerate the adoption of clients with "header encryption" functionality. As a result, the techniques Comcast is currently using to control BitTorrent use are likely to get less and less effective over time, and Comcast will have to spend still more money developing more sophisticated filtering software. It's unlikely that either side will "win" this cat-and-mouse game. But at some point, Comcast may decide it's more trouble than it's worth.
Other posts in this series:
Filed Under: control, net neutrality, networks
Companies: aol, comcast, meebo
