Closed Bug 627472 Opened 11 years ago Closed 11 years ago

Change values for sessionstore.privacy_level_deferred to not save secure session cookies


(Firefox :: Session Restore, defect)

Not set



Firefox 4.0b11
Tracking Status
blocking2.0 --- final+


(Reporter: zpao, Assigned: beltzner)



(Keywords: privacy, Whiteboard: [hardblocker])


(1 file)

From the security review for deferred session restore, it came out that we really shouldn't be saving (secure?) session cookies for people who don't have their session restoring by default. Since the only way to opt out of deferred session restore is to clear recent history when quitting, most people will be saving session data without their knowledge.

I think the consensus was that we could leave the normal "restore windows from last time" case as is with saving cookies & form data for https site.

It was also proposed we split the pref of privacy level for form data & cookies into 2 different prefs which I'll file shortly.
blocking2.0: --- → ?
Keywords: privacy
Isn't that what I'd suggested in bug 424871 comment 19 only to have jruderman (of s-g!) say that it wasn't needed in bug 424871 comment 20?

Either way, I support a default of "1", here, for deferred.
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Assignee: nobody → beltzner
Blocks: 629420
Attachment #508500 - Flags: review?(paul) → review+
Keywords: checkin-needed
Whiteboard: [hardblocker] → [hardblocker][can land]
Closed: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [hardblocker][can land] → [hardblocker]
Target Milestone: --- → Firefox 4.0b11
I'm confused.  In it was recommended to set browser.sessionstore.privacy_level to '1' - 

This patch seems to be changing privacy_level_deferred to 1 

so.. shouldn't both be '1' ?  or did wrong pref get flipped ?
It's confusing, I concur! This is how I understand things:

There are two settings:

privacy_level is the basic setting, governing what's stored while the sessions is active.

privacy_level_deferred is what's used when the browser is shutting down and:
  - the browser isn't "restarting" (for add-on install, application update, etc) 
  - the user hasn't stated that they "always want their session stored" in prefs

So, what happens now is:

 - browser saves session data even for SSL content during a session (=0),
 - on shutdown, if browser isn't restarting of the user hasn't set prefs such that session is automatically restored on startup, we purge SSL session data (=1)

In bug 629420 the reporter was surprised that their SSL data was restored, but they had set the preference to automatically restore their session on startup. That's why that bug was resolved INVALID - the browser was behaving as designed. 

However, in bug 629420 comment 4 someone asked "but what about the fact that we offer session restore on startup?" - as Gavin said, that particular case (the offer to restore session always being there, but not the case where the user has explicitly set a pref saying the session is to be automatically restored) is covered by this bug.
I confirm that the pref is set to 1 by default now.  I think we should create a litmus testcase for the "don't restore SSL session data" scenario.  Paul, could you please advise me on such a testcase?
Flags: in-litmus?(
You need to log in before you can comment on or make changes to this bug.