Code on the Net

I’ve spent lots of time talking about the code of cyberspace. For those who know something about code in cyberspace (and who are still with me here), what I’ve said will have been quite frustrating. As they know (and though they doubt it, as I know), there are many different kinds or layers of code on the Internet. When we talk about regulating code, it matters deeply which code we are describing. [THIS PARAGRAPH IS OUT OF DATE GIVEN THAT CODE ISN'T AS CONTROVERSIAL AS WHEN IT CAME OUT. A NEW INTRODUCTION IS NECESSARY]

The Internet is defined by a set of protocols together referred to as TCP/IP. That label refers to a large number of protocols that feed different “layers” of the network. The standard model for describing layers of a network is the open systems interconnect (OSI) reference model. It describes seven network layers, each representing a “function performed when data is transferred between cooperating applications across” the network. But the TCP/IP suite is not as well articulated. According to Craig Hunt, “most descriptions of TCP/IP define three to five functional levels in the protocol architecture,” though it is simplest to describe four functional layers in a TCP/IP architecture.³ From the bottom of the stack up, we can call these the data link, network, transport, and application layers.⁴

Very few protocols operate at the lowest layer—the data link layer—since that handles local network interactions exclusively. More protocols exist at the next layer up—the network layer, where the IP protocol is dominant. It routes data between hosts and across network links, determining which path the data should take. At the next layer up—the transport layer—two different protocols dominate, TCP and UDP. These negotiate the flow of data between two network hosts. (The difference between the two is reliability—UDP offers no reliability guarantee.)

These three layers are the essential plumbing of the Internet, hidden in the Net’s walls. (The faucets work at the next layer; be patient.)

The protocols together function as a kind of odd UPC. Data are passed from the application to the transport layer. There the data are placed in a (virtual) box and a (virtual) label is slapped on. That label ties the contents of the box to particular processes. (This is the work of the TCP or UDP protocols.) That box is then passed to the network layer, where the IP protocol puts the package into another package, with its own label. This label includes the origination and destination addresses. That box then can be further wrapped at the data link layer, depending on the specifics of the local network (whether, for example, it is an Ethernet network).

The whole process is a bizarre packaging game: a new box is added at each layer, and a label on each box describes the process at that layer. At the other end, the packaging process is reversed: like a Russian doll, each package is opened at the proper layer, until at the end the machine recovers the initial application data.

On top of these three layers is the application layer of the Internet. Here protocols “proliferate.”¹ These include the most familiar network application protocols, such as FTP (file transfer protocol, a protocol for transferring files), SMTP (simple mail transport protocol, a protocol for transferring mail), and HTTP (hyper text transfer protocol, a protocol to publish and read hypertext documents across the Web). These are rules for how a client (your computer) will interact with a server (where the data are), and the other way around.

These four layers of protocols, then, constitute “the Internet.” Building on simple blocks, the system makes possible an extraordinary range of interaction. It is perhaps not quite as amazing as nature—think of DNA—but it is built on the same principle: keep the elements simple, and the compounds will astound.²

When I speak about regulating the code, I do not mean that we regulate the TCP/IP protocols. (Though in principle, of course, they could be regulated, and others have suggested that they should be regulated.)³ Instead, I’ve had in mind a different part of the code of cyberspace—the part that TCP/IP connects. In the terms of network theory, I’ve had the “ends” in mind.⁴ Not the code at its most basic level of Internet exchange, but the applications (both in hardware and software) that use or implement those protocols.

A different metaphor may help you see the difference. Tim Wu likens the Internet to the electric grid: TCP/IP is the architecture for that grid; programs then “plug into” TCP/IP, or into the Internet. At the top layer, the protocol defines what the plug looks like; lower down, it governs how power flows.⁵

This is a helpful picture. Just as a very large number of appliances can be plugged into the electric grid, so too can a very large number of programs use the Internet. Before doing so, this wide variety need only agree on a simple protocol of data exchange.

My focus is on the code that plugs into the Internet. I will call that code the “application space” of the Internet. This includes all the code that implements TCP/IP protocols at the application layer—browsers, operating systems, encryption modules, Java, e-mail systems, P2P, whatever elements you want. This application space code would be the target of regulation in the story of regulability that I have told so far. The question in this chapter is: What is the character of that code that makes it susceptible to regulation?

Footnotes

¹ Loshin, TCP/IP: Clearly Explained, 18. Edit Delete

² As Hafner and Lyon explain: “The general view was that any protocol was a potential building block, and so the best approach was to define simple protocols, each limited in scope, with the expectation that any of them might someday be joined or modified in various unanticipated ways. The protocol design philosophy adopted by the NWG [network working group] broke ground for what came to be widely accepted as the ‘layered’ approach to protocols”; Where Wizards Stay Up Late, 147. Edit Delete

³ The fights over encryption at the link level, for example, are fights over the TCP/IP protocols. Some within the network industry have proposed that encryption be done at the gateways, with a method for dumping plain text at the gateways if there were proper legal authority—a kind of “private doorbell” for resolving the encryption controversy; see Elizabeth Kaufman and Roszel Thomsen II, “The Export of Certain Networking Encryption Products Under ELAs,” available at www.cisco.com/warp/public/ 779/govtaffs/archive/CiscoClearZone.doc .This has been opposed by the Internet Architectural Board (IAB) as inconsistent with the “end-to-end” architecture of the Internet; see IAB statement on “private doorbell” encryption, available at http://web.archive.org/web/19991109020406/http://www.ietf.org/mail-archive/ietf-announce/msg01937.html. Edit Delete

⁴ See John C. Morley and Stan S. Gelber, The Emerging Digital Future: An Overview of Broadband and Multimedia Networks (Danvers, Mass.: Boyd & Fraser Publishing Co., 1996); Jerome H. Saltzer et al., “End-to-End Arguments in System Design,” in Integrated Broadband Networks, edited by Amit Bhargava (New York: Elsevier Science Publishing Co., 1991), 30. Edit Delete

⁵ See Timothy Wu, “Internet v Application: An Introduction to Application-Centered Internet Analysis,” Virginia Law Review 86 (1999). Edit Delete