Web cookies elevated to a US government privacy firestorm
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.
- 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.
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."
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.