Closed Bug 443354 Opened 14 years ago Closed 12 years ago
"Save and Quit" tabs should not save session cookies of to-be-restored tabs
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0 When opening saved sessions, it is possible to broswer a previously opened Gmail account without Logging in again. Close Firefox with a few opened tabs, one of them is Gmail (logged in) and choose to Save and Quit. When you re-open the Firefox, the tabs are opened with last session, but the you're not logged in to Gmail account. Nevertheless - you can browse the Gmail account, and not just the Cache. Even new emails can be read. Reproducible: Always Steps to Reproduce: 1.Login to Gmail 2.Close Firefox and save the opened sessions. 3.Open firefox Actual Results: You can brower Gmail account. Expected Results: Gmail account should be blocked until Login.
This happens because session-restore saves session cookies (hence the name). It's by design and known so I'm going to unhide the bug. In the case of a crash or restart after install this is generally what we want to happen -- get the user up and running right where they left off. However, it's a bad idea for the "Use my tabs from my last session" option. When users shut down the browser cleanly they (and many of the websites they're using) think they are logged out and done, but in our implementation they are not. This was true in Firefox 2 but the setting was not all that discoverable. Firefox 3 makes it much easier for people to switch to this option (good for usability) but doesn't at all educate people about the implications of building this on top of a "session" restore feature. When the browser is shut down cleanly we should discard all the session information, including session cookies, form data, and session history. Note that we should throw this out on shutdown rather than deciding on next start whether we want to use it or not -- we really don't want all this crap laying around on disk if it's not an immediate-restart situation. This might actually be a startup performance win for people who have lots of tabs with lots of session history in many of them. I know periodically have to bookmark my tab groups, switch to using a plain home page, and then restore the tabs from bookmarks to reduce some of the memory bloat and slow starts I fall into. On the other hand, having 100-200 tabs open at any given time probably puts me out of the mainstream.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Restore session allows entering Gmail without logging in → "Save and Quit" tabs should not save session cookies
Whiteboard: [sg:want P2]
In Firefox 3 people switch into this mode in droves because on quit the old "You are closing many tabs" warning now has the "Save and Quit" button mentioned in the summary, and a checkbox that allows people to permanently remember that mode. It's not clear that it's "Save my complete session" as opposed to simply preserving the tab URLs. I can see people with a secure computer might find the current behavior useful and safe so maybe one answer is just to make it clearer what's going on. Or add another home-page mode, in addition to "Show my windows and tabs from last time" have one that says "Restore my complete state from last time". It's going to be hard to make that distinction clear :-(
I nominated this wanted for both 1.9.0.x/1.8.1.x and firefox 3.1. If we're taking a change in the security/stability branches obviously the only choice is to always drop the session information (with maybe a hidden pref to bring that functionality back for the hardcore folks who want it AND have a secure non-shared machine). Any changed design that offers more choices in the UI or explains the feature better obviously can't happen until 3.1 at the earliest.
(In reply to comment #0) > Steps to Reproduce: > 1.Login to Gmail > 2.Close Firefox and save the opened sessions. > 3.Open firefox > Actual Results: > You can brower Gmail account. > > Expected Results: > Gmail account should be blocked until Login. I'm sorry, why is this expected? When I exit, I'm asked: "Do you want Firefox to save your tabs and windows for the next time it starts?" I'm not asked: "Do you want to end your current sessions but save the locations loaded in your tabs and windows for the next time you start?" It feels to me that what you're actually asking is for there to be a way to protect your session to ensure that you and you alone are the one who can resume it. Historically our policy there has been to recommend that people use one-OS-profile per user, but perhaps we should enable some sort of global "this is a shared computer" flag which sets default options for this and other similar behaviours (awesomebar, saved login info, etc), or allow more advanced profile management.
Dup of bug 345345?
(In reply to comment #5) No, this is just about the new "Quit Firefox" prompt. Then again, fixing this bug as Daniel intends to will turn this into a dataloss issue (and a UX regression on the branch). Per comment #4 this should be WONTFIX, as we simply don't ship Firefox in a state where it could be used in a public terminal without further configuration changes (see bug 345345 comment #14).
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [sg:want P2] → [sg:want P2][wontfix?]
Version: unspecified → 3.0 Branch
I would also vote for an option to clear session cookies on a normal shutdown of FF. I have many sites with over 25 session cookies after some restarts and they will never clear. Very stupid.
(In reply to comment #6) That's exactly what I wrote. Who cares about SESSION cookies. When you restart your session after one day, the server often cannot remember your session (eg ASP sites sets random session cookies with random names). I get a new session cookie created and I get more and more and I cannot clear them without removing ALL cookies or remove them manually.
Dan, Johnath, and others: What do we want to do here? I imagine the patch is pretty simple, we just need to decide what to do and whether we want a UX regression on the stable branches or not.
I'm marking this as wanted1.9.0.x+ for now to keep it on our radar.
Flags: wanted1.9.0.x? → wanted1.9.0.x+
I think there's a good bit of difference between the various information in the profile (which is somewhat under the user's control) and session cookies (which are under web sites' control in the sense that they're supposed to be transparent to the user, except for auto-disappearing when the user chooses to quit the browser)... Are there serious cases people can think of where a user would select "quit" but expect session cookies to persist? I haven't been able to think of one for myself yet (and we DO discard HTTP auth state at the moment, which is functionally completely equivalent to session cookies). For what it's worth, this seems like a pretty serious security regression to me.
(In reply to comment #12) > Are there serious cases people can think of where a user would select "quit" > but expect session cookies to persist? "Save and Quit" or just "Quit"? In the later case, session cookies are discarded as you'd expect it and in the former case, only session cookies related to any of the open tabs are persisted (which you might want for remaining logged into forums, etc.). Also note that secure session cookies are not saved by default - and that setting is only exposed through about:config. > we DO discard HTTP auth state at the moment This is a limitation in our SessionStore implementation yet to be fixed. (In reply to comment #12) > this seems like a pretty serious security regression to me. I fail to see the seriousness. We offer the user to resume his/her session at a later point and try to be as thorough as reasonably possible to fulfill that promise. Is the wording in the prompt not explicit enough or do I fail to see your actual point?
Summary: "Save and Quit" tabs should not save session cookies → "Save and Quit" tabs should not save session cookies of to-be-restored tabs
> "Save and Quit" or just "Quit"? Once you've toggled the pref (which we push people to do, as dveditz noted), it's the same thing. > which you might want for remaining logged into forums, etc. But not for remaining logged into banks, right? > Also note that secure session cookies are not saved by default Secure in what sense? Ones where the scheme+host+port has an https scheme? If so, that makes me a lot happier with the current setup... > We offer the user to resume his/her session at a later point Honestly, what I want (and I suspect most users want) is something that will restore their tabs as they were when quitting. I don't think users expect that all logins for things they navigated away from in those tabs (including ones that say that closing the browser should log you out) will be persisted... I certainly didn't, based on the dialog wording.
(In reply to comment #14) > Once you've toggled the pref (which we push people to do, as dveditz noted), > it's the same thing. As I understand it, that's not what this bug is about. In your case, there really should only be one option: save the session in such a way that we can later show your tabs in the same way as you're currently seeing them (which is what you've configured Firefox to do). > But not for remaining logged into banks, right? > Secure in what sense? Ones where the scheme+host+port has an https scheme? We don't save any data (besides the URL) for https sites and thus for most (hopefully all) banking sites... unless you set browser.sessionstore.privacy_level to 0 in about:config. > Honestly, what I want (and I suspect most users want) is something that will > restore their tabs as they were when quitting. I.e. not at all? We're currently only offering to either resume or discard your current browsing session. I guess for the "quit Firefox but first bookmark all currently loaded pages and then restore those bookmarks" case, you'll either have to set Firefox to clear all cookies at shutdown (in case you don't care about restarts and permanent cookies), or you'll have to set the .privacy_level pref to 2 (in case you don't care about restarts and crashes) or you'll need an extension (or file an enhancement bug). > I don't think users expect that all logins for things they navigated away > from in those tabs (including ones that say that closing the browser should > log you out) will be persisted... Closing the browser never logs you out of sites authenticating with cookies (you already knew that) and sites saying otherwise should be evangelized to correct their wording. Furthermore, I think that most users actually expect tabs to be restored as is (including remaining logged in) when setting Firefox to do so - unfortunately I've got no empirical data to prove that.
> As I understand it, that's not what this bug is about. As I understand it, is is. If I start with a blank profile, then quit, I get a dialog that says: Do you want minefield to save your tabs for the next time it starts? [ ] Do not ask next time [Quit] [Cancel] [Save and Quit] There is no indication that logins are going to be saved. There is no indication that session history will be saved. Heck, there is no mention of the word "session". Every single user I know has picked "Save and Quit" and checked the checkbox... What they have configured Firefox to do is to "save your tabs for next time it starts", whatever that means to them. > unless you set browser.sessionstore.privacy_level to 0 in about:config. Ah, interesting. I had to set that pref to 0, because otherwise any crash or update restart (which I hit a lot, by accident) wipes out my Bugzilla comments. Which is fine; in those cases I want to restore the session cookies too. I guess I'll turn that off and live with the bugzilla dataloss, but what I, as a user, really want is something that restores my session completely from "unintentional" shutdowns and "safely" from intentional ones. Alternately, I would like a way to whitelist certain https sites to restore form data... > I.e. not at all? We're currently only offering to either resume or discard > your current browsing session. What you're offering is exactly what I said above. And a typical user sees that dialog exactly once. "As they were when quitting" is not exactly mysterious: it's the set of tabs that were open when I went to the File menu and selected the "Quit" option. I can file a bug on my use case, I suppose, since it involves changing the privacy_level pref. > Closing the browser never logs you out of sites authenticating with cookies > (you already knew that) That's false for sites that use session cookies for authentication, in every single other browser. Closing the browser DOES in fact log you out of such sites in every other browser (including Firefox 2). > and sites saying otherwise should be evangelized to correct their wording I don't see why, since it's correct for every browser but Firefox 3. > most users actually expect tabs to be restored as is (including remaining > logged in) when setting Firefox to do so Straw poll around here suggests not, but I'm talking to people who actually know what "logged in" is, sort of, not typical users...
I filed bug 477605 on my Bugzilla dataloss issues, so we can focus this bug on the behavior with the default privacy_level setting. One other note.... if you expect that users remember what the wording was in the dialog, you're being silly. All they remember (again, based on straw poll of people around here) is that they want to see the tabs they had open when they quit.
(In reply to comment #16) > Do you want minefield to save your tabs for the next time it starts? > There is no indication that logins are going to be saved. So we don't agree what a "tab" is - just its URL or as much of its content as possible. In my understanding, a session consists of all open tabs, but apparently that's not completely obvious. Of course, it is quite unfortunate that we actually DO throw away large bits of https tabs... Mike: Should the wording in the Quit prompt be adjusted? > Closing the browser DOES in fact log you out of such > sites in every other browser (including Firefox 2). What I meant was: All those browsers do is throw away your cookie so that you can't get in again, but until the server throws away your server-side session after a timeout of up to several hours you DO remain logged in (as in: somebody intercepting your cookie can happily continue using it).
The original bug about saving session cookies in session restore in general is bug 345345. This bug, at least in my eyes, was filed as a suggested compromise, specifically about the behavior when you select "Save and Quit" from the dialog (see comment 5). I don't think most people can (or want to) distinguish between "the set of URLs that were loaded" and "the credentials required for viewing those URLs as they were when you loaded them", and it's not clear to me that trying to cater to non-HTTPS sites that rely on session cookies expiring for security is worth the usability costs.
> So we don't agree what a "tab" is - just its URL or as much of its content as > possible. More of the latter, but in my mind "tab" doesn't necessarily include "everything I've ever browsed in this tab", in the context of quitting the browser. It _does_ for crashes, of course. > (as in: somebody intercepting your cookie can happily continue using it). Yes; that's where SSL comes in, no? I realize that the SSL issue is somewhat distinct, hence the separate bug on that.
>Expected Results: >Gmail account should be blocked until Login. I disagree with this premise, similar Gavin. I think in the user's mind (which is contains only a very simplistic abstraction of reality), the tab is the thing they were doing/using/viewing. So "Save" should mean Save in this broader context, since that is what they think it is going to mean.
Hi, I'm a developper of a single sign on application. And this bug causes password bypass on independent applications. e.g. 1. Login to application on site A using site B's SSO(OpenID, etc.) 2. Close Firefox 3. Start Firefox and access to application on site C using site B's SSO Result: You can login site C application without authentication because site B's SSO session cookie remains in firefox. I have checked on some OpenID site and Shibboleth application(that I'm just developping). So I think this bug should be fixed. Thanks.
Hi, I'm a WEB developer, I just hit the same issue. On my site I need user to be logged out after he closes the browser. Even if he want's to save the session - I don't wan't him to do that. The same reason internet banking closes your session on timeout and generates cookies with different names. So, with this bug (it's a bug for sure) I'm forced to generate random cookie names for now and that will lead to cookies being multiplying on user side. Second bad thing about it, you log in into your site, then close FF and go away. Someone (wife, kids) walks to computer and starts FF - he is still logged in. So if user haven't logged out and server side timeout haven't passed - you can get the access. I consider that really bad. If I really need to logout the user - I have to set really short timeout for session expiration on server side, something like 30-40 seconds (I have AJAX call's every 5 seconds, so I can do that). Same as Hideki Sakamoto: this should be fixed. Just destroy the cookies on clean shutdown, that way after crash or update you could restore all sessions properly.
I agree with comments #4, comment #6, comment #19 and others, the user is expecting to save the session in its entirety, which includes things like being logged into an account. I think if we were to reverse this decision far more people would complain because of the convenience lost compared to the current fraction of users complaining. On an only partially related note, many of the Web applications that lock you out after a certain amount of time (like for instance my Zimbra calendar) tend to be running directly next to local applications that contain similar types of data, but have no authentication. In my opinion this is mostly just holding Web applications back from being able to effectively replace desktop apps, and a lot of Web developers need to evaluate the logic and actual usability cost of constantly locking their users out.
(In reply to comment #23) > Hi, > > I'm a WEB developer, I just hit the same issue. > On my site I need user to be logged out after he closes the browser. Even if he > want's to save the session - I don't wan't him to do that. This issue you're referring to will never be solved, because there are extensions that allow people to push the timeout of session cookies to years away, and force them to not be deleted.
At the very least can we get rid of the sessions saved for sites with no open tabs? (In reply to comment #24) > I agree with comments #4, comment #6, comment #19 and others, the user is > expecting to save the session in its entirety, which includes things like being > logged into an account. I think if we were to reverse this decision far more > people would complain because of the convenience lost compared to the current > fraction of users complaining. Except the users whining about convenience are not considering the security implications of that convenience. Once they get hacked because they shared a computer and it remembered their sessions -- even though it doesn't say it will if you've made that the default behavior, even if the user isn't normally a Firefox user and has no clue this might be the case -- they're not going to remember how kindly you served their convenience.
>At the very least can we get rid of the sessions saved for sites with no open >tabs? That seems to be a more reasonable balance between security and convenience.
(In reply to comment #25) > This issue you're referring to will never be solved, because there are > extensions that allow people to push the timeout of session cookies to years > away, and force them to not be deleted. Oh, Really? That sounds "A security hole of session fixation with malicious extensions" for me. And I think that behavior should be fixed by developer of that extension. Furthermore, I think changing any attribute(timeout, value, etc.) of a cookie by extensions have to be blocked by firefox. In other words, a cookie should not be changed by any 3rd party.
(In reply to comment #26) > At the very least can we get rid of the sessions saved for sites with no open > tabs? We already do that. If that's not what you see, please file a new bug. > even though it doesn't say it will if you've made that the default behavior, Why would you expect Firefox to tell you that it'll remember the whole session, if you've previously told it to always do so? Or do you mean that the wording for that very option isn't as clear as it could be? If so, please file a new bug as well.
from RFC 2109, section 4.3.1 Interpreting Set-Cookie > The user agent applies these defaults for optional attributes that are missing: > [..] > Max-Age The default behavior is to discard the cookie when the user agent exits. As a web developer, the only way for me to tell the browser that the cookie is valid until the browser exits, is to not set Max-Age. There is no other way to do it because I have no idea how long the user will keep his browser open. So if Firefox saves those cookies, it is a bug, not a feature.
Agree completely with comment 30. The current situation is a security risk, and very irritating for session-testing as a webdeveloper. It should be the responsibility of a website to keep the current session by using a Max-Age... just as GMail for example is doing: When logging in the user has to tick the "keep session" option. That works fine enough! So, all on-browser-close-expire-cookies should be deleted on browser close. As a user I would NOT expect the session to stay on browser close... when I click log-out I expect a total and save logout, and thus a deletion of the sessioncookie.
See also bug 530594, which suggests capping the lifetime of session cookies.
13 years ago
Duplicate of this bug: 542688
There are two primary kinds of cookies for good reason: persistent and session. The only significant difference between them is whether they get cleared at browser close. This is a core characteristic of the security contract that defines authentication via cookies that should not be messed with lightly. I recommend doing a quick search for "difference between persistent and session cookies." This feature fundamentally redefines all cookies as persistent cookies. Its the job of the web developers make this security vs UX decision not ours; they can always use persistent cookies if they want the session to survive browser restart (modulo user's cookie settings). This has serious implications for privacy as well. Even if the user has disabled persistent cookies you can now use session cookies for persistent tracking of users across browsing sessions via web bugs.
Lucas: would it help if we differentiated between a quick restart (like an immediate crash recovery, or an extension install) versus a restart that is occurring considerably after the user closed Firefox?
In Bug 551191 that is marked as duplicate of this one I have tested both immediate and long time restart (like after 24h+ including system shutdown). Both give the same results - session cookie is not deleted.
Alex, re comment 36, I don't know how you would do that. Even if you limited it to 1 minute, a user should be assured that as soon as they shutdown, or "quick restart" their browser, their session is history. Likewise, the web developer expects the same result. I don't see where the standard allows an option about how to handle this.
(In reply to comment #38) > Alex, re comment 36, > I don't know how you would do that. Even if you limited it to 1 minute, a user > should be assured that as soon as they shutdown, or "quick restart" their > browser, their session is history. Likewise, the web developer expects the same > result. > I don't see where the standard allows an option about how to handle this. Just to extend that comment - I do like the reopen the tab concept, it's just the session I have trouble with. This may not always work without the session, but just let the user log in again, where possible.
>a user should be assured that as soon as they shutdown, or "quick restart" their >browser, their session is history. I agree, but if the user was in the extension manager and hit the "Restart Firefox" button, they might not be ready to experience any data loss, and they aren't going to view this as a real "shutdown" (although it is in the technical sense). The same goes for a crash when Firefox automatically restarts and restores. They didn't even ask for the browser to shutdown in that case, and moments later they are back running again. In both of these cases it seems like we are looking at a restart and not a shutdown, and intentionally failing to restore the session isn't in line with the user's intention.
(In reply to comment #40) > ... intentionally failing > to restore the session isn't in line with the user's intention. I think that's irrelevant - at least here. Firefox should be correctly implementing the standard, and to me, this behavior violates the standard - which is what I expect as a developer and website owner. Whatever the merits of your arguement, they should be made toward a change in the standard, not to us here to just ignore a standard. (I'm not arguing with your point, and I don't really have a view on it. I just think this is the wrong place to achieve what you want).
(In reply to comment #36) > Lucas: would it help if we differentiated between a quick restart (like an > immediate crash recovery, or an extension install) versus a restart that is > occurring considerably after the user closed Firefox? Alex: yes, this bug is strictly about the case where the use is explicitly shutting down the browser, not about crash-recovery or the fact that we lack the ability to upgrade on the fly (see comment 1). People who want session-restore to never store session data (cookies/forms) under any circumstances can accomplish that with an existing about:config pref, and can argue elsewhere about changing that default (good luck with that) or exposing UI for it. (In reply to comment #41) > Firefox should be correctly implementing the standard, and to me, this > behavior violates the standard - which is what I expect as a developer > and website owner. Fair point, rfc 2109 says that without an explicit Max-age expiry time "The default behavior is to discard the cookie when the user agent exits." That's certainly the expectation of web site developers. But by describing it as the "default" behavior it implies other behaviors might be acceptable. Otherwise the spec would have said "MUST discard"; it doesn't even say "SHOULD". > Whatever the merits of your arguement, they should be made toward a change in > the standard, not to us here to just ignore a standard. The standards /are/ changing. RFC 2109 from 1997 never quite matched actual behavior which developed over time as browsers reverse-engineered what each other were doing and what was required to avoid breaking major web sites that weren't following the standard. An updated cookie spec is in the works and has different language around session cookies. When "the current session is over" (as defined by the user agent), the user agent MUST remove from the cookie store all cookies with the persistent-flag set to false. http://www.ietf.org/id/draft-ietf-httpstate-cookie-05.txt Our current behavior is therefore perfectly compliant, but it's still a bad idea to violate long held expectations of web-app developers.
Sorry to barge in like that... I have a question and I think that people here could point out this problem with the session engine. I've been using 3.5.9 till 3.6.4 cam out and I had this nasty behavior of Firefox which cause problems: the sessionstore.js file would not clear, even if there were no tabs open (just the one blank tab) before closing the browser. And I didn't know what was wrong. Now after I upgraded to 3.6.4 the first thing was to see if it was fixed... and wow, it was! Every time I would close Firefox in a clean state, the file sessionstore.js would be deleted. The joy ended when I closed it with some tabs open and it asked me to "Save and Quit", which I accepted since I planned to view those sited when I started the browser. Now, every time I close Firefox in a clean state, the file sessionstore.js remains, grows and sometimes the nasty window appears at start up which says something went wrong during saving session and I would have to restore the last session or make a new one.
Using php and the session_set_cookie_params(0) parameter, this should tell the browser to clear the session/cookie when the browser closes. This does not work as it should in Firefox, but works in ever other browser. Is this bug going to be addressed soon?
With Gmail when one has enabled "Grant access to your account:" to allow gmail account #1 to access gmail account #2, Firefox 3.6.13 properly prompts user for login credientials for gmail account #1 when the browser is shutdown and restarted a few minutes later. In Firefox 4b8 upon restarting the browser still allows connection to gmail account #1 and in turn access to gmail acct #2.
In bug 424872 we changed the prefs even further to enable restoring from HTTPS pages. Saving session cookies is an feature of our session restore. For most people, restoring session cookies is associated with restoring a browsing session (even if most people don't know what a cookie is). 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). If the cookie spec changes and we "MUST" discard session cookies, we can deal with that then. And/or we add UI to allow an easier override. But those should both be done elsewhere.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Whiteboard: [sg:want P2][wontfix?] → [sg:want P2]
I can understand your point of view in restoring sessions. However, you should reword the cookie settings dialog. When Firefox promises to "Keep cookies until: I close Firefox" I'd consider it a bug if it keeps them for longer. There should be another wording (or an explanatory sentence below the drop-down box) that cookies will be kept, when "remembering tabs".
I think this bug really comes down to the difference in opinions about when a session has ended - when the browser has closed (as per other browsers, and when the general population assumes it has ended), or when all the tabs of any site that set session cookies have been closed, and then browser has been closed (as per Firefox, if the user has selected 'Show my windows and tabs from last time'). This is different to restoring sessions after a crash (which is infrequent, but a good thing), and not a request for an advanced option to disable keeping sessions between restarts for security reasons. The general public won't change such settings and would leave their browser behaving in a non-standard way (compared to how other browsers handle session cookies, and even Firefox with different settings). This bug is about Firefox not adhering to heuristic standards. Firefox configured to 'Show my windows and tabs from last time' in may cases does not adhere to the instructions given by the site setting session cookies. That is a bug.
This is a really old bug. Nils and Martin, if you feel it warrants further discussion and investigation in relation to the latest version of Firefox please file a new bug report to that effect. Thanks
I disagree with comment 51. Filing a dup of a WONTFIX bug isn't the right approach. Comment 49, on the other hand, would be a good bug report on its own.
Thanks Anthony, but this bug has had regular discussion since opening and I was thinking along the same lines as Jesse in comment 52, re filing a new bug. I wanted to raise the issue again along the lines of comment 34 and the site owners/developers perspective. From the user's perspective - "Show my windows and tabs from last time" has a different meaning to - "Show my windows and tabs from last time, and keep the sessions for any domain I still have open active if possible. I understand that this is a non-standard feature unique to Firefox, similar to doing a full session restore each time I restart, and not just remembering the URLs I had open. Some site sites may not function as the creator expected." Users who choose to remember tabs with this setting are unintentionally causing Firefox to handle session cookies differently to any other site visitor, and it may also impact that users security/privacy. From the site owners/developers perspective - This non-standard interpretation of session-cookies could affect the web sites logic in determining new and active sessions, as it differs to all other browsers - including a Firefox visitor with different settings. A feature for remembering tab and window locations shouldn't override the cookie settings intentionally and thoughtfully specified by the site creator. Should developers deal with this unusual scenario by not relying on session cookies to expire, and only ever use short-duration persistent cookies? See the following detail about how Google Analytics tracks sessions/visits. GA sets both a session cookie (__utmc) and a 30 minute persistent cookie (__utmb) - probably to allow for the differences in session end time that this bug causes. See the first bullet point - http://www.google.com/support/analyticshelp/bin/answer.py?answer=1006241&topic=1006224
(In reply to Nils from comment #53) > Thanks Anthony, but this bug has had regular discussion since opening and I > was thinking along the same lines as Jesse in comment 52, re filing a new > bug. Right, so can you file a new bug on this?
This is a MAJOR security issue and our company has been reporting this to all major banks and highly secured websites that Firefox (7.0.1) as we speak is the ONLY browser with such behavior. ---->Reproduction: 1) Firefox->Tools->Options Startup When Firefox Starts: Show my windows and tabs from where last time. 2) Login in to your Bank Account Say you have 3 more tabs (sites) open The phone rings and you must leave in a hurry. Your ALWAYS quickest options is to hit the browsers close button. You think is all good and leave. 3) Someone else, says your wife's cousin that hates you very much steps in and requests her to use your computer 4 min just after your have left stating that he needs to check on something. Opens Firefox All the previous sites and sessions are restored. Here sites are ok, just like other browsers, but SESSIONS should NEVER, EVER be restored. Now that nasty cousin sees all about your bank account and may take a few "dimes" for himself. Now Seriously.... non computer savvy people will do exactly as above and and risk their privacy and more. Besides all the above, another issue due to this behavior (holding session cookie ID persistently) when using programming languages such as PHP and session stored in DB, FIREFOX is the only browser that makes session_regenerate_id(TRUE) a failure, by not deleting older session, not regenerating session ID and not recreating the session at all. Anyway... for us it does not matter because we can quickly stop all our customers to use secure sites until a browser becomes free from security threats, they switch browsers, not sure if they will come back to firefox thou... shame, it's always been a great browser. As soon as we see this bug fixed we will communicate to all our partners and report the fix as a safety measure. Thank you!
Yes, that's the nature of this bug report, and I see no new information in your comment that would cause it to be re-opened. A more realistic problem isn't the case of the "nasty cousin," but the settings being applied on a public Internet connected terminal, honestly. Nothing mentioned here overrides comment 20 or comment 48. The default behaviour is not to save sessions on shut down, that's something we allow our users to choose. I would recommend - if you truly are a fan of Firefox - that you recommend users do not set that option or sign out of your website explicitly, not that they use another browser.
For clarity in the 'When Firefox starts:' dropdown - How about changing - 'Show my windows and tabs from last time' to something like - 'Restore my last browsing session, including all cookies from the session' And/or adding a new option that doesn't retain session cookies (for the security conscious, and developers doing testing) - 'Restore my window and tab locations only. Allow sites to forget my last session'
Those should be filed as separate bugs, not as a comment on a WONTFIXED item.
I'm a standard user. Recently realised that my cookies weren't being deleted as I expected and was dismayed. I found this bug from here http://support.mozilla.com/en-US/questions/675906 I've created an account on this site just to say the following: The sort of user who works out how to edit their preferences for cookies to "keep until I close firefox" is expecting their cookies to be deleted when they close firefox. I've followed the workaround described in comment 48 -- but such basic functionality shouldn't involve use of the about:config. I've submitted a new bug along the lines of comment 49: https://bugzilla.mozilla.org/show_bug.cgi?id=697684 . As I said I'm entirely new to this site so please be patient if I've set it up wrong.
(In reply to Martin from comment #49) > I can understand your point of view in restoring sessions. However, you > should reword the cookie settings dialog. When Firefox promises to "Keep > cookies until: I close Firefox" I'd consider it a bug if it keeps them for > longer. There should be another wording (or an explanatory sentence below > the drop-down box) that cookies will be kept, when "remembering tabs". See bug 401187.
10 years ago
Duplicate of this bug: 729066
I have created bug 794253 in order to get this serious privacy issue resolved.
http://zpao.com/posts/restore-previous-session/ Set both settings to 2; It works for me.
Sure, see comment 48. However, that's a work around. This bug is about getting the problem fixed in Firefox.
EFF posted to their blog steps to configure Firefox to reduce online tracking (https://www.eff.org/deeplinks/2012/04/4-simple-changes-protect-your-privacy-online) but even they got it wrong. I followed all their guidance including setting the preference to keep cookies until "I close Firefox." But it wasn't working, and I didn't figure out why until today when I had to look into this as part of my job. This behavior runs totally contrary to user expectations, and if it's even fooling the main Internet privacy advocates, there's a serious problem. I have made the browser.sessionstore changes per Comment 48, but that should at least be default behavior as part of making the change to keep cookies "Until I close Firefox."
Hi Ben, thanks for pointing this out. I have emailed the author about the problem and its workaround so that it will hopefully appear somewhere along with the article.
*It's not a bug, it's a feature.* Alex and Paul are right. > when I > click log-out I expect a total and save logout, and thus a deletion of the > sessioncookie. When you click "Log out", sure, the cookie gets deleted. But here we are in the case where I did not click "Log out". On the contrary, I clicked "Remember" in the first place. So I expect Firefox to... remember. Contrary to what some people suppose here, I am a counter-example, as I user I expect and want the whole session to be restored. Identifications, authentication, form data... everything. Even on HTTPS sites. Even on bank sites. See this discussion : http://security.stackexchange.com/questions/31937/firefoxs-restore-previous-session-restores-logins-authenticated-by-servers-ses In terms of usability and data loss, computers apps, including Firefox, are still far behind the paper and pen. Firefox' move to improve that situation is good for the users, no matter what the other Web browsers do or don't do (yet). Think about what Apple brought in Mac OS X Mountain Lion : Mac apps are now supposed to be *stateful*. Like on the iPad. The user is no longer supposed to quit nor to launch apps. Apple's guidelines for developers now recommend Mac apps to remember and restore their whole state, in order to make quit and relaunch invisible to the user. Regarding the privacy implications, the place to go 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 to something much more general, like "Clear personal data" or "Clear navigation data".
Yep I have a doubt are the banks doing such dumb things of keeping session idle for more than minutes?
(In reply to Nicolas Barbulesco from comment #72) > *It's not a bug, it's a feature.* Then, it is a badly implemented "feature": I am using the german localization and I have selected: "keep cookies until Firefox is closed" ("behalten, bis Firefox geschlossen wird)-- but Firefox closing at system shutdown does not delete the cookies. In contrast, HTTP/HTTPS authentication is lost for this kind of (automatic) closing. > .... > Contrary to what some people suppose here, I am a counter-example, as I user > I expect and want the whole session to be restored. Identifications, > authentication, form data... everything. Even on HTTPS sites. Even on bank > sites. Thus, you, too, should be dissatified with the current state: while cookies are restored, HTTP/HTTPS authentication is not. It would not be that difficult to get all users satisfied: * provide an additional option "until Firefox is terminated" (which includes automatic "closing"). Then, people who do not want session cookies to be kept indefinitely (like me) can use this option * describe clearly what "until Firefox is closed" means (and that is does not include automatic closing). Then people (like me) are not surprised that session cookies live in fact indefinitely.
(In reply to Nicolas Barbulesco from comment #72) > *It's not a bug, it's a feature.* No matter how you call it, its a bug for most users and thats why it should be fixed and not reworded.
People, I posted on this one year ago. You know what? give up, just do like I do, motivate your customers to permanently switch to Chrome or something safer. Look at the statistics, Every month it loses preference anyway. http://www.w3schools.com/browsers/browsers_stats.asp. "The INTERNET of the people, by the people, for the people, shall not perish by the minds of a small group of knuckleheads". Status: VERIFIED ABANDONWARE
WHY this unsecurity issue still not fixed?! Terrible situation.
(In reply to Konstantin from comment #77) > WHY this unsecurity issue still not fixed?! Terrible situation. We will not be fixing this issue, see comment 48 for the reasoning. If you disagree with this decision please start a discussion on the dev-platform mailing list.
When you look up the definition of a session cookie, it says a cookie that is stored in memory and terminates when the user agent closes. Yes, in the spec, it might say SHOULD instead of MUST. And you are saying that opening up a HUGE security hole is worth it why? So that a user can click "History -> Restore Previous Session"? Normal users dont know about that feature, but hackers do. Normal users close a browser, open it up, see a login screen, and think they are logged out. This is a really bad false sense of security. If a server wanted you logged in longer, then it wouldnt use a session cookie! Please reconsider fixing this issue. By default a session cookie should last for a browser's session. Oh wait, I said should. By default a session cookie must last for a browser's session. :) THANKS!
BTW, the way I read comment 48, is the FF team is saying that the cookie spec says you dont have to delete session cookies when the browser is exited. "MUST". But when I read it, I think it does say that. "3.3.1 The user agent applies these defaults for optional attributes that are missing: Discard The default behavior is dictated by the presence or absence of a Max-Age attribute. Max-Age The default behavior is to discard the cookie when the user agent exits." So by default (without making any changes to the browsers settings), cookies are discarded when the user agent exits. I think FF is not following the spec in this regard. There is also the "Discard" flag on cookies. The spec says "The Discard attribute instructs the user agent to discard the cookie unconditionally when the user agent terminates." I tried using the Discard flag and firefox restores those too when restoring session. That seems contrary to the spec as well. Thanks, Chris
I reported this 5 years ago. Since then it's been debated over and over again and most people think, as me, that this is a security risk. I'm not a developer, I'm a tester, so I can't fix the problem. Can someone please take the initiative and fix this already?
> And you are saying that opening up a HUGE security hole is worth it why? > So that a user can click "History -> Restore Previous Session"? I agree with you for the specific case of a clean, user-initiated shutdown when the user has not selected "When Firefox starts: Show my tabs and windows and tabs from last time". Please file a bug if Firefox isn't getting it right in that case. The other cases are: * Restarts to install updates or extensions (where it's much more important to make security updates smooth than to maintain the illusion that process lifetime has anything to do with what users consider a "session") * Crashes * Pre-planned tab restoration (still controversial, with lots of room for clever heuristics; see bug 529899 and bug 530594).
Thanks for agreeing. I dont think opening a new bug will help. There are tons of bugs about this, e.g. the one we are commenting on, and this one https://bugzilla.mozilla.org/show_bug.cgi?id=530594 If you are on the bugzilla team, can you PLEASE reopen one of these and assign them for someone to fix. This is a serious problem. If you still want me to open a new bug I will. Thanks
Opening bugs on specific cases definitely helps, especially if they're uncontroversial cases. Patches fixing those cases don't happen in bugs that are full of people talking past each other.
ok, I opened this bug, if there is more information needed, please add. If you can assign to a developer, that would be great. https://bugzilla.mozilla.org/show_bug.cgi?id=879496 Thanks
You need to log in before you can comment on or make changes to this bug.