Closed Bug 636399 Opened 14 years ago Closed 12 years ago

Session cookies for App Tabs should be deleted on exit if specified in privacy preferences

Categories

(Firefox :: Session Restore, defect)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 345345
Tracking Status
blocking2.0 --- .x+

People

(Reporter: whackster, Unassigned)

References

Details

(Whiteboard: [mozmill-test-needed][4b12])

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre Log in some site, then pin it as an app tab, restart the browser - the site is still logged in... Tried clearing cache on exit, disabled password manager still the same unwanted behavior. Reproducible: Always Steps to Reproduce: 1.Log in some site (eg. gmail) 2.Pin as App tab 3.restart browser 4.still logged in Actual Results: On browser start the App tab still saves the logon data. Expected Results: Clear logon data, refresh the log in page
Component: Tabbed Browser → Session Restore
QA Contact: tabbed.browser → session.restore
Do you store cookies? That's the reason why you are getting automatically logged in after the next restart.
(In reply to comment #1) > Do you store cookies? That's the reason why you are getting automatically > logged in after the next restart. Tried all the settings, no cookies, keep untill I close firefox, the App Tabs simply save the log in data no matter what.
Ok, so I'm able to reproduce this behavior with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre ID:20110222191823 As it turns out even with the setting enabled to remove all cookies on exit we don't remove any of the stored cookies. Users would have to do that manually to keep their privacy. That's kinda a major even critical issue for shared computers. This is a regression from Firefox 3.6, and sounds like that important to fix for Firefox 4 final. Requesting blocking. Also I will check for a regression range. That's a situation which could have been caught by a Mozmill test.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: in-litmus?
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: [mozmill-test-needed][4b12]
Summary: Pinned tabs save login data across sessions → Cookies are not deleted anymore on exit even if specified in preferences
This has been regressed between beta 6 and beta 7. I will search for the daily window now.
Regressed between the builds 10100803 and 10100903. PASS: http://hg.mozilla.org/mozilla-central/rev/b36eeab1df8b FAIL: http://hg.mozilla.org/mozilla-central/rev/d45c87e58110 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b36eeab1df8b&tochange=d45c87e58110 For now I would suspect bug 424872 has been caused this regression. I will run a local test to verify.
Ok, so this issue has been introduced by the preferences changes on bug 424872. 1.12 -pref("browser.sessionstore.privacy_level", 1); 1.13 +pref("browser.sessionstore.privacy_level", 0); 1.14 // the same as browser.sessionstore.privacy_level, but for saving deferred session data 1.15 -pref("browser.sessionstore.privacy_level_deferred", 2); 1.16 +pref("browser.sessionstore.privacy_level_deferred", 0); Setting the preferences to the old values everything is fine. Even if we have this problem with cookies for a while we have updated the default values with the above change. So all users of Firefox 4 who haven't changed the value are affected.
Blocks: 424872
Ok so cookies are getting deleted, at least what the cookie dialog tells me. But it looks the session cookies are stored somewhere else and are not deleted after a restart. That would allow others to use a formerly session i.e. from Gmail.
Summary: Cookies are not deleted anymore on exit even if specified in preferences → Session cookies are not deleted on exit even if specified in preferences
I'm not sure where this falls in relation to other privacy issues, but if we claim to be clearing a cookie and we're not, we should at least evaluate this for Firefox 4 blocking.
blocking2.0: --- → ?
Hm, browser.sessionstore.privacy_level_deferred was changed to 1 in bug 627472, which should (as per bug 627472 comment 5) clear session cookies on shutdown. If the browser is being restarted or the session is stored, though, the cookies will be kept. Paul: is this because we now always save sessions so they can be restored on the next start? Whimboo: I'm assuming the STR you're using are: 1. Login to gmail (do not check "always remember me") 2. Quit Firefox 3. Start Firefox (do not restore session) 4. Go to gmail Expected: have to login Actual: are already logged in
Assignee: nobody → paul
The right steps to reproduce it are: 1. Start Firefox with a clean or a Firefox 3.6 profile 2. Go to "preferences | privacy" and select "keep cookies until I close Firefox" 3. Open Gmail into a tab 4. Restart After step 4 you will be still logged into Gmail.
Don't forget to pin gmail as an App Tab. I guess it has something to go with keeping App Tabs across sessions - the page seems to reload, but the cookie is kept so you get logged in right away. Again, this only happens with App Tabs and not with regular tabs.
App tabs always use browser.sessionstore.privacy_level, even when not restoring the rest of your session (this was done in bug 588482 when we did the whole deferred session restore thing). Other tabs would be using privacy_level_deferred if we won't restore at startup. This isn't really a regression. From the beginning of app tabs we were saving session cookies, though only for HTTP. The change Henrik points to just changed that we'd save HTTPS session cookies (that's why using gmail as your test case "regresses") Is this not about app tabs anymore? Regardless, we didn't clear cookies from sessionstore in 3.6 if that prefs > privacy setting was selected. The only difference is what privacy_level of cookies we keep.
Keywords: regression
Sorry, but this is not app tabs only! In my steps I have forgotten an important step to make this behavior also appear in normal tabs: 1. Start Firefox with a clean or a Firefox 3.6 profile 2. Go to "preferences | privacy" and select "keep cookies until I close Firefox" 3. Set When Minefield starts open windows and tabs from last time 4. Open Gmail into a tab 5. Restart
Blocking, but I actually think that this is INVALID as Whimboo and the reporter are saying different things. If it's just for App Tabs, then it's INVALID and as designed. If it's happening to all tabs, then it's a problem and should be fixed. Whimboo: you're sure that you're not set to be "Always logged in on that machine"? Can you try on a banking site instead of GMail? They're a little more sure to use session-scoped cookies (sometimes GMail's session scope isn't so sessiony!)
blocking2.0: ? → final+
Whiteboard: [mozmill-test-needed][4b12] → [mozmill-test-needed][4b12][hardblocker]
(In reply to comment #13) > Sorry, but this is not app tabs only! In my steps I have forgotten an important > step to make this behavior also appear in normal tabs: > > 1. Start Firefox with a clean or a Firefox 3.6 profile > 2. Go to "preferences | privacy" and select "keep cookies until I close > Firefox" > 3. Set When Minefield starts open windows and tabs from last time > 4. Open Gmail into a tab > 5. Restart What do you mean by restart? I think beltzner was trying to clear this up, but this seems really important. Are you using a restart button in add-ons manager, are you going to file -> exit? I'd like to test this also, so clearing that up would be great!
(In reply to comment #14) > Whimboo: you're sure that you're not set to be "Always logged in on that > machine"? Yes, otherwise I would have explicitly mentioned this part. > Can you try on a banking site instead of GMail? They're a little more > sure to use session-scoped cookies (sometimes GMail's session scope isn't so > sessiony!) Same problem. If you do not logout before quitting the browser, the session cookie will persist and you will be still logged into the banking site after Firefox has been started again. (In reply to comment #15) > What do you mean by restart? I think beltzner was trying to clear this up, but > this seems really important. Are you using a restart button in add-ons manager, > are you going to file -> exit? Whatever way you want. It shouldn't make a difference.
Attached file test profile
This test profile can be used to raise the issue: 1. Extract zip file and create a new profile at the extracted location 2. Start Firefox with that profile 3. Change to the Gmail tab and login 4. Quit the browser (Cmd+Q/Alt+F4,...) 5. Start Firefox
(In reply to comment #14) > If it's just for App Tabs, then it's INVALID and as designed. Why are cookies treated differently by App Tabs? Should there be a separate setting on whether to keep cookies until browser is closed? I get the idea that App Tabs are kept across sessions, but also keeping the log in data (cookie) is a serious security breach. Especially when a setting to clear cookies already exists (and doesn't work).
WhACKO, can you please check my steps if you can reproduce it too? I think that would also need some clarification.
Henrik, The part that is unclear and (I think) making this a blocker is that Beltzner thinks you're restoring session on demand (eg, pressing restore previous session). What I suspect is actually happening is that you are restoring automatically at startup ("show windows & tabs from last time). Based on the profile you attached, you're using "show windows & tabs from last time" and so this is as expected.
Well, then I don't get the difference between removing all cookies via "Clear Recent History" and the preference via "Keep until: I close Minefield". Both result in a different behavior.
Henrik: Clear Recent History explicitly purges cookies up to a point. Clear on exit will clear when Firefox exits, but if the session is restored, then they are brought back to life. Since you always restore your session, they are always brought back to life. See bug 529644 for a related bug. WaCKO: I agree that if a user has stated that they want cookies to be deleted when Firefox exits we should even delete session cookies held by app tabs. I don't think I'd block the release on it, but we could take the fix if a patch comes along or in a stability release.
blocking2.0: final+ → .x+
Summary: Session cookies are not deleted on exit even if specified in preferences → Session cookies for App Tabs should be deleted on exit if specified in privacy preferences
Whiteboard: [mozmill-test-needed][4b12][hardblocker] → [mozmill-test-needed][4b12]
I have settings for both "Keep until: I close Firefox" and also "Clear history when Firefox closes", with cookies included. These are quite explicit, and in previous versions (3.5 iirc) they definitely cleared cookies despite my "Show my windows and tabs from last time" setting. Even if the functionality is not changed, incompatible options should be greyed or clearly warned about. The current situation constitutes a security breach.
Got this problem with Twitter and other websites tabs I save and I'm asking too, keeping only cookies for the session / until I close firefox. If I close the website's tab that is logged in and restart firefox, cookies are cleared so the problem comes from here: After closing Firefox, it cannot delete cookies if tabs are saved for next session. Why is this problem still not corrected?
I'm having this problem with Aurora, STR for me: 1) clean profile 2) set restore session on startup, keep cookies until I close Aurora, don't save pwds 3) login to gmail (NOT as an app tab) 4) restart fx 5) gmail still logged in if instead I delete all google.com / gmail.com cookies manually, the gmail login form appears upon restart. I think this issue should really be addressed soon (and cookies relating to app tabs should also be deleted upon restart, if the user chose so in the privacy settings)
Maybe the user's choice of deleting all cookies on exit should always prevent session cookies to be restored, overriding Browser.sessionstore.privacy_level and Browser.sessionstore.privacy_level_deferred?
Assignee: paul → nobody
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
why is this a duplicate? in bug 345345 comment 40: "You might instead want to file a bug about making sure that automatically clearing cookies at shutdown clears them from sessionstore.js as well (then we'd even have obvious UI to achieve what you're asking for)." this seems to be the current bug, so not duplicate
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: