I’ve been working on browsers professionally for 12 of the last 15 years, and in related areas for 20 of the last 20, and over the years I’ve discovered enough surprises in browser behavior that they’re no longer very surprising.
Back in April, I wrote up a quick post explaining how easy it is to delete a single site’s cookies in the new Edge browser. That post was written in response to a compatibility problem with some internal web application that could somehow get in a state where a single “bad” cookie would cause the application to fail to load. The team that owns the application later looked into things further and discovered that the problem was that the application was misbehaving upon receipt of a very old (over a month) session cookie.
Recall that there are two types of cookies:
- Persistent cookies, sent to the server until the expiration date supplied when they were set, or until the user clears their cookies, whichever happens first, and
- Session cookies, sent to the server until the end of the user’s browser session.
Now, in most cases, developers expect that Persistent cookies will live longer than Session cookies– most users restart their browsers (or computers) every few days, and many modern browsers require restart (to install updates) every few weeks. In contrast, many Persistent cookies are configured to last for a year or more.
So how did this zombie cookie live so long?
Until last week, I didn’t realize that these browser settings in Chrome/Edge76:
…both behave very differently than the old setting from Internet Explorer:
…and the old setting from Edge 18 (Spartan) and earlier:
The Internet Explorer and Edge 18 settings simply open tabs to the URLs of the tabs that were open when you last closed your browser.
In contrast, the Firefox/Chrome/Edge76+ settings restore the browser session itself… which means that closing the browser does not delete your session cookies and doesn’t empty the HTML5 sessionStorage (Update: Chromium broke sessionStorage recovery in Chrome 77, twenty days after this post).
In many ways, preserving session state makes sense– without it, users are likely to find that their restored tabs are immediately navigated to a login page when the browser is restarted. However, a consequence of this session restoration behavior is that browsers with this option configured might keep session cookies alive for a very long time:
If you’d like to play with your browser’s behavior, try setting the option and then play with this simple test page. (The background of the page is generated by the session cookie, and the
localStorage values are shown in the text of the page. Adjust the dropdown to change the color.)
Note: If the Chromium-based browser is restarted by visiting
chrome://restart or if it restarts to install an update, it behaves as if “Continue where I left off” is set, even if it isn’t.
Web Developers: Given this session resumption behavior, it’s more important than ever to ensure that your site behaves reasonably upon receipt of an outdated session cookie (e.g. redirect the user to the login page instead of showing an error).
Users: If you enable the session resumption option, keep in mind that you can’t simply close your browser to “log out” of a site– you need to explicitly use the site’s logout option (I’ve written about this before).
PS: If you’re really concerned about privacy, you can set the Keep local data only until you quit your browser option:
This will clear all Session and Persistent storage areas every time you exit your browser, regardless of whether you’ve set the “On Startup: Continue where you left off”.
PS2: What else is bound to “session lifetime”? Client Hint opt-in, for one thing.
One thought on “Surprise: Undead Session Cookies”
I’d love a user setting that let me change between 3 options of (when tabs are open): Restore Session, Restore Pages, Restore Nothing.
Most of the time I just want “Restore Pages” as I kinda expect session stuff to last until I “close a tab or the browser” (which is the speced text for “sessionStorage” right?)
Luckily the login systems and web apps I make uses server side session tracking so old session id’s won’t work etc. But it’s certainly a concern I’ll have to keep in mind though.
Looking at the specs https://www.ietf.org/rfc/rfc2109.txt
7.1 User Agent Control
When the user agent terminates execution, it should let the user
discard all state information. Alternatively, the user agent may ask
the user whether state information should be retained; the default
should be “no”. If the user chooses to retain state information, it
would be restored the next time the user agent runs.”
The last time this text was in the specs is https://www.rfc-editor.org/rfc/rfc2965.txt (now under 6.1 section)
In the current spec https://www.rfc-editor.org/rfc/rfc6265.txt this text no longer exists.
I can understand that with multiple tabs it may be annoying to ask for each site/tab, but presenting a list where sites(/pages) can be removed from could work.
In any case, stuff like this should be user configurable (IMO), either through a normal privacy settings page or at the least via a “flags” page for more advanced users.
I wonder why the text was removed from the later specs!