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

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect)

Description

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

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.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: set privacy_level_deferred to 1

Comment 3

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Pushed http://hg.mozilla.org/mozilla-central/rev/9b9a27994839

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

I'm confused.  In https://bugzilla.mozilla.org/show_bug.cgi?id=629420#c1 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 ?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 6

[u279076]

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?

Comment 7

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

I think https://litmus.mozilla.org/show_test.cgi?id=13855 and I think https://litmus.mozilla.org/show_test.cgi?id=13853 are sufficient.