tracking: migrate cookie lifetime and sanitize cookie/offlineApps

Just a follow-up to the “keep cookie + site data exceptions on close” functionality (issues #1256 and #1291.)

Considering that:

• privacy.sanitize.sanitizeOnShutdown is not “All or Nothing” anymore, i.e. privacy.clearOnShutdown.cookies and privacy.clearOnShutdown.offlineApps now respect website exceptions as of FF99 (1681701, code);

• network.cookie.lifetimePolicy is soon/not so soon to be deprecated (1681493, 1764761).

Would it be the right time to update section 2800, deprecating network.cookie.lifetimePolicy and setting both privacy.clearOnShutdown.cookies and privacy.clearOnShutdown.offlineApps to true? Functionality wise, thing should continue to be the same. It would be more of a future-proof measure.

[Thorin-Oakenpants]

right … here we go … patchs underway bitches, early in the 102 nightly cycle

• https://bugzilla.mozilla.org/show_bug.cgi?id=1681495#c7 - Switch clear cookies and site data checkbox to control sanitization prefs
• https://bugzilla.mozilla.org/show_bug.cgi?id=1681498#c7 - Migrate users from network.cookie.lifetimePolicy to sanitize on shutdown prefs

[Thorin-Oakenpants]

The only issue I have is timing

• there is a migration planned
  • i.e if users have lifetime policy = 2, then enable sanitize on close and check cookies and offlineApps - and some logic to uncheck the other options IF sanitize on close was disabled
  • IDK what happens if the prefs are modified - e.g. us
  • and for subsequent starts the user.js will reset them

In other words I want to avoid the migration code getting triggered. So as long as we can switch at least one release before the pref is deprecated, then that’s what I want to do

My best guess is that they will want to get this done in ESR102 at the latest. For now it is not in FF101 and we can safely keep using the current setup.

I would rather not pull the trigger on changing until I know it’s production ready. There’s a bit to digest, and I would want to know it’s all working as intended. For example, 101 introduced some sanitizing speed perfs, which caused a regression with containers and subdomains (which was fixed). What I’m saying is I want to let the bugs manifest if there are any. And there is still code to be changed where lifetime policy is used.

We can afford to wait. The only benefit I see is that it would then allow service workers, but since we’ve lived without those for the last four five+ years, I don’t think another release or two matters

We can keep this issue open as the ToDo and for tracking (although I am already tracking it)