Last Comment Bug 530594 - (eternalsession) Session restore can result in excessive session cookie lifespan
(eternalsession)
: Session restore can result in excessive session cookie lifespan
Status: NEW
[sg:want] suggestion in comment 17/18
: privacy, sec-want, uiwanted
Product: Firefox
Classification: Client Software
Component: Session Restore (show other bugs)
: unspecified
: All All
: -- normal with 17 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 636209 650298 650332 657226 662306 693275 693281 697684 716984 741768 769127 794253 807591 894858 1240288 1298452 (view as bug list)
Depends on:
Blocks: 1263419 1286748 443354 704779
  Show dependency treegraph
 
Reported: 2009-11-23 11:31 PST by Lucas Adamski [:ladamski]
Modified: 2016-09-02 03:41 PDT (History)
56 users (show)
amchung: needinfo? (shorlander)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
bug-530594.patch (4.05 KB, patch)
2016-06-03 03:49 PDT, Amy Chung [:Amy]
josh: feedback+
Details | Diff | Splinter Review

Description Lucas Adamski [:ladamski] 2009-11-23 11:31:00 PST
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.
Comment 1 Jesse Ruderman 2009-11-23 12:12:02 PST
See also bug 443354, "Save and Quit" tabs should not save session cookies of to-be-restored tabs.
Comment 2 Daniel Veditz [:dveditz] 2009-11-24 10:07:24 PST
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.
Comment 3 Ben Bucksch (:BenB) 2009-11-24 10:12:59 PST
> 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.
Comment 4 Jesse Ruderman 2009-11-24 11:49:40 PST
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?
Comment 5 Lucas Adamski [:ladamski] 2009-11-25 21:15:53 PST
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.
Comment 6 Ben Bucksch (:BenB) 2009-11-26 04:19:58 PST
> 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.
Comment 7 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-02-26 11:39:03 PST
*** Bug 636209 has been marked as a duplicate of this bug. ***
Comment 8 Daniel Veditz [:dveditz] 2011-04-27 10:35:22 PDT
*** Bug 650298 has been marked as a duplicate of this bug. ***
Comment 9 Ben Bucksch (:BenB) 2011-04-27 10:45:59 PDT
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.
Comment 10 Vlad [QA] 2011-05-10 07:32:44 PDT
*** Bug 650332 has been marked as a duplicate of this bug. ***
Comment 11 Jesse Ruderman 2011-06-02 12:49:52 PDT
*** Bug 660994 has been marked as a duplicate of this bug. ***
Comment 12 Daniel Veditz [:dveditz] 2011-06-08 18:34:42 PDT
*** Bug 657226 has been marked as a duplicate of this bug. ***
Comment 13 Daniel Veditz [:dveditz] 2011-06-08 18:42:48 PDT
*** Bug 662306 has been marked as a duplicate of this bug. ***
Comment 14 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-10-12 17:00:39 PDT
*** Bug 693275 has been marked as a duplicate of this bug. ***
Comment 15 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2011-11-09 12:42:51 PST
*** Bug 697684 has been marked as a duplicate of this bug. ***
Comment 16 Ben Bucksch (:BenB) 2011-11-09 12:51:46 PST
This bug is now 2 years old, and the DUPs show that this is still a significant threat.
Comment 17 Elizabeth 2011-11-09 13:00:57 PST
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.
Comment 18 Ben Bucksch (:BenB) 2011-11-09 13:19:50 PST
> 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.
Comment 19 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2012-01-11 16:49:12 PST
*** Bug 716984 has been marked as a duplicate of this bug. ***
Comment 20 Dan 2012-02-15 06:30:18 PST
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.
Comment 21 Jesse Ruderman 2012-02-15 10:24:18 PST
If a public computer allows visitors to change browser prefs, you have bigger problems than session restore.
Comment 22 Dan 2012-02-15 10:54:41 PST
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.
Comment 23 Ben Bucksch (:BenB) 2012-02-15 11:04:25 PST
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.
Comment 24 Dan 2012-02-16 16:04:12 PST
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".
Comment 25 James May [:fowl] 2012-02-16 19:02:30 PST
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.
Comment 26 Dan 2012-02-16 19:49:44 PST
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.
Comment 27 Emanuel Hoogeveen [:ehoogeveen] 2012-02-16 20:14:51 PST
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.
Comment 28 Elizabeth 2012-02-17 01:52:42 PST
@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.
Comment 29 Ben Bucksch (:BenB) 2012-02-17 06:07:22 PST
> 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.
Comment 30 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2012-02-17 08:58:57 PST
(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)
Comment 31 Jesse Ruderman 2012-02-17 13:37:48 PST
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.
Comment 32 Elideb 2012-02-17 18:27:56 PST
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.
Comment 33 Jesse Ruderman 2012-02-17 23:24:23 PST
Elideb, do you have any app tabs? If so, you're probably hitting bug 704779.
Comment 34 Jesse Ruderman 2012-02-17 23:25:58 PST
Most of the bugs marked as dups of this bug are actually dups of bug 345345.
Comment 35 Elideb 2012-02-18 04:42:23 PST
(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.
Comment 36 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2012-04-03 07:30:26 PDT
*** Bug 741768 has been marked as a duplicate of this bug. ***
Comment 37 Bill Sanford 2012-04-03 08:00:53 PDT
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.
Comment 38 Daniel Veditz [:dveditz] 2012-06-27 22:42:34 PDT
*** Bug 769127 has been marked as a duplicate of this bug. ***
Comment 39 Manoj 2012-06-28 09:17:09 PDT
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
Comment 40 Manoj 2012-06-28 09:20:19 PDT
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.
Comment 41 Elizabeth 2012-06-28 09:27:27 PDT
@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.
Comment 42 Matthias Versen [:Matti] 2012-11-01 16:11:43 PDT
*** Bug 807591 has been marked as a duplicate of this bug. ***
Comment 43 Frank Breitling 2012-11-02 01:38:54 PDT
*** Bug 794253 has been marked as a duplicate of this bug. ***
Comment 44 Nicolas Barbulesco 2013-03-05 06:43:35 PST
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.
Comment 45 Elizabeth 2013-03-05 07:02:05 PST
(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]
Comment 46 Frank Breitling 2013-03-05 07:49:17 PST
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...
Comment 47 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2013-07-17 05:18:07 PDT
*** Bug 894858 has been marked as a duplicate of this bug. ***
Comment 48 :Gijs Kruitbosch 2016-01-11 11:16:08 PST
*** Bug 693281 has been marked as a duplicate of this bug. ***
Comment 49 Gingerbread Man 2016-01-16 06:49:04 PST
*** Bug 1240288 has been marked as a duplicate of this bug. ***
Comment 50 Gian-Carlo Pascutto [:gcp] 2016-02-01 08:24:28 PST
(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.
Comment 51 Kestrel 2016-04-06 07:22:48 PDT
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.
Comment 52 Amy Chung [:Amy] 2016-06-03 03:49:01 PDT
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!
Comment 53 Josh Matthews [:jdm] 2016-06-06 05:05:46 PDT
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.
Comment 54 Josh Matthews [:jdm] 2016-06-06 05:06:25 PDT
(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?
Comment 55 Amy Chung [:Amy] 2016-06-07 01:09:28 PDT
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!
Comment 56 Josh Matthews [:jdm] 2016-06-07 09:13:05 PDT
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.
Comment 57 Amy Chung [:Amy] 2016-07-12 04:04:27 PDT
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!
Comment 58 Jason Duell [:jduell] (needinfo me) 2016-07-20 18:17:58 PDT
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.
Comment 59 Gian-Carlo Pascutto [:gcp] 2016-07-21 02:34:05 PDT
(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.
Comment 60 Elizabeth 2016-07-21 03:08:47 PDT
> 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).
Comment 61 Gian-Carlo Pascutto [:gcp] 2016-07-21 03:16:46 PDT
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).
Comment 62 Elizabeth 2016-07-21 04:38:11 PDT
(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.
Comment 63 Gian-Carlo Pascutto [:gcp] 2016-07-21 05:06:14 PDT
(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.
Comment 64 Elizabeth 2016-07-21 05:31:39 PDT
Apologies, I misunderstood you.  Going over to bug 1286748.
Comment 65 Ben Bucksch (:BenB) 2016-07-27 09:49:00 PDT
> "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.
Comment 66 Chris Peterson [:cpeterson] 2016-07-27 10:27:46 PDT
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.
Comment 67 Daniel Veditz [:dveditz] 2016-08-18 10:42:21 PDT
*** Bug 1296167 has been marked as a duplicate of this bug. ***
Comment 68 :Gijs Kruitbosch 2016-09-02 03:41:43 PDT
*** Bug 1298452 has been marked as a duplicate of this bug. ***

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