Bug 530594 (eternalsession)

Session restore can result in excessive session cookie lifespan

ASSIGNED
Assigned to

Status

()

Firefox
Session Restore
ASSIGNED
8 years ago
2 months ago

People

(Reporter: ladamski, Assigned: Amy, NeedInfo)

Tracking

(Blocks: 3 bugs, {privacy, sec-want, uiwanted})

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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

8 years ago
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

Comment 3

8 years ago
> 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

8 years ago
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?
(Reporter)

Comment 5

8 years ago
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

8 years ago
> 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.
Duplicate of this bug: 636209
Whiteboard: [sg:want]
Duplicate of this bug: 650298

Comment 9

6 years ago
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.

Updated

6 years ago
Duplicate of this bug: 650332

Updated

6 years ago
Keywords: privacy

Updated

6 years ago
Duplicate of this bug: 660994
Alias: eternalsession
Duplicate of this bug: 657226
Duplicate of this bug: 662306
Duplicate of this bug: 693275
Duplicate of this bug: 697684

Comment 16

6 years ago
This bug is now 2 years old, and the DUPs show that this is still a significant threat.

Comment 17

6 years ago
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

6 years ago
> 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
Duplicate of this bug: 716984

Comment 20

5 years ago
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

5 years ago
If a public computer allows visitors to change browser prefs, you have bigger problems than session restore.

Comment 22

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
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.

Comment 28

5 years ago
@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

5 years ago
> 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)

Comment 31

5 years ago
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

5 years ago
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

5 years ago
Elideb, do you have any app tabs? If so, you're probably hitting bug 704779.

Comment 34

5 years ago
Most of the bugs marked as dups of this bug are actually dups of bug 345345.

Comment 35

5 years ago
(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.
Duplicate of this bug: 741768

Comment 37

5 years ago
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.
Keywords: sec-want
Duplicate of this bug: 769127

Comment 39

5 years ago
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

5 years ago
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

5 years ago
@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.

Updated

5 years ago
Whiteboard: [sg:want] → [sg:want] suggestion in comment 17/18
Duplicate of this bug: 807591

Updated

5 years ago
Duplicate of this bug: 794253

Comment 44

4 years ago
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

4 years ago
(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

4 years ago
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...
Duplicate of this bug: 894858
Blocks: 1160368

Updated

2 years ago
Duplicate of this bug: 693281

Updated

2 years ago
Duplicate of this bug: 1240288
(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

Comment 51

a year ago
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.

Updated

a year ago
Blocks: 1263419
(Assignee)

Updated

a year ago
Assignee: nobody → amchung
(Assignee)

Comment 52

a year ago
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!
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?
(Assignee)

Comment 55

a year ago
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)
(Assignee)

Comment 57

a year ago
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)

Updated

a year ago
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.

Comment 60

11 months ago
> 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).

Comment 62

11 months ago
(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.

Comment 64

11 months ago
Apologies, I misunderstood you.  Going over to bug 1286748.

Comment 65

11 months ago
> "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.

Updated

10 months ago
Duplicate of this bug: 1296167

Updated

10 months ago
Duplicate of this bug: 1298452
Duplicate of this bug: 1296167
Blocks: 1330633
Blocks: 529899
Assignee: nobody → amchung
Status: NEW → ASSIGNED
(Assignee)

Updated

5 months ago
Whiteboard: [sg:want] suggestion in comment 17/18 → [necko-next],[sg:want] suggestion in comment 17/18

Updated

3 months ago
Duplicate of this bug: 1349175

Updated

2 months ago
Whiteboard: [necko-next],[sg:want] suggestion in comment 17/18 → [necko-backlog],[sg:want] suggestion in comment 17/18
You need to log in before you can comment on or make changes to this bug.