The principal architecture of HTTP, the transfer protocol for the Web, is by definition sessionless. That means that once a browser has completed loading a page from a server, the communication between the server and the browser is broken. So any illusion of a connection between the browser's user and the server is produced by the server creating a record of the session that inevitably terminates, and referring to that record later. The only decision a Web publisher has to make is where to store those records -- on a local database, or using remote cookies stored on the client.

For most publishers, that decision takes less than two seconds to make -- cookies are practically ubiquitous among Web sites. But for the United States Government, storing any record about a person using a government service is a privacy concern; and the decision of storing and retrieving government-generated data on a citizen's private computer raises the irresistible specter of conspiracy.

Since June 2000, US government policy has been not to store cookies on private citizens' computers, for reasons which at the time were explained as obvious. "Because of the unique laws and traditions about government access to citizens' personal information, the presumption should be that 'cookies' will not be used at Federal Web sites," wrote then-director of the Office of Management and Budget, Jacob Lew, in a policy memo. "Under this new Federal policy, 'cookies' should not be used at Federal Web sites, or by contractors when operating Web sites on behalf of agencies," unless clear and compelling reasons for doing so are presented in writing, Lew continued.

The problem with that policy is that it has a dramatic effect on the Web architecture choices that the government can make. Persistent variables used by JavaScript are often stored as cookies; when asked if there's any other way to do it, professional developers tend to say no. While there are other ways to store session state, any of the problems the government might encounter in attempting to enable one of them, tend to be enormous:

• They're limited to newer browsers, which is the case with an API called XMLHttpRequest. This sets up an interface that can be addressed using JavaScript, and which can store data in memory in such a way that cookies are not required. Though recent versions of Internet Explorer implement the version of XMLHttpRequest currently specified in the W3C's working draft, IE6 is limited to an implementation that uses Microsoft's ActiveX -- a technology whose security implications are far more grave than any cookie. And as Betanews has been reporting today, the government may not be able to abandon IE6 until Microsoft does so, which won't happen for at least another five years. Besides, the W3C has yet to formally sign off on this API as an official standard, for reasons some blame on the public sector's reticence towards upgrading.
• They have prominent brand names, as is the case with Microsoft's ASP.NET. It maintains a sophisticated HTTPContext object where variables representing the session state are maintained within member objects. Unfortunately, Microsoft's initial attempts at cookie-less session state resulted in a severe security hole. Another alternative is implemented in Java (which is part of Sun, which is now part of Oracle), which in the past utilized an IIOP protocol whose roots lie all the way back to CORBA. But that protocol utilized a port that firewalls today tend to block, since that channel is also used by Java to implement remote procedure calls, and for that reason was heavily exploited.
• They're protected by private patents. Enough said there.
• They remain experimental in nature, even years after the discovery of the methodology. What's more, they obviously require throwing away the old rulebook on Web development and starting from scratch.

As daunting as any one of these prospects may appear from the perspective of an OMB manager writing suggestions and mandates for government Web architects, the option of simply going forward with traditional cookies while promising not to misuse or abuse them, is now meeting with opposition that could look as scary, if not more so: The American Civil Liberties Union is now formally objecting to any move that the Obama administration's Web architects may take to allow the use of cookies, calling it a "sea change in government privacy policy."

ACLU Washington-based attorney Michael Macleod-Ball stated yesterday, "Without explaining this reversal of policy, the OMB is seeking to allow the mass collection of personal information of every user of a federal government Web site. Until the OMB answers the multitude of questions surrounding this policy shift, we will continue to raise our strenuous objections." And later in the same statement, ACLU counsel Christopher Calabrese uttered the "S" word in his objection: "No American should have to sacrifice privacy or risk surveillance in order to access free government information. No policy change should be adopted without wide ranging debate including information on the restrictions and uses of cookies as well as impact on privacy."

By design, cookies are extremely small units of data, and browsers may only use a few of them. While conceivably some agency may store information about how a user browsed through that agency's Web site, the use of cookies as surveillance tools is about as rare as the use of databases as clairvoyance tools.

The other alternative the government has open to it is to stay right where it is with regard to Web development policy. But that will mean maintaining an older and less adaptable methodology that's taught by fewer instructors, therefore making it more costly. The administration did seek the public's assistance in making a final decision; it'll be interesting to see if the public came up with a viable solution to this one.