[THIS IS THE ONLY PLACE WHERE THE IDEA OF TRUSTED COMPUTING ARCHITECTURE IS DISCUSSED.  IT SEEMS TO ME THAT THE IDEA NEEDS MORE DISCUSSION.  SHOULD IT REMAIN IN THIS FOOTNOTE OR CAN WE FIND A WAY TO MOVE THE IDEA INTO THE BODY OF THE TEXT?  THIS IS THE PLACE TO TRY SOME SUBSTANTIVE REWRITES INCORPORATING IN TRUSTED COMPUTING.  HOPEFULLY WE'LL LIKE WHAT WE PRODUCE AND CAN MOVE IT INTO THE MAIN TEXT.]

Where This Leads

My argument so far has taken a simple path. In answer to those who say that the Net cannot be regulated, I’ve argued that whether it can be regulated depends on its architecture. Some architectures would be regulable, others would not. I have then argued that government could take a role in deciding whether an architecture would be regulable or not. The government could take steps to transform an architecture from unregulable to regulable.

The final step in this progression of regulability is a constraint that is only now becoming significant. Government’s power to regulate code, to make behavior within the code regulable, depends in part on the character of the code. Open code is less regulable than closed code; to the extent that code becomes open, government’s power is reduced.

This is not, obviously, an absolute claim. I am discussing relative, not absolute, regulability. Even with open code, if the government threatens punishments that are severe enough, it will induce a certain compliance. And even with open code, the techniques of identity, tied to code that has been certified as compliant, will still give government plenty of power. Thus, much of the argument from part 1 survives this point about open code—if the world becomes certificate-rich, regulability still increases.*

But when designing an architecture for cyberspace, the margins matter. The values of a given space are not only the values of speech, autonomy, access, or privacy. They may also be values of limited control. As John Perry Barlow puts it, they are the values of a certain bug being programmed into the architecture of the Net—a bug that inhibits the power of government to control the Net perfectly, even if it does not disable that power entirely.

For some, the objective is to build code that disables any possible governmental control. That is not my objective. I certainly believe that government must be constrained, and I endorse the constraints that open code imposes, but it is not my objective to disable government generally. As I’ve argued already, and as the next part makes plain, some values can be achieved only if government intervenes. Government has a role, even if not as substantial a role as it would wish. We need to understand this role, as well as how our values might be advanced in the context of the Web.

One constraint seems clear in this account. As I argue more extensively later in the book, even if open code does not disable government’s power to regulate completely, it certainly changes that power. On the margin, open code reduces the reward from burying regulation in the hidden spaces of code. It functions as a kind of Freedom of Information Act for network regulation. As with ordinary law, open code requires that lawmaking be public, and thus that lawmaking be transparent. In a sense that George Soros ought to understand, open code is a foundation to an open society.

Even this is an important—some might say an essential—check on the power of government. But whether or not one is for transparency generally, my aim so far is just to map out the links. Regulability is conditional on the character of the code, and open code changes that character. It is a limit on government’s power to regulate—not necessarily defeating the power to regulate, but changing it.¹

* Another constraint would arise if more code were burned into hardware rather than existing as software.  Then, even if the code were open, it would not be modifiable.  I am grateful to Hal Abelson for this point.