User-Agent: Opera/9.24 (Windows NT 5.1; U; en)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20071008 Firefox/188.8.131.52
When I use firefox to login web site like gmail or on-line bank, I find that if I close firefox without logout, then reopen firefox, firefox will remains the login state, cookies won't be deleted. This happens when firefox starts "Show my windows and tabs from last time", but I choose to keep cookie until "I close Firefox".
Steps to Reproduce:
1. open Options, in Main tab, set "When Firefox starts" to "Show My Windows and tabs from last time"
2. open Options, in Privacy tab, check "Accept cookies from sites" then set "Keep until" to "I close Firefox"
3. open Options, in Privacy tab, check "Always clear my private data when I close Firefox", and open it's seetings to uncheck "Cookies"
4. After login to web site like gmail (or similar web sites), close Firefox directly without logout.
5. Reopen Firefox, web site remains login.
After restart Firefox, the web site will keep the state of login, so anyone can get my private data from the site without knowing my auth infomation.
After restart Firefox, Firefox should clear these session cookies to protect user's privacy.
This sounds like bug 345345. In your step 4, what exactly do you mean by "close
Firefox directly"? Close firefox normally, with File > Exit or the [x] at the
top right of the browser window? Or close firefox by killing the process?
Sort of like bug 345345, but there's really two cases and the other bug doesn't distinguish them very well (although this bug's aspect is mentioned, bug 345345 comment 18). Since I doubt we'd ever drop session cookies after a crash maybe that other bug is now about the non-crash case, but if so the summary needs to clarify that.
Simon? There seem to be a lot of people in the "OK to restore cookies after a crash, not so much with the 'show tabs from last time' non-crash" camp. Can we add a privacy level or extra pref to control that?
(In reply to comment #2)
> Can we add a privacy level or extra pref to control that?
Technically, that wouldn't be much of an issue. I still don't understand the use case, though:
Why would we want to save session cookies at all times except at shutdown? Are there well founded privacy concerns, or is it just for a cozy feeling? I.e. would this restriction only apply to cookies, or to form data, POSTDATA, DOM Session Storage, etc. as well? Would we have to remove the cookies, etc. at shutdown or could we just not re-set them at startup? Would we have to make sure to delete sessionstore.bak as well (which contains the cookies from the last crash), just remove cookie data from it, or not touch it at all? Or would it be sufficient to point these people to an extension which customizes SessionStore more than we do by default (which should already be possible for this specific request)?
Steps to Reproduce:
4. After login to web site like gmail (or similar web sites), click menu [File]->[Exit] to exit Firefox. (or the [X] is also the same.)
My point is, I choose to keep cookie until "I close Firefox" in [Options]->[Privacy]. Unless this setting has exception, or it doesn't mean that it will clear cookies after I close Firefox, then it should clear these cookies after I close Firefox. But the result is opposite, Firefox keeps there cookies after it restarts.
(In reply to comment #4)
> I choose to keep cookie until "I close Firefox" in [Options]->[Privacy].
So, we have a potential UI inconsistency between "Show my windows and tabs from last time" for which having cookies around improves the experience and keeping cookies until "I close Firefox" which implies that we don't.
Internally, this works out because the cookie setting makes us treat all cookies as _session_ cookies and the startup setting acts as _session_ resuming.
IMO we should just reword the "I close Firefox" bit to clear things up, because if this was a privacy issue, we'd probably have to clear out further SessionStore data (form text data, POSTDATA, maybe even URL queries) and include the option at a different place (e.g. as an "Don't save any sensitive data for session resuming" option in Options -> Privacy -> Private Data).
*** Bug 410059 has been marked as a duplicate of this bug. ***
OK, so surprise surprise, despite the fact that Firefox clearly doesn't do what you tell it to (keep cookies until I close Firefox -> close Firefox -> cookies remain), there is a mix of apathy and complication of the issue (comment #3). Incidentally, this affects the 'clear private data on exit' option too.
There are two solutions:
- actually do what the user asks (don't save cookies as part of the session)
- change the text of the option (keep cookies until I end my session - how that would happen I have no idea...)
Meanwhile, while people argue over this, here's how to get Firefox to save sessions and delete cookies when you exit:
- tell FF to start with a blank page, and keep cookies until exit
- install session manager
- set it to at startup always load -> select session -> previous browsing session
- under saving and restoring, uncheck 'save session cookies'
duping forward as the other bug seems to have more visibility
*** This bug has been marked as a duplicate of bug 443354 ***
Repopening: bug 443354 is wontfix, this bug was morphed and is now about rewording the "Keep [cookies] until: I close Firefox" setting, which was generally agreed upon in 443354.
*** Bug 794253 has been marked as a duplicate of this bug. ***
Rewording is not generally agreed on. It was an idea of a minority.
Moreover, it is the wrong approach to this problem.
The user wants to have cookies deleted on exit as clearly stated by the option.
This is a very reasonable and important privacy option which should be respected as such with highest priority.
Bug 794253 clearly summarizes the conflict and a proper solution, i.e. only the URL of the last pages visited should be restored, but not the full session.
A session restoration would only be beneficial for a small group of users, who really know what they are doing.
This is extraordinarily simple. It is a bug, a new one, that has nothing to do with wording, and nothing to do with restoring sessions after a crash.
If you check Accept cookies from sites and select Keep until I close Firefox, it used to do precisely what it was supposed to do, i.e. it used to delete all cookies on closing Firefox normally.
It has stopped working. Now, it does not to what it is supposed to do, i.e. it does not delete any cookies on closing Firefox normally (as I say, nothing to do with crashes, nothing to do with restoring sessions).
This is a bug. Worse, it is a serious privacy concern, for me, at least. I won't be using Firefox until it is fixed, because it has already caused me problems (I closed Firefox, assumed I was logged out of Google, then, hours later, I opened Firefox again, and found that Google was tracking me, because Firefox had failed to delete the cookies when I closed it.)
The following option also does not work:
1. In the Privacy options, check Clear history when Firefox closes, click Settings, check Cookies, uncheck all others.
2. Close Firefox normally by clicking the [X] button.
3. Open Firefox.
None of the cookies have been cleared.
If we're unwilling to fix these bugs, we should _remove_ the options to clear cookies when Firefox closes, because it's wrong to promise the user we'll do something (especially something so privacy-critical) then not do it.
OK, this is now working again for me. Perhaps, after all, Firefox was failing to shut down properly, though there was no indication that it had crashed.
Just found this bug and a work-around googling for the issue. The work-around for the issue outlined in the original bug description is here: https://support.mozilla.org/en-US/questions/961175
I.e. set browser.sessionstore.privacy_level to 2. Works for me.
Although, I personally still see the issue in the original bug description as an issue, especially as the cookies don't get removed when both:
- "Keep [cookies] until: I close Firefox" is used AND
- "Clear history when Firefox closes" is activated AND the "Cookies" checkbox is activated under the "Settings" button on the right of it (among many other checkboxes, which work correctly though, unlike the cookies).
(Side note: Also, the reason for existence of the "Cookies" checkbox is not clear, given the existence of the "Keep [cookies] until: I close Firefox" option. Why the double configuration? Here is a UI simplification possibility Mozilla seem to be eagerly searching for recently.)
I think that goes against user expectations. I think the options should not be re-worded, but followed - i.e. the cookies deleted.
Maybe a simple solution would be setting the *default value* of browser.sessionstore.privacy_level (and possibly also of browser.sessionstore.privacy_level_deferred) to 2? But only if it doesn't interfere with the more typical use case: keeping the cookies when "Keep [cookies] until: I close Firefox" and "Clear history when Firefox closes" are not activated. Looking at parameter description it seems it wouldn't interfere, as session storage seems to be de-coupled from the regular cookie storage. Making the issue described in this bug report just an issue of incorrectly chosen default values for the above parameters.
(In reply to Joe Smith from comment #15)
> [...] session storage seems to be de-coupled from the regular cookie
> storage. Making the issue described in this bug report just an issue of
> incorrectly chosen default values for the above parameters.
I meant that:
- The "regular" cookie handling works correctly - they are deleted when configured.
- With the current default values, the cookies saved in the session storage do not follow the "regular" cookie configuration. Which is counter-intuitive.
- With browser.sessionstore.privacy_level and browser.sessionstore.privacy_level_deferred set to 2, the cookies would not be saved in sessions. So that the "regular" cookie handling will apply for the tabs saved in sessions - i.e. their cookies will come from the "regular" cookie storage (or not - if deleted).
Is that correct?
Bug 529899 is the one with a patch
*** This bug has been marked as a duplicate of bug 529899 ***