1681493 - [meta] Deprecate and remove network.cookie.lifetimePolicy

Status: RESOLVED FIXED

(Core :: Networking: Cookies, task, P3)

Description

[Johann Hofmann [:johannh]]

As mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1679012#c4 and following comments we would like to get rid of the cookie lifetime policy. While there used to be more options for cookie lifetime, the remaining one is "session".

For most users, the concept of "session" cookies is very hard to understand and so we try to make it a little more opaque by calling the option "Delete cookies and site data when Nightly is closed". Because this can already be done with sanitization preferences we effectively end up with two different ways in Firefox to clear cookies and site data on exit. The difference between them is almost impossible to understand for anyone who is not a Firefox engineer.

In addition to usability concerns, having "in-memory-only" session cookie lifetime has meant adding ugly hacks and workarounds for most of our storage technologies for a long time now (or simply disabling them in that mode). We had already decided in the past to stop treating "session lifetime" as equivalent to "in-memory" to avoid these issues. At that point there's no real reason to have the concept of session lifetime anymore when all of it could be handled through sanitization.

The path forward here is to start removing UI that allows users to enable session lifetime and migrate all users with the pref set to sanitization prefs instead. If we do it right there should be few implications for the affected users except less site breakage :)

Comment 1

[jscher2000]

(In reply to Johann Hofmann [:johannh] from comment #0)

We had already decided in the past to stop treating "session lifetime" as equivalent to "in-memory" to avoid these issues. At that point there's no real reason to have the concept of session lifetime anymore when all of it could be handled through sanitization.

The path forward here is to start removing UI that allows users to enable session lifetime and migrate all users with the pref set to sanitization prefs instead. If we do it right there should be few implications for the affected users except less site breakage :)

Can you make sanitize at shutdown respect ALLOW exceptions? This would benefit users (i.e., me) who currently use the pattern of session cookies by default and ALLOW permissions for sites that torment you with MFA (or simply logging in every time you have to restart).

I realize this functionality is difficult to explain, but SUMO also gets questions about why cookie exceptions are not observed in sanitize at shutdown and we steer them to lifetime as a workaround.

Comment 2

[Johann Hofmann [:johannh]]

(In reply to jscher2000 from comment #1)

(In reply to Johann Hofmann [:johannh] from comment #0)

We had already decided in the past to stop treating "session lifetime" as equivalent to "in-memory" to avoid these issues. At that point there's no real reason to have the concept of session lifetime anymore when all of it could be handled through sanitization.

The path forward here is to start removing UI that allows users to enable session lifetime and migrate all users with the pref set to sanitization prefs instead. If we do it right there should be few implications for the affected users except less site breakage :)

Can you make sanitize at shutdown respect ALLOW exceptions? This would benefit users (i.e., me) who currently use the pattern of session cookies by default and ALLOW permissions for sites that torment you with MFA (or simply logging in every time you have to restart).

To be honest I didn’t realize that this wasn’t the case already. But looking at the code it seems like you’re right.

So, yes, that’s definitely a blocker for the transition. Thanks for chiming in!

I realize this functionality is difficult to explain, but SUMO also gets questions about why cookie exceptions are not observed in sanitize at shutdown and we steer them to lifetime as a workaround.

Gah, yeah, this is why I want to simplify the whole thing.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

I think we already do the allow check in maybeSanitizeSessionPrincipals after my review comment to this effect in https://bugzilla.mozilla.org/show_bug.cgi?id=1400678#c13.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Oh, is the issue that this conditional logic only applies to ACCEPT_SESSION explicitly in Sanitizer.jsm? I guess that's what bug 1681701 is saying about "privacy.clearOnShutdown.cookies" which I guess I hadn't realized was a different thing? Yeah, so confusing.

Comment 5

[Johann Hofmann [:johannh]]

Yup, I think it’s not covered, really confusing :(

Comment 6

[Thorin [:thorin]]

When lifetime is deprecated, how do you propose to handle the permissions tab (Ctrl-I)

• the setting "Set cookies" is fine, in that the default will now be allow, and you can test/set a site to session or block
• but that doesn't leave an easy way to add site exceptions for sanitizing cookies + site data

Comment 7

[jscher2000]

(In reply to Simon Mainey from comment #6)

When lifetime is deprecated, how do you propose to handle the permissions tab (Ctrl-I)

• the setting "Set cookies" is fine, in that the default will now be allow, and you can test/set a site to session or block
• but that doesn't leave an easy way to add site exceptions for sanitizing cookies + site data

Hi Simon, the way I think about the planned meaning of the three permissions is as follows:

• Allow => Preserve the site's cookies at shutdown regardless of the "Clear history when Firefox closes" setting
• Allow for Session => Remove the site's cookies at shutdown if I select "Clear history when Firefox closes" with cookies designated for clearing
• Block => Never set cookies for this site

However, that naming is hard to understand, so hopefully UI can devise great new labels that succinctly capture this behavior.

Comment 8

[Thorin [:thorin]]

Hi Jefferson

We're assuming "delete cookies + site data when Firefox is closed" is checked, and the user has some exceptions

I think we're talking at cross purposes a little. I wasn't expecting the cookie permission to be usurped (and labels renamed) from controlling actual cookie states to sanitizing. It just feels so wrong as it's not a site permission, it's a user sanitizing decision

But if replacing it (and losing that functionality) makes things simpler, so be it, and it becomes just a naming/UX thing (that wasn't my original question, but yeah: that's easy)

• Permissions tab > Cookies : Keep (default in new profile), Keep for session (default for us: see assumption above), Block

Wonder what Johann and Paul think

Comment 9

[Paul Zühlcke [:pbz]]

(In reply to Simon Mainey from comment #8)

I think we're talking at cross purposes a little. I wasn't expecting the cookie permission to be usurped (and labels renamed) from controlling actual cookie states to sanitizing. It just feels so wrong as it's not a site permission, it's a user sanitizing decision

This is actually the way it has always worked with cookie lifetime policy. We're merely extending sanitize-on-shutdown to honor these exception permissions. I get how these cookie permissions aren't very intuitive though. A cookie allow permission would both allow a site to set storage and preserve that storage when clearing / sanitizing site data on shutdown.

We're seeing low usage on the "Allow for session" permissions, so we're planning to remove that feature entirely. That is, having sanitize on shutdown disabled and only clearing very specific sites which have the permission set. Users who still need this specific capability, could switch to an addon like: https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/ which allows for more fine-grained control over cookie clearing.

We want to keep both the allow and block options, which means you can still enable sanitize-on-shutdown and exempt sites from being cleared.

Comment 10

[Thorin [:thorin]]

Sorry, I feel we're still talking at cross purposes. I am concerned about the UI. I get the underlying code/principles and what we're doing

Me: But if replacing it (and losing that functionality)
Paul: so we're planning to remove that feature entirely

OK. "Allow for session" functionality is to be removed - that's fine

That is, having sanitize on shutdown disabled and only clearing very specific sites which have the permission set

Indeed: this is not something anyone should want: i.e keep all delete a few = not good hygiene/strategy: agreed, extensions can handle that sort of nonsense

We want to keep both the allow and block options, which means you can still enable sanitize-on-shutdown and exempt sites from being cleared

Indeed, but users won't be able to add exceptions via permissions tab if you only have two options "Allow" and "Block". Which only leaves the slow human error-prone typing into "Manage Exceptions" including missing schemes and www etc - if that's how it has to be, so be it - and that was what my question was about

Comment 11

[Asif Youssuff]

I'm also confused about what the UI will look like/how this will work. For context, I wrote a post about my particular setup (with screenshots): https://www.quippd.com/writing/2021/07/26/firefox-privacy-stop-hardening-love-strict-etp.html#delete-cookies-when-closing-firefox

Basically, I set Firefox to Delete cookies and site data when Firefox is closed, then I override that preference on a site by site basis by using the Page Info panel.

Is this something that will continue to be supported? I guess in the parlance of this bug, I don't want to sanitize the cookies of the sites that I specify.

Comment 12

[Paul Zühlcke [:pbz]]

(In reply to Simon Mainey from comment #10)

We want to keep both the allow and block options, which means you can still enable sanitize-on-shutdown and exempt sites from being cleared

Indeed, but users won't be able to add exceptions via permissions tab if you only have two options "Allow" and "Block". Which only leaves the slow human error-prone typing into "Manage Exceptions" including missing schemes and www etc - if that's how it has to be, so be it - and that was what my question was about

There are actually 4 states in the page info window (Permissions tab) for the cookie permission.

1. "Use Default" checked
2. Allow
3. Allow for Session
4. Block

When we remove (3) "Allow for Session", you can still check "Use default", which effectively clears the permission. Selecting "Allow" will add an exception for that site. Does that answer your question?

(In reply to Asif Youssuff from comment #11)

I'm also confused about what the UI will look like/how this will work. For context, I wrote a post about my particular setup (with screenshots): https://www.quippd.com/writing/2021/07/26/firefox-privacy-stop-hardening-love-strict-etp.html#delete-cookies-when-closing-firefox

Basically, I set Firefox to Delete cookies and site data when Firefox is closed, then I override that preference on a site by site basis by using the Page Info panel.

Is this something that will continue to be supported? I guess in the parlance of this bug, I don't want to sanitize the cookies of the sites that I specify.

Yes, that will still be supported. Since you're checking "Delete cookies and site data when Firefox is closed" Firefox will clear all data on shutdown, skipping any sites you added as exceptions - exceptions being sites where you set cookies to "Allow".

Comment 13

[Thorin [:thorin]]

When we remove (3) "Allow for Session", you can still check "Use default", which effectively clears the permission. Selecting "Allow" will add an exception for that site. Does that answer your question?

Bingo!

Comment 14

[Dennis Schubert [:denschub]]

This is WebCompat P3 for now - it's only a breaking site and only with a non-default config. We can revisit in the future.