1666895 - When domains are set with Ci.nsICookiePermission.ACCESS_SESSION the cookies persist across restarts

Status: NEW

(Firefox :: Session Restore, defect)

Description

[Mike Kaply [:mkaply]]

We had a request for enterprise policies to allow specifying domains where cookies are only allowed for sessions.

Basically a domain specific version of setting ACCEPT_SESSION for network.cookie.cookieBehavior.

I chose to use Ci.nsICookiePermission.ACCESS_SESSION because based on lookingat the code, it seemed like it would work, but it has one major difference:

When you have Firefox set to "Restore Session" it restores cookies set with ACCESS_SESSION even though Restore Session does NOT restores cookies when you have ACCEPT_SESSION set for network.cookie.cookieBehavior.

This doesn't seem like correct behavior. Both of these should have the same definition of what a "session" is.

Comment 1

[Mike Kaply [:mkaply]]

see conversation at:

https://github.com/mozilla/policy-templates/issues/683

Comment 2

[Valentin Gosu [:valentin] (he/him)]

I'm not sure what the desired behaviour is here.
Potentially we could nuke all the session cookies at shutdown to make sure we don't restore them?

Comment 3

[Dragana Damjanovic [:dragana]]

Can you maybe answer question ic comment 2?

Comment 4

[Daniel Veditz [:dveditz]]

This has been a giant head-butting issue since the beginning of session restore. There's broad agreement that if the user crashes or does an update then we want to get them back to where they were with minimal fuss. A user will naturally think of this as "the same session", just interrupted. Where we fight is what the start-up setting "Open previous windows and tabs" means.

Some of us think a user intentionally closing the browser is the end of the session, and all we should do on a normal start-up is literally load the previous URLs and let the chips fall where they may. Early influential Firefox Product owners felt very strongly that users would be mad if we opened their "previous windows" and then they immediately got redirected elsewhere because they were logged out. To which the first group pointed to the many websites that let users choose between "remembering" them and ephemeral sessions. The second group then pointed to fascist sites like banks that don't give you that choice and try to log you out as aggressively as possible -- we fight for the user! (never mind that banks etc can time sessions out on the back-end, or use non-session cookies with a short lifetime).

A mess. See the "eternalsessions" bug 530594 (which grew out of the WONTFIXed bug 443354), and its at least 27 dupes. Part of it was fixed for people who globally set their cookie lifetimes to "session" (bug 529899) or had their privacy pref set to clear cookies on shutdown (bug 1260360). This broke at least once and had to be re-fixed in bug 1359344. This is what gives rise to the difference described in comment 0: the second group agreed that we could delete the session data for users who had made such a strong explicit opt-in privacy signal, but that for other users where we didn't have a signal like that the majority would still expect the "Open Previous Windows" settings to "just work".

So there we are.

I vehemently disagree with giving enterprise policies abilities that users don't have. Either we should figure out a way to fix this for all or not do it. I see a couple of ways to do approach this.

1. Maybe the current crop of Firefox Product / front-end folks no longer have the same opinions as the old-guard. On a clean shut-down we could just clear ALL the session data. This might be pretty easy: in _maybeClearCookiesAndStorage() I think we could just skip checking the prefs and always delete.

2. More conservatively, argue that manually setting an origin's cookie lifetime setting to ACCESS_SESSION is just as explicit a signal as the global one and we should honor it. This would work be honored whether that setting was made by the user or by enterprise policy. Might be easier to get agreement to do this conceptually than the first option, but implementation will be more work since we'd have to loop through all the data and check site permissions for each origin.

This is more properly a sessionrestore issue, not a cookie one

Comment 5

[Daniel Veditz [:dveditz]]

in _maybeClearCookiesAndStorage() I think we could just skip checking the prefs and always delete.

After the checks that we're cleanly shutting down, of course.