Open Bug 530594 (eternalsession) Opened 15 years ago Updated 2 months ago

Session restore can result in excessive session cookie lifespan

Categories

(Firefox :: Session Restore, defect, P3)

Product:
Firefox
Component:
Session Restore
Type:
defect

Tracking

()

People

(Reporter: ladamski, Unassigned)

References

(Depends on 2 open bugs, Blocks 3 open bugs)

Details

(Keywords: privacy, sec-want, uiwanted, Whiteboard: [necko-backlog],[sg:want] suggestion in comment 17/18)

Attachments

(1 file)

bug-530594.patch
4.05 KB, patch
jdm
: feedback+
Details | Diff | Splinter Review 
Since session restore saves and restores session cookies, it significantly modifies expectations around session cookies (namely that session cookies expire when the browser quits).  This can result in session cookies being kept alive for much longer in Firefox than expected.  

This has security implications as the longer a cookie is kept alive the great the risk of a brute force attack succeeding.  Best practices around sliding window (i.e. idle) session cookie lifespans recommend a time-out of somewhere between 5-25 minutes.  Websites that expect cookies to live longer than a day or two generally use 'persistent' cookies instead.

I'm proposing that we should implement an absolute session cookie lifespan limit of 7 days, which means that a session cookie would expire after 7 days regardless of sliding window (keepalive) behavior.

Another approach could be to implement a sliding window time limit of say 24 hours, but that would not necessarily address the underlying issue of session cookies being kept alive potentially indefinitely.
See also bug 443354, "Save and Quit" tabs should not save session cookies of to-be-restored tabs.
Yes, this grew out of discussions around bug 443354, which as written the Firefox team does not want to implement because the current behavior is useful for some people and not necessarily dangerous if you never ever share a computer.

This and bug 529899 are partial solutions, though it really seems simpler to just offer an option with the home page setting to save my tabs with/without data.

The proposed solution may be problematic: if the objection to bug 443354 is that users expect to restart their browser and have everything "just work", having sites mysteriously fail to do so every seven days may be worse than consistently forgetting session data.
Blocks: 443354
> having sites mysteriously fail to do so every seven days may be worse than
> consistently forgetting session data.

Yes, I don't like that either. I sometimes keep my shopping pages open long time, and are happy when the shop doesn't expire me, so neither should Firefox.
I don't understand how this would help.  What kind of "brute force" attack would this prevent?  Is it an attack involving the client or the server?
Session cookie should expire after 5-25 minutes.  If a site wants a session to remain alive for a week it should use a persistent cookie.  Or we could stop persisting session cookies as part of tab restore.  If someone can find examples of long live session cookies on major sites please put them in this bug.
> Session cookie should expire after 5-25 minutes.

Who says that? The spec says:
"Max-Age The default behavior is to discard the cookie when the user agent exits."(RFC 2109 4.3.1, RFC 2965 3.3.1)

You could loosen the spec and redefine session cookies as one that applies only to the current *visit* of the website. That ends at latest when the user closed all pages of the site.
There's absolutely nothing that support expiring the cookie after a certain time. In fact, if the site wanted that, it would have set Max-Age. It also breaks sites.

As I said, I get really annoyed with shopping sites that empty my basket or even log me out just because I gather more information about the products I am about to buy, or want to think more about it before committing to the purchase. That may take hours, sometimes days.
Whiteboard: [sg:want]
See bug 650298 for an important threat situation.

So, this bug title correctly specifies the problem, but the solution proposed here is IMHO not the proper one. Apart from interfering with normal use (see my comments above), it's not a complete fix for bug 650298. I close the browser and expect sessions to be gone, not somebody being able to go to my computer immediately after I leave the room and explicitly closed the browser.

We should just do what the spec says and empty session cookies when the browser exists. "Session restore" should not restore cookies.
Keywords: privacy
Alias: eternalsession
This bug is now 2 years old, and the DUPs show that this is still a significant threat.
The bug I filed, 697684, has just been marked a duplicate of this.  It's subtlely different as I was interpreting the bug as being with the preferences option "Accept 3rd party cookies.  Keep until I close Firefox" -- which is not enacted.  Rather than the complicated sliding scale suggested here, I'd just like there to be two options in the preferences, with the difference made clear.  So that people who choose to keep their tabs but not their cookies can do so.
> two options in the preferences, with the difference made clear.
> choose to keep their tabs but not their cookies

That's a good idea to break the tie that we have here.
Blocks: 704779
This is a huge security issue, and the fact that Mozilla even allows such functionality makes me question what other security issues Firefox has hidden under the covers.  This behavior makes it very easy for someone with malicious intent to enable "Show my windows and tabs from last time" on a public computer and then camp-out and wait for someone to close the browser thinking they had destroyed their session.  Until this issue is addressed, not only will I not be using Firefox on public computers anymore, but my best practice moving forward will be to block Firefox from public facing applications that require authentication.
If a public computer allows visitors to change browser prefs, you have bigger problems than session restore.
You must look at this issue from the a web application security perspective.  If I have a public facing web application that requires authentication, and I have no control over how the Firefox preferences are configured on public/shared computers, then I have no way to guarantee that my end users sessions are protected if they are using Firefox with "Show my windows and tabs from last time" enabled.  From a application security perspective I have to assume that my end users won't hit Logout, and that the user may assume by closing the browser that their session was destroyed (not realizing that "Show my windows and tabs from last time" is enabled).  Since I have don't have control over how Firefox is configured on public/shared computers, then my only option for securing my application against someone hijacking a previous users session on a public/shared computer is to block all users from using Firefox on our sites.
Dan, Jesse is saying that from a web app perspective, you cannot trust such a host *at all*.
If you want to continue this point, please file a new bug. This bug here is talking from a user perspective, not a web app perspective.
Until this new feature its always been the case that application end-users as well as application providers could trust that when a user agent exits that it does not leave any lingering sessions active.  So I think the point is valid from both the user and application perspective. 

The word "default" used in the specification leaves a lot to interpretation "Max-Age The default behavior is to discard the cookie when the user agent exits."(RFC 2109 4.3.1, RFC 2965 3.3.1), so I can see how you could make the argument that since "Show my windows and tabs from last time" is not enabled by default that Firefox does conform to the current specification.

What are your thoughts about RFC 2109 4.2.2 where the specification states:

 Secure 
     ...

      The user agent (possibly under the user's control) may determine
      what level of security it considers appropriate for "secure"
      cookies.  The Secure attribute should be considered security
      advice from the server to the user agent, indicating that it is in
      the session's interest to protect the cookie contents.

Given Firefox's strong commitment to security (http://www.mozilla.org/en-US/firefox/security/); what about an approach where session cookies marked Secure are always destroyed on exit?   The specification seems to leave this decision up to the user agent...and since it says "(possibly under the user's control)" it would seem you could make this the default behavior without the option to disable it.

Thoughts?

The spec also states that we can use a Cache-Control header to stop the user agent from caching the session cookie. Do you know if Firefox adheres to this requirement if "Show my windows and tabs from last time" is enabled?

RFC 2109 4.2.3
* To suppress caching of the Set-Cookie header: Cache-control: no-
     cache="set-cookie".
The whole point of the feature is to act as if the browser was never closed. Why should updating (and therefore restarting) my browser require me to lose all my state?

If you want to limit session lifetimes just expire your session tokens more eagerly - the browser is an /user/ agent.
Last comment...I think I've made my point clear. 

Simple, don't update your browser until you've finished what your working on. And if you lose your state then it's probably because the site intended it that way.  If not, then the site should have used persistent cookies if they had state information that they had intended to be persisted. Session cookies are not to be saved past the life of the browser process because it is a security risk, it that simple.   

http://www.allaboutcookies.org/cookies/cookies-the-same.html

Think like a criminal for a second. Go to a public place where they have shared computers using Firefox and change the Firefox settings so "Show my windows and tabs from last time".  Now sit back at a distance and wait for someone to login to their Gmail, or bank account then close Firefox without clicking the logout button. As soon as they leave open Firefox and your in.  Your below average criminal can pull this one off without an ounce of computer skills.  

This is a very big security hole and it should be closed.
James, while I don't really want to add more noise to this bug, I think you're conflating two different things here: Firefox is clearly able to differentiate a restart from explicitly closing the browser, as evidenced by the behavior when "When Nightly starts:" is set to either "Show a blank page" or "Show my home page". With this setting, closing and reopening the browser will not automatically restore the previous session, but restarting the browser for an update or a change to extensions *will*.

I think everyone can see the advantages of saving session data across restarts, i.e. when you expect the browser to pop back up right away.

When you explicitly close the browser and then reopen it later on, however, this is not so obvious. For one thing, web pages associated with stored tabs may have changed, leaving the session data significantly out of date. The security problems mentioned above are another disadvantage. I'm not saying what Firefox does right now is *wrong*, per se - for instance if the browser crashes, a user will expect (or at least hope) that their data was saved. On the other hand that same user may give up in frustration, not realizing the next person to open the browser will see their data. So it's not clear that Firefox' current behavior is unequivocally *right*, either.
@James

"The whole point of the feature is to act as if the browser was never closed....If you want to limit session lifetimes just expire your session tokens more eagerly - the browser is an /user/ agent."

You assume this, but it is not communicated to the *user* that you think this is the point of the feature.  A perfectly competent, computer-literate agent may think that the point is to enable them to pick up where they left off -- but that they can additionally select the option "Accept 3rd party cookies.  Keep until I close Firefox" and ensure that the cookies are got rid off.  The fact that this is not actual behaviour removes agency from the user.
> A perfectly competent, computer-literate agent may think that the point is to enable
> them to pick up where they left off -- but that they can additionally select the
> option "Accept 3rd party cookies.  Keep until I close Firefox" and
> ensure that the cookies are got rid off.

Exactly. I do want to keep the pages open - be it newspaper articles that I want to read or MDC tabs for APIs that I need for my work - but I chose "Keep cookies until I close Firefox" *specifically* because I don't want to be tracked forever by Google or advertisers and I want a regular cut in the tracking. I want to appear that I am a completely new user who opens these articles.
Currently, Firefox doesn't allow me that.
(In reply to Ben Bucksch (:BenB) from comment #29)
> Currently, Firefox doesn't allow me that.

This may not be obvious enough to satisfy everybody, but set browser.sessionstore.privacy_level to 2 (0 = save all session cookies, 1 = don't save https/secure, 2 = don't save any)
Firefox should do something smarter if your cookie settings and session restore settings are mutually contradictory.  That needs a separate bug, though.  This bug is about session restore with the default cookie settings.
I'd like to add a point to the discussion and a potential start for fixing this issue:
So far, if "Show my windows and tabs from last time" is selected, all session cookies are saved and later restored. However, most of those cookies are for pages not in the user's current tabs, but for sessions belonging to already closed ones*. If any cookie is saved and restored in a later instance of Firefox, it should at least belong to pages in the "windows and tabs from last time." Any other cookie not represented in such population should be removed if "Keep until: I close Firefox" is selected.

This keeps the current behaviour for people who, as commented, would leave their online shopping basket loaded, close Firefox and expect the basket to remain saved, while at least giving a partial solution for people worried about their cookies. If you don't want cookies for your mail to be restored you can at least close its tab, but still take advantadge of the "Show my windows and tabs from last time" option. With the current implementation, your mail info will be kept unless you explicitly log out.

* I've experienced this behaviour with Youtube's HTML5 trial (no account involved), StackExchange (no logout button) or Twitter (no login related info, since I log out). All this pages remember some of my settings between sessions, eventhough they shouldn't, and I rarely keep their tabs open between browsing sessions.
Elideb, do you have any app tabs? If so, you're probably hitting bug 704779.
Most of the bugs marked as dups of this bug are actually dups of bug 345345.
(In reply to Jesse Ruderman from comment #33)
> Elideb, do you have any app tabs? If so, you're probably hitting bug 704779.

Jesse, I did have an app tab, indeed. I've unpinned it and tested again Youtube and StackOverflow and their cookies are still restored after closing and opening Firefox. I've tested this 5 times, all of them with the same result, so I'd say the app tab was not the issue, unless they screw things permanently.

And even if that would be the case, I still think that making sure session restore only kicks in for remembered tabs (if "Keep until: I close Firefox") would be the way to go, fixing this bug and bug 704779 at the same time.
I went to my banking website on a secure connection and accessed my account. I then rebooted my PC without closing the browser. 

I open the FF browser and I was in the same banking web page as if I logged in again.

I should have been forced to login to my bank's website again after the reboot like I get when I close the web browser.
A bug I filed, bug 769127, was marked a duplicate of this one. The interaction between Session Restore and the Privacy Settings, specifically "Clear cookies" and "Active logins" on shutdown violates the Principle of Least Surprise [1]. There should, at the very least, be text in the preferences UI that says session cookies, and Active logins by association, will not be cleared if Session Restore is enabled. 

As a user, I am not signing away my privacy rights just because multiple people have access to the machine. The browser is not being clear that my preference to clear login information has been overridden by another preference.

[1] https://en.wikipedia.org/wiki/Principle_of_least_surprise
Additionally, I am not suggesting something as complicated as honoring session cookie duration or enforcing a 7-day maximum lifetime of said cookies. My request is either the browser delete the cookies, and obey my preference, or the browser's preferences pane tells me that Session Restore will result in the cookies not being deleted. Armed with the information, I can make an informed decision about whether Session Restore is worth the risk of secure logins persisting across sessions.
@Manoj: you can actually get Firefox to behave the way you want it to, it just isn't accessible via the UI:

Quoting https://bugzilla.mozilla.org/show_bug.cgi?id=443354#c48
"For the concerned users, they can change the hidden prefs (browser.sessionstore.privacy_level & browser.sessionstore.privacy_level_deferred) to 1 or 2 (save HTTP session cookies & no cookies respectively)."

I quite agree with you about principle of least surprise, and find it bizarre that Firefox are  ignoring requests to have this as an option accessible via the UI -- and to remove the ambiguity in the current UI option.
Whiteboard: [sg:want] → [sg:want] suggestion in comment 17/18
The request bug 443354 is tightly connected to this one.

(In reply to Dan from comment #20)

> Until this issue is addressed,
> not only will I not be using Firefox on public computers anymore, but my
> best practice moving forward will be to block Firefox from public facing
> applications that require authentication.

(In reply to Dan from comment #22)

You look in the wrong direction. The place you need is "Clear recent history..." in the menu "Tools". Although this feature deals with other than recent stuff and with more than history. This feature needs a rephrasing into something much more general, like "Clear personal data" or "Clear navigation data".

(In reply to Dan from comment #26)

> Think like a criminal for a second. Go to a public place where they have
> shared computers using Firefox and change the Firefox settings so "Show my
> windows and tabs from last time".  Now sit back at a distance and wait for
> someone to login to their Gmail, or bank account then close Firefox without
> clicking the logout button. As soon as they leave open Firefox and your in. 
> Your below average criminal can pull this one off without an ounce of
> computer skills.  

Anyway, if you can control the public computer, you can bug it with a key-logger. This is easy, you only need a few minutes.

(In reply to Bill Sanford from comment #37)

> I went to my banking website on a secure connection and accessed my account.
> I then rebooted my PC without closing the browser. 
> 
> I open the FF browser and I was in the same banking web page as if I logged
> in again.
> 
> I should have been forced to login to my bank's website again after the
> reboot like I get when I close the web browser.

That is your expectation. As a user, I expect otherwise. I expect my bank to remember me, I hate having to login again and again. It is a matter of compromise between security and usability, who are always in conflict. I think it is good to let the user decide. Let's inform the user better, and let's respect the user's informed choice.
(In reply to Nicolas Barbulesco from comment #44)

> That is your expectation. As a user, I expect otherwise..... I
> think it is good to let the user decide. Let's inform the user better, and
> let's respect the user's informed choice.

I absolutely agree.  

The problem is, that as is, Firefox does *not* behave in the way I think I have specified, as a user.  I want to "keep my tabs" and "delete all cookies when I close firefox" -- so those are the options I select in preferences, and that is the behaviour I expect.  I haven't selected an option saying "delete all my cookies when I close firefox, except for the ones for tabs that are still open", but that is what I'm getting.  [Unless I make changes in about:config].

This is the point I was making in comment 17.  A user who chooses these options in their preferences is already a pretty well informed user.  The "bug" is in the fact that behaviour is not as the selected preferences seem to describe.  Absolutely, let the user decide, but do *let* them decide.  [Without needing to find this conversation online and make the changes in about:config]
Elizabeth is right. Nicolas, you are missing the point. Please try to understand the problem that people are addressing here. A key-logger is not the solution to it...
(In reply to Jesse Ruderman from comment #31)
> Firefox should do something smarter if your cookie settings and session
> restore settings are mutually contradictory.  That needs a separate bug,
> though.  This bug is about session restore with the default cookie settings.

FWIW I've filed bug 1244756 to give a warning in this case. I'm not sure giving a warning is the best solution, but just adding extra prefs or options isn't helpful unless the user already understand that these two options don't interact well.
No longer blocks: 1160368
Duplicates regarding not honoring the user preference to clear cookies on shutdown (Bug 697684, Bug 769127, Bug 794253 and Bug 1240288) have been fixed by Bug 529899 and Bug 1260360.
Blocks: 1263419
Assignee: nobody → amchung
Attached patch bug-530594.patch — — Splinter Review 
Hi Josh,
I have added a option to let user chooses the website that be browsed can restore the session cookies or not.
Would you help me to confirm my patch?

Thanks!
Attachment #8759600 - Flags: feedback?(josh)
Comment on attachment 8759600 [details] [diff] [review]
bug-530594.patch

Review of attachment 8759600 [details] [diff] [review]:
-----------------------------------------------------------------

This code actually belongs to the Firefox frontend team, rather than the cookie peers in my opinion.

::: browser/components/sessionstore/SessionCookies.jsm
@@ +123,5 @@
>          name: cookie.name || ""
>        };
> +
> +      var restore_session = Services.prefs.getBoolPref("network.cookie.restore.session");
> +      if (!Services.cookies.cookieExists(cookieObj) && restore_session) {

It would make more sense to return immediately from this function if the preference value is false, since we won't do any work.

::: modules/libpref/init/all.js
@@ +1902,5 @@
>  pref("network.cookie.cookieBehavior",       0); // 0-Accept, 1-dontAcceptForeign, 2-dontAcceptAny, 3-limitForeign
>  #ifdef ANDROID
>  pref("network.cookie.cookieBehavior",       0); // Keep the old default of accepting all cookies
>  #endif
> +pref("network.cookie.restore.session", true);

Since this is all browser-level session storage code that is controlled by the value, browser.sessionstore.restore_session_cookies would be a more meaningful name.
Attachment #8759600 - Flags: feedback?(josh) → feedback+
(In reply to Amy Chung [:Amy] from comment #52)
> Created attachment 8759600 [details] [diff] [review]
> bug-530594.patch
> 
> Hi Josh,
> I have added a option to let user chooses the website that be browsed can
> restore the session cookies or not.
> Would you help me to confirm my patch?
> 
> Thanks!

Hi Amy! On a technical level, yes, this patch allows configuring whether Session Restore should restore session cookies. I'm not clear on the plan here, though, since making the behaviour configurable via about:config and leaving the default behaviour isn't really enough to solve this in my opinion. Are there further changes planned for this bug?
Hi Josh,
Would you offer me some candidates in Necko frontend team?
I would like to add a UI option to let user choose the behavior of restoring session cookies.

Thanks!
Flags: needinfo?(josh)
I think Mike de Boer has been active in session restore code in the frontend recently. You may want to email the firefox-dev mailing list (https://www.mozilla.org/en-US/about/forums/#firefox-dev) about your plans for the UI option.
Flags: needinfo?(josh)
As per-disused with Mike at mail, we already excited a preference id "browser.sessionstore.privacy_level" can satisfy for user request and need UX's input.
Preference id "browser.sessionstore.privacy_level" already cover my patch (I didn't browse all comment on this bug), so can pass my patch.

Thanks!
Flags: needinfo?(shorlander)
Assignee: amchung → nobody
Blocks: 1286748
Keywords: uiwanted
My understanding is that our current behavior is the same as Chrome's?  If so I suggest we WONTFIX this bug--it doesn't seem worth the bustage/user confusion/unalignment with chrome to change it.
(In reply to Jason Duell [:jduell] (needinfo me) from comment #58)
> My understanding is that our current behavior is the same as Chrome's?  If
> so I suggest we WONTFIX this bug--it doesn't seem worth the bustage/user
> confusion/unalignment with chrome to change it.

"Behavior is the same as Chrome" sounds like an exceptionally weak argument for privacy-sensitive features :-)

What does WONTFIX mean here, though? My understanding of the state of this bug is that we now have about:config preferences to control behavior, but we have no UI for it. It's not clear whether such an UI could be made understandable enough (see bug 1286748) to be in the default product. We definitely don't want to change the default.
> It's not clear whether such an UI could be made
> understandable enough (see bug 1286748) to be in the default product. We
> definitely don't want to change the default.

Well, as I have been asking for exactly this for, er, nearly 5 years, maybe I should make some suggestions.  Here are a few:

* Under Privacy: additional option for cookies in "keep until:" so that the options are now
  - they expire
  - I close Firefox: SAVE cookies from saved tabs
  - I close Firefox: ALSO DELETE cookies from saved tabs

* Under Privacy: additional clicky box under "accept cookies from sites" which says "always save cookies from saved browser tabs".  When this is selected (and it can be default for it to be selected) behaviour is the current default; when it is unselected, behaviour is what I expected.

* Under General: "when firefox starts:" options 
  - Show my home page
  - Show a blank page
  - Show my windows and tabs from last time (retain user data)
  - Show my windows and tabs from last time (discard user data).

I agree the 3rd idea here isn't ideal because it forces the issue on users with a very casual interest in their preferences.  I continue to hold the view that anyone who gets as far as the Privacy tab will understand the distinction, and many users, like me, will think the current UI options mean that they have selected behaviour to discard all cookies -- and be baffled / dismayed to find this not the case (see my comment 17 above).
It's probably better to continue the discussion about the UX in the bug that was filed for it (and which you even quoted in your response).
(In reply to Gian-Carlo Pascutto [:gcp] from comment #61)
> It's probably better to continue the discussion about the UX in the bug that
> was filed for it (and which you even quoted in your response).

I thought convention was, once a bug is filed as a duplicate, all discussion should continue in the same place?  But I'm only trying to follow convention, I'm happy either way.  I've re-posted my suggestion above back in bug 697684.
(In reply to Elizabeth from comment #62)
> I thought convention was, once a bug is filed as a duplicate, all discussion
> should continue in the same place?  

Yes, that's correct. The problem was "fixed" in this bug by adding about:config preferences. 

There is a followup bug to see if there's a possibility to make an understandable UX to control those preferences, which is, I repeat, bug 1286748.

I would imagine some kind of resolution there will cause this bug to be closed.

> But I'm only trying to follow convention, I'm happy either way.  I've re-posted my suggestion above back in bug 697684.

It looks like that bug should have been duped to bug 529899 or bug 1260360 instead of this one. The behavior described there has been fixed already, as pointed out by comment 51.
Apologies, I misunderstood you.  Going over to bug 1286748.
> "Behavior is the same as Chrome" sounds like an exceptionally weak argument for
> privacy-sensitive features :-)

Seconded. If we do everything like Chrome, there's no need for Firefox.

Google has a significant business interest in tracking people, without gap, eternally. That's exactly the problem here. Google wants that, I don't. Chrome is the worst example you could pick.
In my recent cookie testing, session restore only retains session cookies for tabs that are still open when the browser shuts down. So not *all* session cookies live forever, just the ones for the sites you leave open all the time. That's better than nothing.

Anyways, sites that really want to track you will use non-session cookies, so eagerly clearing session cookies is no protection.
Whiteboard: [sg:want] suggestion in comment 17/18 → [necko-next],[sg:want] suggestion in comment 17/18
Whiteboard: [necko-next],[sg:want] suggestion in comment 17/18 → [necko-backlog],[sg:want] suggestion in comment 17/18
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Assignee: amchung → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(jhofmann)

(In reply to Chris Peterson [:cpeterson] from comment #66)

In my recent cookie testing, session restore only retains session cookies
for tabs that are still open when the browser shuts down. So not all
session cookies live forever, just the ones for the sites you leave open all
the time. That's better than nothing.

Hello from the future!

As I commented on bug 1468220, I am not seeing this behavior in Firefox 85 (stable). I log into a site that uses session cookies to persist a session ID, close the tab, exit the browser, wait a bit, then open the browser, and go back to the site in a new tab -- still logged in.

I'd appreciate if anybody can verify that this definitely worked before. I already have mozregression installed so I'm going to see if I can figure out exactly when this broke...

Update: I ran through mozregression and got as far as flagging 2017-04-07 nightly as good, 2017-04-08 nightly as bad. It then dumped a bunch of warnings/errors along the lines of "Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.revision.{hash}.firefox.win64-opt'" but I figure a one-day window is probably good enough to find when it went wrong. I'm also kind of shocked that it happened so long ago and hasn't been addressed at all...

(In reply to James B from comment #80)

(In reply to Chris Peterson [:cpeterson] from comment #66)

In my recent cookie testing, session restore only retains session cookies
for tabs that are still open when the browser shuts down. So not all
session cookies live forever, just the ones for the sites you leave open all
the time. That's better than nothing.

Hello from the future!

As I commented on bug 1468220, I am not seeing this behavior in Firefox 85 (stable). I log into a site that uses session cookies to persist a session ID, close the tab, exit the browser, wait a bit, then open the browser, and go back to the site in a new tab -- still logged in.

I'd appreciate if anybody can verify that this definitely worked before. I already have mozregression installed so I'm going to see if I can figure out exactly when this broke...

I have verified that in FF 85.0, when I login to a site that is protected by Shibboleth (secure, httpOnly cookie), it is possible to close FF and select "Restore previous session" in the menu and access the site where all session cookies restored, including secure cookies.

Flags: needinfo?(jhofmann)
No longer blocks: 529899
Depends on: 529899
Depends on: 1666895
Depends on: 1679956
See Also: → 1793434
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 26 duplicates, 38 votes and 76 CCs.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dao+bmo)

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Flags: needinfo?(stephen)
See Also: → 1813375
Duplicate of this bug: 1813375
Duplicate of this bug: 1823911

I can confirm the observation made in comment #80. The session restore file keeps accumulating cookies forever. And because of bug 1631408, old cookies cannot be cleared selectively. The only way to get rid of them is to clear all session cookies, which I understand is possible by manipulating sessionstore.privacy_level, but I haven't tried it.

(In reply to Chris Peterson [:cpeterson] from comment #66)

In my recent cookie testing, session restore only retains session cookies
for tabs that are still open when the browser shuts down. So not all
session cookies live forever, just the ones for the sites you leave open all
the time. That's better than nothing.

So, this is not true anymore. But I'm not sure if that's good or bad. Generally, I appreciate websites remembering me even after long periods of not visiting. More importantly, the concept of a session (outside private browsing windows) has become totally nebulous due to the ubiquity of session restore features and mobile browsers that no one shuts down deliberately in order to "terminate a session". There's private browsing mode for the occasions where you actually need an isolated session that doesn't hold on to any data. That is also easy for users to grasp, unlike the behavior of classical session cookies, which normal people don't know about.

Anyways, sites that really want to track you will use non-session cookies,
so eagerly clearing session cookies is no protection.

The current situation is kind of perverse in that persistent cookies actually expire, while session cookies never do. But again, I'm not so sure that the right solution is just to delete everything on browser shutdown (at least by default). What I would like to see, though, is some way to do some basic housekeeping. Fixing bug 1631408 by associating session cookies with a Last Used timestamp would go a long way towards accomplishing that.

I wonder at what point session cookies begin to noticeably affect browser startup time, since they are all accessed during launch.

Duplicate of this bug: 1870136

I created an account just so I could report this bug. My report was closed as resolved (1870136 duplicate) and I was directed to this one.

I've just read through most of these comments. I cannot believe that this bug has been active for so long. This is a HUGE security/privacy risk. I'm able to restore tabs for websites requiring login and MFA with a click of a button even after my laptop has been fully shut down for days… I’d never log into a public computer with personal details but think about it from a home user perspective; what if a family member or friend were able to manipulate this bug to gain access to private/personal information?

The risk of someone gaining access to private information should outweigh the convenience of not having your shopping cart empty… how can Mozilla call their browser secure when they have a gaping hole like this?

(In reply to michael.whitteker from comment #92)

I cannot believe that this bug has been active for so long. This is a HUGE security/privacy risk. I'm able to restore tabs for websites requiring login and MFA with a click of a button even after my laptop has been fully shut down for days…

Sounds like what you are seeing is expected behaviour. If you haven’t logged out of a website, and neither has the website expired the session on their end due to inactivity, you remain logged in.

I don’t think anyone in this thread has suggested that Firefox should automatically log users out of everything by default when they close the browser. But if you would prefer that behaviour, you can enable the setting “Delete cookies and site data when Firefox is closed” under Settings > Privacy & Security > Cookies and Site Data.

As I understand it, the security concerns raised in the historical comments revolved around two separate issues:

  1. The session restore feature restores session cookies. That is precisely the point of session restore and therefore not a bug. The idea that this should be considered a security issue makes no sense, as websites have access to persistent storage in the browser regardless of whether session cookies are retained indefinitely or not. They’re just one particular type of cookie.

  2. The session restore feature used to make the “Delete cookies when closed” setting ineffective, but that was fixed 8 years ago.

(And of course, neither issue does not and has never applied unless you have enabled session restore, which is optional.)

The discussion that remains is about providing more fine-grained control over cookie retention and better visibility into stored session cookies.

I disagree. The universally expected behaviour when exiting a browser is that all active sessions are expired; doubly so if the user has also lodged out and fully shutdown the machine; much the same as expecting to have to use your keys to start your vehicle each and every time.

Furthermore, the expected behaviour, for a standard user, when using the “restore previous session” function is to reopen tabs and browse to those pages. Retaining access to websites that require username, password and MFA circumvents those features. A typically user would expect to re-enter login credentials.

No one is suggesting that Firefox actively signs users out of websites. In my particular case, the website in question is Outlook.com. The “remember me” function of the website is toggled off. My expectation is to have to enter my login credentials each and every session, as it would be for the majority of typical users.

The “restore previous session” feature needs to have an explicit warning that active session credentials are retained, a configurable option to retain active session credentials, with the default being “off” or a toggle to disable this feature. There is currently no option to disable ”restore previous session from the history toolbar in standard user settings, only to disable it from startup.

“Delete cookies and site data when Firefox is closed” is not a practical solution as it significantly inconveniences standard browsing.

I concur with goose' expectations. They match my understanding that when I shut down the browser or the computer, my website sessions are gone, unless I specifically told it otherwise.

(Caveat: I do expect logins and cookies to survive a browser restart that was triggered by Firefox after an update. But only because the initiator here is Firefox / the computer, not me, and the shutdown was involuntary for the user.)

Basically, the browser should do what the user told it. Browser close means the session is over.

Since we're discussing this issue on the board of a browser vendor, could we look for some telemetry data? I would be very interested to know how many users automatically "restore previous session", i.e. "open previous windows and tabs" in the Startup section of Preferences. You may believe that "the universally expected behavior" is to end the session when a browser is closed, but I suspect this viewpoint may actually be the minority, and I'll explain why:

A simple majority of web traffic today comes from mobile devices, none of which have a concept of "exiting" a web browser. It's just not a thing. You can "force quit" the application but your tabs will come right back when you launch it again. There is no "close everything and start from scratch" button, and frankly no one is asking for one to be implemented. Given that we've already found ourselves in a mobile-first world, I think "the universally expected behavior" is more likely to be a mobile-like appearance of seamless persistence -- a simple majority of users would likely be puzzled if they returned after closing a browser to find their "stuff" had vanished. Browsers have been moving in this direction for a long time. Why bother introducing tab management features like grouping and suspend/unload for inactive tabs, if not to encourage indefinite "sessions"?

First:

The universally expected behaviour when exiting a browser is that all active sessions are expired

But:

No one is suggesting that Firefox actively signs users out of websites.

And:

“Delete cookies and site data when Firefox is closed” is not a practical solution as it significantly inconveniences standard browsing.

So, you want login sessions to be cleared, but at the same time you don’t want them to be cleared, and in particular you don’t want cookies and site data to be cleared, even though that would be the method of clearing the login sessions.

I honestly do not understand what exactly you wish to happen when you close the browser. Could you elaborate, goose & BenB?

A website’s login session is a conceptual thing. It’s the website that determines whether a session is still ongoing or not, typically based on a piece of data it has stored in the browser. There is no way for a browser to unilaterally end a session while retaining all the other data the website has stored. Either you (1) log out manually, (2) rely on the website’s inactivity timeout mechanism, or (3) clear cookies for the site in question. Automatically invoking the third option upon browser close is available in Firefox’s settings.

This bug is about the accumulation of session cookies when session restore is enabled. But as I wrote in my previous comment, a session cookie (despite its name) is just one type of local storage provided by the browser. The session-maintaining token stored by the website is not required to reside in a session cookie. Thus, there is no guarantee that clearing session cookies alone will get you logged out of every website. And likewise, not using session restore at all still does not mean you won’t stay logged in to websites.

For example, navigating to Google (where I am logged in) and inspecting browser storage, I can see that there are 15 cookies set from the root domain, none of which are session cookies. So clearing only session cookies would do nothing in this case. And disabling session restore would also change nothing. The login session remains in place until I explicitly log out or clear my cookies, or Google decides it’s time to require a new login.

James B in comment 96 makes a good point about user expectations being trained by mobile. It's true that this blurrs the lines a litte bit, and it's not clear when a session ends on mobile, given that I never close the apps. I think you would agree that when a user force-quits the browser on mobile (indicating his wish to start over fresh, which indeed is rare, due to mobile OS UIs), or didn't visit the site for a few days or a week, the session is over?

@bintoro (comment 97): In the standards, there is the concept of session cookies. The website says that this is a session cookie, and expects the browser to delete them at the end of the "session". Unfortunately, last time I checked, "session" was not clearly defined, it's one website visit. I understand that as the user visiting a site, doing something, and leaving the site. When leaving, the session ends. If I have no tabs open with the site, the session ended. The session most definitely ends when the browser is closed, at the very latest. Or the computer is shut down. This is the most obvious and clearest point when a session ends, even from the perspective of an end user. So, keeping cookies after the user closing the browser to me is a violation of the standard, and a violation of the expectations of websites and end users.

Yes, the website has the option to store cookies that last beyond the session. That is then the responsibility of the website. E.g. because the website offered "Keep me logged in", and the user specifically chose that. Of course that should be honered, because it was an explicit user wish.

However, if the user left "Keep me logged in" unchecked, and the site made a session cookie only, and we persist it anways, then we go directly against what the user and the website asked for.

In short: I expect session cookies to be forgotten when the browser is closed by the user, or by a explicit computer shutdown. But not by a restart due to updates.

Regarding: "Delete cookies and site data on browser exit". I agree that this is a different question. (I only respond because you asked.) I have this turned on, because I don't want Google and others to track me forever. I want a "clean cut" once in a while. However, this is highly inconvenient, because it also deletes all site data whenever there is a Firefox update. That's not what I want. This little detail makes that feature completely unusable. So, given that problem, I would assume that not many people have this feature turned on. But that's a problem with Firefox updates, and not inherent.

Re: mobile force-quit, I personally would not want my session in Tab A to end just because Tab B crashed and hung the browser. Actually, I wouldn't want that to apply to desktop either. (IME it's pretty rare for a whole browser to crash these days since tab isolation has gotten pretty good, but it's not entirely unheard-of.)

Re: the "keep me logged in" checkbox, you may have gotten to the heart of the situation. As an end user, what do I expect that box to do? If there's a "keep me logged in" that implies the existence of a "don't keep me logged in", i.e. automatic logout -- but when does that happen? Some people would assume at a fixed time, and some would assume after some specific action (like closing a tab or browser).

This also starts a sort of arms race, where sites want to force logout and (some) users want to avoid having to redo the login process. You saw the same thing with password managers, sites wanted to prevent browsers from saving passwords -- "for security", which is dumb, but that's an argument for another issue -- while (some) users wanted to save passwords in spite of that, so browser vendors had to try to circumvent the site intent. Browsers have to try to accommodate users who want to stay logged in all the time, and also users who want to be forced back through the login process.

mobile force-quit, I personally would not want my session in Tab A to end just because Tab B crashed and hung the browser.

I didn't mean crashes, I meant the user explicitly closing the app. From a developer perspective, the app gets onPause, onStop etc. notifications from Android. From the user perspective:
If the user wants to force a clean start, what should she do?

users who want to be forced back through the login process.

If (for whatever reason) I don't want my family members into my account of a certain password-protected site (whatever that may be), I'd leave "[ ] Keep me logged in" unchecked, and close the browser after the session. Closing the browser is easy enough. I will not reliably remember to always explicitly log in, there are bound to be situations where I forget, so that's not a solution. As a user, I expect the session to end when I close the browser.

This also starts a sort of arms race, where sites want to force logout

Exactly. If the browser keeps session cookies desite the session ending (e.g. browser close), the site will take actions against that in such cases. These actions will typically have other negative side effects.

Here’s the thing: unchecking “Keep me logged in” does not mean that the login session will become tied to a session cookie. It’s up to the website to decide what to do. On some sites, a transient session might mean “until session cookie expires”, but on others it might mean a 4-hour inactivity timeout instead of a 30-day one.

Therefore, relying on session cookie clearance is not going to work universally for terminating transient sessions and avoiding the kind of surprise goose experienced. Maybe for Outlook.com it works, but there’s no guarantee. Users would have to learn by trial and error which sites they get logged out of, and they would still have to remember to log out manually everywhere else.

I understand that as the user visiting a site, doing something, and leaving the site. When leaving, the session ends. If I have no tabs open with the site, the session ended. The session most definitely ends when the browser is closed, at the very latest. Or the computer is shut down.

If websites and users want sessions to be very short-lived, there’s nothing stopping the websites from implementing auto-logout just the way they want, such as when the last page is closed. The fact that not many websites do this suggests that either they or their users don’t actually want it.

So, keeping cookies after the user closing the browser to me is a violation of the standard […]

It’s up to the browser to define when a session ends (RFC 6265, section 5.3, last paragraph). Both Firefox and Chrome have made the determination that session cookies persist across restarts if the user has opted in to session restore. The reason is that there can be all kinds of information in those cookies that users don’t want suddenly to disappear.

The same people calling for clearing session cookies on exit refuse to clear all their cookies because it would inconvenience them. But that’s exactly why session cookies aren’t cleared either when session restore is enabled; it would inconvenience users. This has been discussed repeatedly before. The prevailing viewpoint is that, on balance, any improvement in security isn’t enough to outweigh the inconvenience of inadvertently lost sessions.

[…] and a violation of the expectations of websites and end users.

I can see how persisting a session cookie indefinitely could once be considered a violation of a website’s expectations, but not really anymore, as this situation has been going on for over 15 years.

As for user expectations, I would say that users generally expect application state to be restored, particularly if the feature is labeled “Continue where you left off” as in Chrome. The wording in Firefox (“Open previous windows and tabs”) could definitely be improved, as it doesn’t really convey that the state of closed tabs will be restored as well. Safari uses similar language to FF, but the browser seems to discard session cookies for tabs that are no longer open.

Anyway, not only do user expectations vary, they can be contradictory. The same user might reasonably expect to keep their shopping cart intact but also to be automatically logged out of their webmail, since it’s subjectively more private. But if both apps rely on session cookies, it’s not possible to satisfy the expectations simultaneously. So a judgment call is required. If we lose the shopping cart, the user has no remedy. If we forgo terminating the webmail session, the user does have a remedy: logging out of there manually.

It would be a different story if, back in the day, the industry had agreed that session cookies should only be used for storing information that must be discarded upon browser close for reasons such as explicit user request. If that were the case, browsers would have no incentive to persist session cookies across restarts. Websites, in turn, could rely on this feature, and unchecking “Keep me logged in” could have become de facto synonymous with setting a session cookie. Sadly, this is not the reality today.

All of that said, it absolutely should be possible to clear session cookies with the press of a button. Right now the management of session cookies is totally broken (see my comment 90). And since this is such a controversial issue with browsers behaving in different ways, I think it would be totally reasonable to allow users to choose between two flavours of session restore via a subordinate option:

[ ] Restore windows, tabs, and session data
    [ ] Restore session data for open websites only

Checking the suboption would trigger Safari-like behaviour.

The concern (as always) is that users can get confused about a multitude of settings. But I don’t think having these two options would be too hard to understand. Users are already familiar with what happens when session restore is disabled (since that is the default). In Safari mode, that’s what happens for closed sites, while full state is restored for open sites. Pretty simple. Also, the word “session” already appears in Privacy & Security > Cookies and Site Data > Manage Exceptions.

There are historical comments saying that you’re supposed to be able to set sessionstore.privacy_level = 2 to force session cookies to expire upon browser restart even with session restore enabled. If this has ever been true, it's broken now. In my testing, all local storage gets purged on browser close, both session and persistent.

The longer I spend reading back over the last dozen or so posts here, the more I get the feeling that session cookies were a mistake in the first place. Best case, "session" is meaningless, worst case -- and certainly much closer to reality -- everybody has a different idea of what it should mean.

Can we just get rid of the concept altogether? As bintoro points out, we don't need an agreed-upon meaning of "session" to implement any of the behaviors requested here. There are plenty of other tools in the toolbox.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: