New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 92 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Issue 128513: Session Cookies not cleared when Chrome processes closed

Reported by, May 17 2012

Issue description

Chrome Version        : 19.0.1084.46
OS Version            : 6.1 (Windows 7 SP1)
URLs (if applicable)  : Any
Other browsers tested : None

What steps will reproduce the problem?
1. Select a test website (eg. facebook)
2. Set cookie mode to 'Session' for that website (see attachment)
3. Perform an operation to set a cookie (eg. log in)
4. Close the browser without logging out (no processes remained in Windows Task Manager)
5. Restart the browser, and navigate to the website

What is the expected result?

When navigating to the website after a restart, the cookie should not
be present (ie. you should not be logged in).

What happens instead?

The cookie is present, and I remain logged in.
This behaviour has appeared within the last 48 hours (ie, coinciding with the time of release of Chrome 19).

Tested (accidentally) with facebook and google reader.

I do not have any issues with incognito windows - all data is closed when the last incognito tab is closed (so, probably not a side affect of #47087)

Note: these are Session's in the browser, rather than a session between the browser and a remote host. This may be a duplicate or related to #30483.

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5

Task Manager: Browser / Tabs / TinEye Reverse Image Search / GPU Process.
Extensions: TinEye Reverse Image Search / GooglePlusPlus (custom applied skins for Google services - should not be invoked for facebook)

Attachment notes:
session-cookies: the previous page has:
"Block sites from setting any data" and "Block third-party cookies and site data".

"Clear cookies and other site and plug-in data when I close my browser" is not selected because this always deletes the non-Session cookies, somewhat defeating the point of the Allow/Session/Block options.
12.2 KB View Download

Comment 1 by, May 18 2012

Labels: -Area-Undefined Area-Internals Internals-Network-Cookies Feature-Privacy

Comment 2 by, May 18 2012

Could you please check on chrome://chrome/settings/ whether "Continue where I left off" is activated? It is interpreted in such a way that sessions continue beyond browser restarts in order to provide a seamless restart.

Comment 3 by, May 18 2012

It is indeed on that setting, which would explain the behaviour.

If memory serves, this button was previously just 'Re-open Tabs'; I take it that this option is no longer direct available.

Comment 4 by, May 21 2012

Please bring back Re-open tabs option (but clear session cookies ONLY when browser is closed). For me as a developer it's really annoying. When I open my browser I expect to start where I left off but please, Session cookies are meant to be destroyed upon broswer closage.

Comment 5 Deleted

Comment 6 by, May 24 2012

Believe this and 128567 are the same issue. 

I spent part of 3 days wading through Chrome newsgroup posts where the canned reply was to use the logout function in Gmail rather than closing the browser! If Chrome behaved properly and deleted session cookies on shutdown people would not have this problem. If people want to remain logged in then use Gmail Stay Signed In or similar option on other websites.

Comment 7 by, May 27 2012

I agree with on this.

I find this to be a serious security issue. Only by chance did I discover that suddenly my session cookies were no longer deleted when I exited the browser, so that I was still logged in to essential web sites after having completely exited the browser and started it again later, even after a restart of the computer. This is really bad.

If there is a need for a seamless restart option (which would be nice sometimes when Chrome behaves erradically), then make a dedicated "Restart" function that does that and optionally keeps the session cookies during the restart if the user says yes to that.

But when I close my browser under normal circumstances I want all session cookies to be deleted so that I am safely logged out of all essential websites.

Comment 8 by, Jun 8 2012

Apparently this is a feature and will emain in Chrome so when using this option any one with access to your computer can relaunch your Chrome browser and get access to sites which you did not explicitly log out of

I removed Chrome from all of my machines. Google did a complete 180 degree flipflop on how this option behaves. When they did this changed Google did not even bother mentioning the change in behavoir in the option which now will keep you logged into secure sites such as Gmail etc.

Comment 9 by Deleted ...@, Jun 12 2012

Google.. pls take necessary actions for correct this bug

Comment 10 by, Jun 12 2012 It seems that according to Google its not a bug its a feature and I doubt that they will be changing this setting back.

Comment 11 by, Jun 14 2012

I agree that this "feature" was not right to implement without giving more options so that it could have continued to work as it did before (Re-open Tabs). All we want is choice to configure the way we work. The option should have been easy to add, right? Like a check box that says, "Kill sessions on close" or something of the sort...

Comment 12 by, Jun 14 2012


I have the same problem. "On start-up" set to "Open the New Tab page". I close the browser, re-open and all my session variables from the previous session are still available to my php scripts. This has broken my site in Chromium currently - since I rely on the fact that closing the browser destroys the session. Since users rarely explicitly logout of a site, I tend to use the session being destroyed as a way to indicate they have ended their session.

This seems reasonable to me. The cookie called PHPSESSID, when I inspect it in Chromium, has:

Created:	Thursday, 14 June 2012 15:47:24
Expires:	When I close my browser

But it does not expire. I re-open the browser and the same cookie is sitting there with the same created time stamp.

Whether or not Google see this as a desired behaviour with "Continue where I left off" set, I have not chosen this setting, so this seems to be a bug to me.

I am running Chromium 19.0.1084.56 under Unbuntu 10.04.

Please help! Can other people confirm this behaviour? Restarting my machine does cause the cookie to expire. I have un-installed all extensions.

Comment 13 by, Jun 14 2012

Okay, the issue seems to be processes not ending when I shut the browser. Here is what I still have running after I shut the browser:

ps -A | grep chrome
 4318 ?        00:00:04 chrome
 4322 ?        00:00:00 chrome
 4324 ?        00:00:00 chrome-sandbox
 4325 ?        00:00:00 chrome
 4374 ?        00:00:01 chrome

If I kill the processes, the session cookie expires properly. Should I move this to a new bug somewhere else?

Comment 14 by, Jun 18 2012

This -- this is a serious problem. Php session cookies, marked as "expire when i close my browser" never expire if the "Continue where I left off" is used.

Cookies *must* expire when they are set to expire -- this does not prevent "Continue where I left off" from working, but it does prevent serious security issues.

Problem exists in 21.0.1171.0 dev -- probably is all versions...

Comment 15 by, Jun 19 2012

Canary build of Chrome now has a link to the following page for this setting

Seems Google will not be changing this behavoir of this setting wrt session cookies but at least now users are warned IF they click on the link beside the option.

Comment 16 by, Jun 19 2012

Well, there is no reason to just give up. Google made a clear mistake and we need to tell them that. They have ruined a nice function "continue where I left off", i.e. with the windows and tabs that where open, with this new buggy behavior that doesn't remove session cookies when the session ends. They probably weren't thinking about what they where doing.  Anybody can make a mistake, we just need to make Google aware of their mistake.

They could easily make a specific option to keep session cookies across sessions, even though it does violate some standard about session cookies (which is also the case with the current behavior). And of course that option should be off by default, because it violates the standard. People who don't want session cookies to expire at all (I wonder who that would be) could then turn that option on.

Comment 17 by, Jun 19 2012

I agree with jesper. Just because it seems like Google won't be changing it does not mean it's right. This setting went from fabulous to ridiculously broken in one version of chrome. They should not have touched this setting because it was already working as it should. The best thing they could have done was "enhance" the option (like jesper said) by adding a check box that you check to keep sessions alive (even though I disagree with this also).

Why take a step backward in security, especially since Chrome could be (and I'm sure is being) used in public such as libraries and coffee shops. So now someone unknowingly shuts down the browser thinking, "oh yeah, my sessions will close" and the next person hacks their account. I agree this is lazy thinking when it comes to sessions on a public terminal, but not everybody thinks or cares about technology and security like we do. We have to help it evolve in the right direction.

The point is: it is not right, it is a bug, fix it!

Comment 18 by, Jun 19 2012

I agree as well with jesper but I got so frustrated with this apparent disregard for people's security and privacy that I ditched Chrome off all my machines and have gone back to Firefox. I got to wondering what else did Google change in Chrome that I am unaware of behind the scenes that was lessening security in favor of convience.

I also make sure that I tell friends etc so they do not have to go through wondering what the heck is going on. I spent hours trying to figure out why Chrome all of sudden was having this "problem" of logging me out.

I do not have an Android phone but does the same thing happen with the current version of Chrome there?

Comment 19 by, Jun 21 2012

Just figured out through  issue 130291  that "Disable Better session restore" (under chrome://flags) does return the desired behavior! Why this is buried under experimental features is beyond me as it could have just as easily been a check box in the main settings so that less-advanced users can choose this option without having to dig so deep. Again, I can't stress enough, this should be how the browser works by default, and maybe "Enable Better session restore" should be an experiment. They have it backwards.

Comment 20 by, Jun 21 2012

Fantastic! Thank you.

Nadeem Hosenbokus

Comment 21 by, Jun 21 2012

Thanks for the pointer to "Better session restore"!

Searching for this phrase reveals a discussion on the Chromium-dev group that explains the rationale for the new behavior. The main problem they were trying to solve is that restarting the browser to apply a new update is too disruptive if things like session cookies are cleared.

I actually agree with this argument, but I think the discussion overlooked a completely different case, in which clearing session cookies is not an unwanted side-effect of closing the browser, but rather the *purpose* of closing the browser.

It's easy to distinguish the two cases:

1. If the user clicks a button or menu item that says something like "restart to finish updating Chrome", then the "better" session restore makes a lot of sense, especially if underneath the button is a note reminding the user that sessions will not be logged out.

2. If the user closes all the browser windows, then the "better" session restore causes all manner of confusion because this is how users are taught to log out of all their sessions.

So I think the solution is for Chrome to confine the "better" behavior to the special restart-to-update case where the goal is to hide the fact that the browser is restarting.

Comment 22 by, Jun 21 2012

Good points and I completely agree!

Comment 23 by, Jun 21 2012


Comment 24 by, Jun 21 2012

t... I had found that option when I first had this problem. However if one disables that and Chrome is updated and has to restart then the session-only cookies are lost. Its a work around to this change but what if Google removes that option entirely after all it is experimental and can disappear.

Comment 25 by, Jun 21 2012

It's still worth it to me so that I can have Chrome functioning as it did prior to version 19. It is not worth thinking about what if that "experiment" disappears, because the answer is that I won't be completely satisfied with my Chrome browsing experience. Also, as many people have mentioned between this thread and  issue 130291 , it is more similar to a bug than a new feature or advancement.

I feel it is a step backwards if keeping session cookies alive is on by default. People should be assured that when they close the browser their sessions are closed, unless they wish to keep sessions open. You should have to opt-in to keeping sessions alive past browser close.

I think @eswi... summed up the solution pretty well a few message back: "... confine the 'better' behavior to the special restart-to-update case where the goal is to hide the fact that the browser is restarting."

Comment 26 by, Jun 21 2012

@eswi: Those are sound recommendations and a couple hours ago they were brought before the Chromium-dev group you linked to (first on the list below). Let's hope they're listening...

For the record, the following threads address the same issue:!topic/chromium-dev/uV5HfzctntM/discussion   [design doc] Better session restore - Session only cookies don't delete - "continue where I left off" setting breaks session cookies per RFC 6265!topic/chrome/Yjw7Urs0fAs - Chrome does not sign me out but Firefox does when browser is closed

Comment 27 by, Jun 21 2012

@t I totally agree regarding the opt-in option for maintaining session only cookies for the  "Continue Where I Left Off". This would mean that its default setting would erred on the side of privacy and security which is what part of Google's mission statement is.

@eswi remarks are correct. The end user should specifically indicate to the web site(s) in question to keep themselves logged in during the initial login. Otherwise having that option in Gmail when using the "Continue Where I Left Off" is a bit misleading.

Comment 28 by, Jun 21 2012

Status: WontFix
This was not just changed because "updates are too disruptive".  We changed it because "continue where I left off" means "continue where I left off".  If session cookies are reset, that's frequently broken, because pages which depended on those session cookies don't reload correctly.

I understand the arguments for the other behavior, e.g. in comment 21, and I agree there is a potential for confusion when closing the browser doesn't auto-logout of websites.  What I'm trying to get at is that there are problems in both directions.  Neither behavior is perfect.

The solution we don't want is for people to have to toggle this as an option.  This violates core design principles of ours about not punting design decisions to options.  (Frankly, even the existing choices about what to do on browser start are too many options already.)  We want to pick the right behavior.

One reason why the new behavior is perceived as better is because sensitive sites with logins -- e.g. banks -- not only provide prominent "log out" mechanisms that can be triggered when you're done using them, but generally also auto-logout on a time-based basis.  So it seems less likely that this behavior is suddenly going to present what amounts to a security hole.  With many other sites, login cookies are not actually session cookies, so cases like the "close Chrome in a library, next person accesses your account" case can happen anyway.  The more comprehensive solution to this is probably for people to use tools like incognito or Chrome OS guest mode, or for the admins for the site in question to check the "clear cookies on exit" box in the options (see below).

Another way to approach the design question: if we were creating browsers from scratch today, how would we make this work?  To me the new behavior is clearly more rational, and the minority of people who actually want to explicitly log out of sites they're using should do it just for those sites, rather than always lose logins every time they try to restart the browser for any reason.  In the long term, there are far more users and usage in the future of browsers than the past, so we shouldn't necessarily continue with past designs just because that's an existing convention.

One other note: AFAIK (at least this was the way I stipulated this should work while things were being implemented), the "clear cookies on exit" checkbox deep in the options takes precedence over this setting, so if you have that checked, you'll still clear cookies when closing the browser.  (In that case, though, you lose all cookies.)

I don't know if it's possible for an extension to implement a behavior like is requested here.  If not I'd be supportive of adding the necessary extension APIs to create one, so that people who truly want this still have a fallback.  (Note that if new APIs are actually needed that should be filed as a new bug.)

I'm not going to lock this bug to other comments for the moment, mostly so if someone investigates the extension issue they can post their findings.  But I will say that this was an intentional decision that went through a lot of discussion with a lot of people, and so unless you have some truly new rationale, it's unlikely we'll change this.  "This is a bug, I don't like it, please change!" is not going to suffice.

Comment 29 by, Jun 21 2012

Incidentally,  bug 128567  implies that the "clear cookies on exit" setting may not currently be overriding the general session restore setting.  If true that's a bug and we will address it there.

Comment 30 by, Jun 21 2012

 Issue 130291  has been merged into this issue.

Comment 31 by, Jun 21 2012

Also, there are some changes afoot w.r.t. allowing you to define exactly which origins get kept and cleared across exits (as jochen@ mentions on  bug 130291  comment 4) but I don't know the precise details there so I won't try to define them.

Comment 32 by, Jun 21 2012

The issue is not only that users can no longer assume closing all browser windows will clear all session cookies, but also that the procedure to clear all session cookies suddenly changed from:

1. Close all windows


1. For each browser tab or window currently open, bring it to the front, and locate and click the Log Out button.
2. For each site you might have visited since the last time you started the browser but since navigated away from, navigate back to the site, and find and click Log Out if your session did not automatically expire.
3. Hope that the owner of any site you forgot about set a short expiration timeout.

Am I missing some alternative that does not involve a trip to the browser Settings window?

Comment 33 by, Jun 21 2012

eswi has stated the problem with perfect, succinct clarity. 

And "Clear all cookies" when the browser is closed is NOT a solution, because that is not what I (and I daresay most users) want to happen when the browser is closed. All we want is our session to close, as intuition dictates. We still want to have the benefits of functional cookies on sites we visit frequently.

> sensitive sites with logins -- e.g. banks -- not only provide prominent "log out" 
> mechanisms that can be triggered when you're done using them, but generally also 
> auto-logout on a time-based basis

I continually use three sites that contain sensitive information and I leave them up at all times when I'm at my desk:

- Gmail -- used for personal and sensitive business email
- RememberTheMilk -- used for personal and company task lists
- Evernote -- used for all kinds of work and personal stuff, much of it sensitive

These sites do not offer log-out mechanisms, nor do they have time-based auto-logout (thank goodness, or I'd be logging into them all day long). They rely on the well-established protocol that closing a browser closes the session.

Comment 34 by, Jun 21 2012

Actually Gmail does have a logout facility (and an easily accessible one).  I don't use the other two personally.

I really think the ideal in-browser solution to this is password protection for profiles, but that's a separate bug.

As I already noted, I understand your use case and we've already considered it and decided it doesn't justify reversing this decision.  One obvious change you can make: Change your startup setting from "continue where I left off" to "open a specific set of pages" and put your working set there.  This way, when you're truly done with your session, close your browser, and on restart you'll get a brand new session, pre-populated with the sites you normally start a session with, with no saved logins.

I have been informed that it is, in fact, possible to write an extension to provide the old behavior.  I don't have a link to one though.

Comment 35 by, Jun 21 2012


Between sessions there are 4 tabs that I always have open. However there will be 10 to 15 tabs that vary from session to session.. i.e. working on a project etc and when done I close that tab. Thats why I found the "Continue Where I Left Off". 

The remark about there being a minority of users is open to debate. When this started happening to me in Chrome 19, I waded through posts from end users having same thing happening to them i.e. they remained logged in. The reply was use the logout option for the website. I happened to stumble across a post which in turn lead me here. I wonder how many other users are not as determined as me to seek out the reason and instead uninstalled Chrome completely and went with another browser or those who put up with the frustration of being logged in.

Comment 36 by, Jun 21 2012

As I said on 128513, the lack of regard for security here is just mind-boggling.  This was a huge change, and compromises people's sensitive information.  How many people's GMail accounts at Starbucks have been compromised because of this?  GMail still has a checkbox that says "Stay signed in" (which shows up in Chrome, btw).  What is it for, if, when I leave it unchecked, it makes no difference!?  In fact what it does is give people a completely false sense of security.

Also, the issue about how hard it is, for an average user, to find out how to address/fix this problem, cannot be overstated.  It took me the better part of an hour to find these tickets.  One of the biggest problems is that my searches for them were all masked by hundreds of posts complaining of the exact opposite problem -- that users have trouble figuring out how to stay signed in.  And while I'm by no means an Internet savant, at least I know what a cookie is.  I pity the vast majority of users who won't be able to figure out how to get this to work the way they want.

Such cavalier disregard for users, and the security of their personal information, really taints my opinion of Google, I have to say.

Finally, if you won't fix it, at least, please, promise you won't take away the chrome://flags option.

Comment 37 by, Jun 21 2012

Over in Firefox land, the Session Restore feature now also saves session cookies. Not everyone is 110% in love with that decision, either:,345830,358042,362212,369289,375182,376605,377233,381940,395749,398827,399748,417711,431547,437911,441544,576845

Regardless of the merits, on this point Chrome can at least claim to be no worse than Firefox...

Comment 38 by, Jun 21 2012

@Voldr:  Issue 133911  (Remove better session restore from about:flags) was opened just a few hours ago. Not a good sign.

Comment 39 by, Jun 21 2012

Labels: -OS-Windows OS-All Restrict-AddIssueComment-Commit
I'm trying to get the folks who prototyped the extension I mentioned in comment 28 to either post the extension or upload some source code as a reference for anyone else who wants to do that.  Otherwise I don't think there's much further productive discussion to be had here.

I admit that I don't particularly enjoy spending a while trying to write some detailed feedback and rationale and be told that I "cavalierly disregard" our users, whom I fight for on an ongoing basis.  I accept that you don't like or agree with the route we (or Firefox) are going here.  Please accept that we do consider our users and don't make changes in a vacuum.  If you still want to grouse after that, consider the chromium-discuss mailing list or the help forums, both of which are intended more for end-user use, unlike the bug tracker, which is where the engineering team is trying to make clear decisions, schedule work, and get on with things.

Comment 40 by, Jun 22 2012

Here is the mentioned prototype for an extension that clears session cookies on browser start-up time.
791 bytes View Download
293 bytes View Download

Comment 41 by, Mar 10 2013

Project Member
Labels: -Area-Internals -Internals-Network-Cookies -Feature-Privacy Cr-Privacy Cr-Internals-Network-Cookies Cr-Internals

Comment 42 by, May 17 2018

 Issue 844075  has been merged into this issue.

Sign in to add a comment