80 Cookie separation in modern browsers

A while back I wrote a short piece which told about using JavaScript-set cookies to communicate between browser windows. While the idea in itself is sound, there are a number of untold details that make real-life implementation have its quirks. This is a much needed clarification of those details.

1. Introduction

When setting cookies (either server-side or client-side via JavaScript) with the purpose of communicating between browser windows, you need to ask yourself how cookies are stored and separated by the browser. Will the same cookie be visible in different browsers? Different instances of a browser? In different windows or tabs of the same browser?

To answer these questions we need to examine how each browser stores and handles cookies in these respects. To this end, I’ve examined a number of the most widely used browsers, as well as the relevant reference specifications.

2. Standard specifications

Let us see first of all if the standards have anything to say about this issue. Naturally, they do, so a more appropriate question would be “to what extent do they take the specs”. What explicitly dictates how cookies are handled and their visibility?

The most important specs in this respect are:

• RFC 2616, which describes version 1.1 of the HyperText Transfer Protocol (HTTP);
• the original cookie specification created by Netscape;
• RFC 2109 which defines the “proper” cookie standard (a.k.a. the HTTP State Management Mechanism);
• RFC 2965 (the second version of the cookie spec).

3. What the specifications say

3.1. What’s a browser?

The HTTP spec uses a generic concept of “browser” by calling it “user agent” and defines it using the following concepts:

Client: a program that establishes connections for the purpose of sending requests.

User agent: the client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.

3.2. Cookie validity and storage

By reading on through the cookie spec, we see the usual regulations limiting cookie visibility by domain, port, path, secure connection, age and the explicit “Discard” attribute. (If you’re not already familiar with the cookie specs please read them before you go on, it makes for very instructive and useful reading.)

The mentions of specific behaviour from the part of the browser in the specs are generally scarce and they contain mostly common-sense recommendations like this one:

NOTE: User agents should probably be cautious about using files to store cookies long-term. If a user runs more than one instance of the user agent, the cookies could be commingled or otherwise corrupted.

3.3. Session cookies

A particularly interesting aspect of the cookie spec is the so called “session” cookies. These are cookies that were created with the age-specification attribute missing (expires in the Netscape docs, Max-Age in the RFC’s). Both sets of docs are rather vague on the topic of discarding such cookies:

(Netscape) expires is an optional attribute. If not specified, the cookie will expire when the user’s session ends.

(RFC) Max-Age: The default behavior is to discard the cookie when the user agent exits.

3.4. Additional quirks

The PHP manual page for the setcookie() function contains many additional comments from visitors which describe interesting idiosyncrasies in various browsers. A very good read.

4. Cookie separation

As you could see, the wording in the documentation is vague enough to allow browser makers to take their own decision in regard to cookie separation.

This can be a good thing, because a specification that endulges in too-precise regulations becomes too rigid for its own good. On the other hand, this forces us to examine the various browsers and see how their makers went about the finer points.

4.1. Opera 9.0

Opera can install one instance for all the users on a machine, or different instances for each user. This translates to user preferences as well, and, in turn, to cookie storage. It can even run with multiple separate profiles for the same user at once.

For my cookie communication exercise, this means that each separate profile has its own session cookies. The cookies in an Opera browser instance running on one profile can’t be seen by another. However, different windows or tabs of the same browser instance all share the profile’s cookies. Pretty much what you’d expect.

4.2. Firefox 2.0

Firefox is very similar to Opera. Each user has his own profile by default, and can create additional profiles. You can run Firefox on different profiles at the same time thanks to the Profile Manager.

As expected, each separate user+profile combination will run a different Firefox instance. You won’t be able to access cookies from a different user/profile, but windows and tabs belonging to the same instance will share cookies just fine.

4.3. Internet Explorer 6.0

Finally, Explorer is the one that introduces an interesting quirk. It too has separate settings per machine users, although it cannot make use of multiple profiles for the same user.

The interesting thing is the way it handles session cookies. Normally, long term a.k.a. non-session cookies are stored on disk in the user preferences. However, Explorer has a setting called “browse in new process” which, if enabled, forces a new session with each new window. That’s right, this means that every time you open a new Explorer window it opens a separate process, even though the windows belong to the same user! And, in turn, these processes will NOT share their session cookies.

Note: By “new window” I mean windows started from shortcuts, from Start Menu entries or by calling iexplore.exe directly somehow (from a file manager, for example). Windows started via Control+N or File/New window run in the same process and share session cookies. Also, please note that it’s a lot more likely for users to click their taskbar shortcut when they need a new window than it is to use the File menu or the Control+N shortcut.

Furthermore, ever since version 5.0 the setting cannot be changed manually, by the user. It is automatically determined by the browser based on how much RAM the machine has. Anything with at least 32 MB of RAM gets the “one window, one process” behaviour, which nowadays means almost all machines.

Therefore, this pretty much means that you cannot use inter-window communication with Explorer 6.

I’m at a bit of a loss as to why Explorer would choose to isolate session cookies in this manner. It makes sense between instances belonging to different users, or between voluntarily separated storages like those in a profile, but not for what is essentially the same user using different windows.

4.4. Other browsers

I’d appreciate to hear back from those who can test cookie separation in other browsers. The test is simple. Either use my inter-window communication example files, or log in to a site that you know only uses session cookies with two different windows belonging to the same user, same user but different profiles, and different users, respectively. Then leave a comment with your findings.

Of particular interest are the following browsers: Konqueror, Safari and Internet Explorer 7, but any browser is interesting. Thanks in advance.