Daniel Witte

Back in 1994, at a fledgling company called Netscape Communications, a specification was proposed that would fundamentally change the Web: the ability for a web server and a browser to maintain state. Web pages being viewed in a browser could send login information to websites using the standard form controls that we know today, but there was no way for that login state to be associated with an individual browser. Things like shopping carts, online forums, and online banking weren’t possible. The cookie specification changed that. By allowing the web server to store small pieces of information in the browser, this information could then be sent back with every http request, and stateful transactions were born.

Of course, the web back then was far different from the web today, and the cookie standard really hasn’t changed much. The simple protocol that was implemented more than a decade ago was just that – simple, minimal, enough to get the job done. But along came https, and JavaScript, and advertisers that want to track you, and host sites with many unrelated subdomains like GeoCities and Blogspot — and with them came cross-site scripting attacks and severe privacy and security issues. Underneath a login session at your favorite online bank is just a handful of cookies, and if that bank makes a mistake or two in their implementation, those cookies could be sent in the clear — you can guess what happens next.

There have been attempts to improve the protocol. RFC2109 was the first, and somewhat reflects the situation today. But this spec didn’t succeed a vacuum – cookies were already in use, and browsers didn’t wholly adopt the new standard for fear of breaking existing, working sites. The spec became more of an ideology, and servers were instead designed around how browsers actually behaved. Realizing that changing the standard — or rather, having browsers and servers implement the standard — was a losing battle, RFC2965 was produced. This introduced new headers, Set-Cookie2 and Cookie2, that had different semantics and solved some (then new) problems – it added more trust to cookies, so that servers could have more confidence that what they received from a browser actually originated from them and not an attacker. This is achieved by sending back metadata with each cookie, detailing how the cookie was set. Unfortunately, interest in the new standard wasn’t great, and most browsers today don’t implement it. (Among the big five, Opera is the sole exception.) But the problem of cookie trust and integrity remains.

Thus was formed the http-state working group in 2009, under the auspices of the IETF. The charter of the group is, firstly, to produce a specification that accurately reflects how cookies are implemented today. This is necessarily a big task, because such a specification must account for the subtle differences between browser implementations. This will result in two separate documents — one describing how clients should behave in order to match other clients (concensus behavior), and one describing how servers should behave in order to interoperate with those clients (conservative behavior). The former will be much more detailed — due to the presence of numerous edge cases — than the latter. Work towards producing a draft is pretty far along. As an added benefit, the extensive testing of the big five browsers required to produce this spec has resulted in several fixes to Firefox, in order to bring it in line with the consensus behavior. Adam Barth deserves a big callout for the awesome effort and energy he’s put into this project — without him this spec wouldn’t exist.

The http-state working group will be congregating at the 77th IETF meeting in Anaheim, California, March 21-26. Representatives from at least some of the major browser vendors — and of course other server and client implementors — will be there. I’ll be going along in my capacity as the Firefox cookie module owner. Which brings me to the second (perhaps informal) purpose of the group, or at least of many of its members — to bounce around ideas for a modern cookie standard; something that does not inherit the integrity problems and lack of scaling that current implementations do. While there are new web standards that provide state management mechanisms (such as DOM storage), nothing beats the simplicity, ubiquity, and public awareness of cookies. Thus it is a noble goal to make things right, and something that http-state holds promise to do.