A shopping cart needed a website to remember its visitor. Around July 1994, Netscape engineer Lou Montulli attended a meeting about a shopping server, according to his 2013 retrospective. He opposed giving every browser a universal identifier that websites could use to recognize it across the web. His alternative became web cookies.
The surprise was where that boundary broke down. A cookie could remain scoped to its own server while that server appeared inside many different websites. The browser could keep returning the same identifier without the visitor deliberately opening that server’s site.
The useful memory and the tracking mechanism grew from the same exchange.
A website needed continuity
HTTP, the Hypertext Transfer Protocol used for web requests and responses, does not by itself connect a visitor’s successive requests into a shopping session. An application needs some way to associate the next request with the selections already made.
In his May 2013 account, Montulli recalled that proposals for adding memory had been circulating before the shopping-server meeting. One proposal was a unique identifier for every browser. He objected because the same identifier could be used across websites.
He recalled the general cookie concept forming during the following week. A website could send a session identifier to the browser, which would return it to that server. He then expanded the idea into a more general payload, useful for more than shopping carts. He credited feedback from fellow engineers, particularly John Giannandrea.
That is Montulli’s retrospective account of the timing and intention. It supports an approximate origin story, rather than an exact invention date or a claim that one person designed every detail alone.
The browser carries a small piece of state
The basic exchange is simple. A server includes a Set-Cookie header in its response. The browser stores the cookie and, on later requests that meet its scope and policy rules, returns its value in a Cookie header.
The value need not contain the whole shopping cart. It can be a session identifier that lets the server look up information stored on its side. The browser carries the key; the application associates that key with the continuing session.
The distinction matters. A cookie is data passed between browser and server. Its usefulness depends on what the application does with that data, whether maintaining a cart, remembering a preference or recognizing a returning browser.
Cookies were also not the only way to maintain state. In his 2001 history, David M. Kristol, a co-editor of the cookie standards, described alternatives such as state embedded in web addresses or hidden form fields. Those approaches had drawbacks involving navigation, modification and caching. Cookies made stateful applications easier to build.
The other server inside the page
Montulli identified embedded content as the interaction he missed during the original design. A page can load images and other resources from servers beyond the site the visitor chose to open. Requests to those servers are still requests, and they can participate in cookie exchanges.
Consider the mechanism described in the later cookie specification, published as Request for Comments (RFC) 6265. A visitor opens one site containing a resource from a third party, then another site containing content from that same third party. Where browser policy permits the exchange, that third-party server can receive its own cookie on both visits and recognize the browser across the two sites.
It does not need to read either publisher’s cookies. Its own identifier supplies the continuity. Restricting a cookie to a server therefore does not restrict that server to appearing within one publisher’s pages.
Montulli recalled advertising companies using this capability and the subsequent debate over disabling third-party cookies. He also described legitimate uses for cookies on embedded resources. The technical mechanism did not distinguish a useful embedded service from an unwanted tracking relationship.
A privacy rule was not a deployed default
The standards process tried to address that problem. Kristol and Montulli’s RFC 2109 appeared in February 1997, after Netscape’s original implementation. It specified restrictions on cookie sessions in automatically triggered transactions, such as requests for embedded content, when the domains did not meet its rules. Options overriding those restrictions were to default to off.
Those requirements describe the specification. They do not establish that browsers implemented its privacy default. Kristol’s 2001 participant history described browser vendors leaving third-party cookies enabled despite the standard’s restrictions.
Montulli’s later recollection supplied his own reasoning for retaining them. He believed visible, controllable cookies and public scrutiny were preferable to replacement tracking mechanisms that might be harder to observe. That was his judgment about a difficult choice, not proof that every alternative would have been worse.
In April 2011, Adam Barth’s RFC 6265 documented cookie behavior actually used on the Internet. It explained third-party recognition and allowed browsers latitude in choosing their policies. Its account should not be projected backward into the 1994 implementation, or treated as a description of every browser today.
The shopping cart asked how a site could remember a visitor. Embedded resources added another question: which servers does the browser contact while showing that site? The same cookie can return to the same server while the person looking at the screen moves from one website to another.
Related stories
Sources
- Lou Montulli: The reasoning behind Web Cookies, May 2013
- David M. Kristol and Lou Montulli: RFC 2109, HTTP State Management Mechanism, February 1997
- David M. Kristol: HTTP Cookies: Standards, Privacy, and Politics, 2001
- Adam Barth: RFC 6265, HTTP State Management Mechanism, April 2011
- Featured image: David Monniaux (corrected by Mysid); Wikimedia Commons; CC BY-SA 3.0 (adapted from the original)
SIGNAL TITANS
Leave a Reply