There is an override recipe

/* override recipe: keep some cookies + other site data on close ***/
user_pref("network.cookie.lifetimePolicy", 2); // 2703
user_pref("privacy.clearOnShutdown.cookies", false); // 2802
  // user_pref("privacy.clearOnShutdown.offlineApps", true); // 2802 optional
user_pref("privacy.cpd.cookies", true); // 2803 Ctrl-Shift-Del
  // user_pref("privacy.cpd.offlineApps", true); // 2803 Ctrl-Shift-Del optional

🔻 overview

cookies + site data are not the problem, it is that they can be linked/re-used. cross-site linking is moot with FPI/dFPI (and network partitioning if using dFPI)

The issue is sites re-using their eTLD+1 site data: there are two types here

• ⭐ in other words, the issue is sanitizing
• in session: browsers are not expected to handle this
  • even TB does not wipe all persistent data when you change a circuit: to change "ID" you need a new session
  • you can use temporary containers
  • you can fluff around with cookie-wiping extensions and hope they cover all of it
  • you can use "forget about this site": handy but manual
    • there are many bugzillas on this and no clear consensus on what it should/shouldn't include, but I think it hooked in recently to Enhanced Cookie Clearing .. also see Exhibit A below
  • i am not concerned with this type, not arkenfox's problem, and this is not how you change an "ID", but I do get the use-case - in which case use containers or one-off PB windows - so still not arkenfox's concern
• new session
  • sanitize on close: robust, automated, etc and how browsers were designed to work (e.g. see TB info above)
  • arkenfox loves this ❤️

🔻 lifetime

Use cookie lifetime = 2 (which makes them session-cookies) and don't sanitize cookies on close. This is fine, even if lifetime is going to be deprecated, before Mozilla do that, they will still hook in some sort of ability to have a default keep-nothing with allow site data exceptions to be kept - but I do not know if that means keeping cookies as session by default, or storing them in a separate jar?

🔻 sanitizing

Sanitizing on close is still critical. "Cookies & Site Data" doesn't clear "everything" - it's a bit problematic in how you define what is part of history/downloads vs site data vs other (cache/certs etc) vs internals (site exceptions etc)

• exhibit A: 1671182 FF94+ cache no longer cleared with site data
• IDK exactly what is sanitized in "cookies and site data"
  • obviously cookies
  • one would assume localStorage and quota manager
    • I do not know how they manage this, imagine deleting eTLD+1 one by one: not saying they do it this way
  • what about SW cache : chicken vs egg in this case for now, as session only cookies block shared workers and SWs. but what if that changes
  • always wary of orphaned data

arkenfox would

• not clear cookies: exceptions as allow mean users keep their logins
• everything else stays the same: i.e it will still clear offlineApps, cache etc
  • offlineApps: localStorage, service worker cache, QuotaManager (IndexedDB, asm-cache)
  • ^^ I doubt sites keep anything useful in those, but maybe losing those means users lose some website user settings

this makes clearing "site data" robust AF

🔻 service workers

There is what I would call a bonus here, and that is that session-cookies blocks shared and service workers. We should also allow service workers 2302 by default (i.e just make it inactive).

FWIW, this actually removes another point of difference in FPing, as the API state is easily detected (via navigator properties), but this is not why I suggest making it inactive. After the API check, whether or not shared or service workers actually work is not a stable FP metric IMO

So by default, shared and service workers are blocked (because cookies are default session-only), and if a site requires e.g. service workers, it's and easy fix to allow the cookie

My only concern here is if service workers are properly isolated under FPI (there are questions but no-one has had time to follow up given this is for Tor browser, which uses PB mode so not high priority), but given the default is they can't run, and allowed exceptions would be minimal, I do not see an issue. Plus we will be moving to dFPI eventually (maybe in three or four releases)

🔺 impact

I actually block all cookies by default: and allow four sites for logins, and allow for session on another dozen so they work. This is not sustainable, as eventually when we move to dFPI, all cookies+sitedate (except known trackers) are allowed. Before anyone asks, cookie permissions are not a stable metric in fingerprints.

we would flip the override recipe to "keep no cookies + site data on close"

overall, I see this as reducing breakage and maintenance

• e.g. I wouldn't need to have my dozen "allow for session" exceptions and that's just some regular sites I can be bothered with: not that you guys need that per se, the point being that many sites don't function properly with cookies allowed
• it allows users to keep logins

class, discuss!