Understanding Session Lifetime

Back in May of last year, I discussed changes we made in Internet Explorer 8 to make the browser’s session handling behavior more predictable. Specifically, we introduced a “New Session” item on the File menu—this menu item explicitly creates a new browser session which doesn’t share session information with the existing session. From the command line, you can open a new session using the -nomerge command line option.

We also changed other codepaths to ensure that no matter what other method you use to open a new IE window or tab, e.g.:

    1. File > New Window

    2. Hit CTRL+K

    3. Hit CTRL+T

    4. Call window.open() from JavaScript

    5. Click on a link in your mail program

    6. Click a QuickLaunch shortcut

    7. Double-click on the “blue e” on your desktop

...the new window would run in the same browsing session as an existing window[1].

As I outlined in that post last year, pre-IE8 prior behavior was somewhat confusing to users who didn’t realize that they’d get a different number of active sessions depending on how they launched Internet Explorer. Beyond improving consistency, the new behavior also improves performance, and thanks to LCIE and crash recovery features, it doesn’t negatively impact reliability.

One downside to this change (or any change that’s visible to the user) is that there is a period of adjustment because some scenarios work slightly differently. When things change, the misunderstandings that users hold in their mental model of how the browser actually works are often spotlighted.

For this particular change, the most common complaint I’ve heard is “Something changed—IE8 won’t let me log out of a website anymore!?!”

When I ask for details, the scenario is always something like:

  1. Open three browser windows by clicking on the desktop icon a few times.

  2. Open a new IE browser window from the desktop.

  3. Navigate that new browser window to GMail or another mail website.

  4. Use the web mail window.

  5. Close the web mail window using the red “X” in the title bar.

  6. The user expects to be logged out.

  7. Open a new browser window or tab.

  8. Navigate that new window to the web mail site.

  9. Observe that you remain logged into the web mail site.

Now, users will try this exact set of steps on IE7 and at step #9 they will see that they are not logged in. In contrast, when they perform this set of steps in IE8, they will see that they are logged into the web mail site automatically.

What happened?

In IE7, Step #1 creates [Session1, Session2, Session3]. Step #2 creates [Session4].

In IE8, Step #1 creates [Session1], with three windows sharing just one session. Step #2 creates a fourth window in [Session1].

So, when you get to Step #5 in IE7, the window is closed and [Session4] is destroyed, so the user is logged out. In IE8, Step #5 merely destroys one window in [Session1], leaving three more windows and [Session1] still alive. Thereafter, when the user opens a new window in Step #7, that new window is opened/merged into the existing [Session1].

What very few people realize is that both IE7 and IE8 work in the same way if a small change is made in the steps:

  1. Open three browser windows by clicking on the desktop icon once and clicking File > New Window twice.

  2. Open a new IE browser window by clicking File > New Window.

  3. ...

  4. ...

  5. ...

  6. ...

  7. Open a new browser window or tab using File > New Window or File > New Tab.

  8. ...

  9. ...

In this set of steps, both IE7 and IE8 create only one browser session, and closing any one window will not log the user out.

Securely Logging Out

We’ve just learned that a browser session ends when you close the last browser window within a given browser session. So is that what you need to do in order to fully log out of a website?

There’s usually a better alternative: Click the site’s Logout button. When you do that, the site will typically expire your session on the server side, and send a command to delete your session cookie on the client side. You may still wish to close your browser windows (so someone can’t simply click “Back” to see the last pages you saw) but after you click Logout, the site should force you to log in again to make any changes or retrieve any new information.

Session Information (Not just cookies!)

A common follow-up question is: “What information is a part of a session?”

  1. Session cookies

  2. sessionStorage

  3. HTTP Authentication (e.g. Digest or Basic HTTP credentials)

  4. HTTPS Client Certificates (e.g. sites that use certificates or SmartCards)

A site can clear its own session cookies by simply sending down new cookies of the same name (and path/domain) with an expiration time in the past. To clear its own sessionStorage, the proprietary clear method can be called. To clear HTTP Authentication and HTTPS client certificates, IE6 SP1 and later support the ClearAuthenticationCache command:

document.execCommand("ClearAuthenticationCache", false);


It’s worth mentioning that the ClearAuthenticationCache command clears ALL session cookies, Authentication, and Client Certificates for ALL sites running in the current session, so it’s definitely a command to execute judiciously lest you drive your site’s visitors crazy. Currently, no other major browser that supports the ClearAuthenticationCache command, although Chrome and Firefox have both acknowledged the problem and are discussing possible solutions.

Until next time,


[1] New windows will not be merged into an existing session if they are “incompatible”—e.g. we won’t merge sessions across UAC Integrity levels, and we won’t merge sessions unless options like InPrivate Browsing (-private) or No Addons Mode (-extoff) match the existing session.

Comments (18)
  1. Adam Barth says:

    Thanks for the pointer to http://code.google.com/p/chromium/issues/detail?id=5497.  I’ll try to get that implemented soon.

  2. Rob^_^ says:

    Hi Eric,

    I was recently having trouble loging in to my online banking account. The usual symptom… could not login with IE8 (login page did nothing on submit) but I could with another browser.

    At first I thought it was my overly long UA string, but reducing its length did not work.

    I then fired up Fiddler to have a look at IE8’s’ requests and responses.

    Nothing obvious.

    I then selected the Session Items in Fiddler and cleared them.

    Behold…. I could then login to my bank account.

    What is going on there?

    Is fiddler using ClearAuthenticationCache?

    If so surely secure bank login sites is the ideal case where we should use it.


  3. @Rob: No, Fiddler doesn’t call ClearAuthenticationCache (or any other URLMon APIs either).

    If you use the "Clear Cache" button in Fiddler, it clears WinINET/IE’s Temporary Internet Files cache, but it doesn’t sound like that’s what you did.

    Even if Fiddler had called ClearAuthenticationCache, there’s no explanation as to why that would fix the problem you describe. "Doesn’t submit" problems are typically related to JScript running on the client.

  4. Rob^_^ says:

    Thanks Eric… I can’t explain it. I just had a look again and all the external scripts are found and their domains are in my trusted sites list…. The Submit button is sus…

    <input class="menubutton" onclick="this.disabled=true,this.form.submit();" type="submit" value="LOG ON"/>

    I have worked for them in Portfolio management… I suspect their coders are in the dark and feed BS. A little more training is required.


  5. FWIW: The use of the comma operator there is a bit odd– a semicolon would be more typical.

  6. EricLaw [MSFT] says:

    blogs.msdn.com/…/session-management-within-internet-explorer-8-0.aspx discusses a registry key available to disable Frame Merging. There's a performance impact to using this, of course, since you'll end up with more frame processes.

  7. Manotas14 says:

    Hi Eric,

    I'm pretty interested on the subject because I have to maintain several ASP 3.0 applications, using Sessions that are being merged between tabs and windows.

    I have only to support IE8…. I don't have to take care of any other browser.

    We're already aware about the possibility to disable the frame merging by registry_key, however I'm still dealing with the tabbed browsing scenario. I'm trying to figure out a way to handle the problem with a reasonable amount of effort to adapt the applications…. I almost got the thing done using the SessionStorage to save an GUID and a cookie to make it available on server-side, then, I'm using this GUID as prefix of session variables, this way their unique by Tab or window and we're having kind of unique session by instance of the application…  this code is being copy to each ASP page, with the help of an include file wich contains the server-side ligic and a link to the javascript code… until now everything is fine

    The weakness of this solution is that the only way I have found to update my cookie on the server (when a same application is used from another tab) is to reload the page after new GUID generated and cookie value updated, but at this moment server-code has already been executed with wrong GUID read from the cookie….  

    I think I there's nothing else to do. I cannot see a way to read the SessionStorage.GUID, update cookie if needed and gurantee that meanwhile there is not server-code execution with old-cookie value. There's no way to update cookie neither to redirect or warn users on time…. any action done on client-side will be done after VBScript code…. :-S …. Am i wrong ?

  8. Eric Tan says:

    Hi, EricLaw,

      I tested a https site which uses smart card, but I find when I  open a new windows, it still need to select the cert and input the pin code. So why? Won't they merge the ssl session?


  9. EricLaw [MSFT] says:

    @EricTan: I might be mistaken, but I don't believe SChannel's client auth handles can be shared cross-process.

  10. Eric Tan says:

    Hi  EricLaw:

       I notice that you said session Information contained https client certificates, a new window will share session in IE8. You mean the certificates used in SSL?  If a new window or tab share the certificate, doesn't it mean that they share the ssl chamnel in order to use the same certificate?


  11. EricLaw [MSFT] says:

    @EricTan: Yes, IE8 is supposed to put new tabs/windows launched to the same host into the same process when a client certificate is in use in the original process. If you have a repro site showing that's not happening, can you please email me a URL?

  12. Hi, EricLaw. I used fiddler to watch the process id of different tabs with same domain, such as vip.icbc.com.cn/…/index.jsp. I found that the process id was different. But the request of the some tab had the same process id.  By the way, I used smart card to log to corporbank.icbc.com.cn, it 's odd that I had to select the certificate and input the pin most of the times when I opened a new window, but still have chance to log in without the process of selection and input. Can you exlain me it.  

    I'm sorry I am new here, so I don't know how to get you email from this site.  


  13. EricLaw [MSFT] says:

    @Eric: I should have clarified– the "leashing" behavior that keeps HTTPS sessions in the same process only occurs when one HTTPS page opens another HTTPS page using window.open(). If you navigate two independent tabs to the same HTTPS site, they aren't guaranteed to be kept in the same process.

  14. Dani says:

    Hi @Eric,

    Thanks for the very usefull entry. Just a question. Is there any way to perform a ClearAuthenticationCache just for the current domain?

    is window.sessionStorage.clear() the way?

  15. @Dani: No, there's no way to perform this function for just one site or domain. (It's a reasonable idea that we've considered, but not something that we've gotten many requests for). Clearing sessionStorage will not touch cookies, HTTPS client certs, HTTP Auth creds, or the TIF per-session cache.

  16. Darizotas says:

    Hi @EricLaw,

    Thanks a lot for this useful post. I still have a question, because when I read that clerAuthenticationCache also clears HTTPS client certs, I understand that once I logout from a site, if I want to login again using HTTPS client certs, in case of a smartcard, I should have to introduce again the PIN code. Am I wrong?

    I created a simple PoC in order to test this, I introduce the smartcard and I login, afterwards I logout and without retrieving the smartcard I login again. No PIN code requested for the second time.

    I do this with IExplorer v11. Am I doing something wrong? Or did the implementation of this command change?



  17. @Darizotas: I would expect that you'd be prompted to select which client certificate to send again, and probably would be required to enter a PIN again, although the latter operation might not have ever been required. It's also possible that this worked at one time and later broke in one of the many process-refactorings that have occurred over the years. If you have a repro, you should probably file a bug on Connect.microsoft.com so the IE team can have a look. (You may wish to confirm that session cookies are being cleared, a sign that the call to the API was correct).

  18. Darizotas says:

    Thanks for your answer @Eric.

    I can confirm you that the session cookie and HTTP credentials are cleared 🙂  But not the client cert. So I guess that I will have to clear the SSL state.

Comments are closed.

Skip to main content