discussion: switch to session cookies (lifetime pref)

[Thorin-Oakenpants]

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!

[Jee-Hex]

FWIW I used to override network.cookie.lifetimePolicy until I realized setting it to 2 broke cookie-remover.js functionality in uBO.

[Thorin-Oakenpants]

I don't follow ... uBO doesn't remove cookies, can you explain what you mean by cookie-remover.js ?

[gwarser]

By scriptlet which sets cookie expiration time to past date - https://github.com/gorhill/uBlock/wiki/Resources-Library#cookie-removerjs-

[Thorin-Oakenpants]

OK, so what is the use case for cookie-remover.js then? I don't see the point

[KOLANICH]

IMHO we should leave privacy.clearOnShutdown at its default values. If a user wanted this, he can enable it himself.

[gwarser]

@Thorin-Oakenpants can be used to remove "adblock_detected" cookies, for example.

[Jee-Hex]

remove "adblock_detected" cookies

This, and I think some filter lists also use it to bypass article limit on some websites? But yeah the latter is probably partially mitigated by using containers.

[Thorin-Oakenpants]

does cookie-remover.js work in PB mode?

[gwarser]

It should work everywhere, because it works like page script.

[Thorin-Oakenpants]

That might be so, but doesn't [edit: defintively] answer my question :-(

[Thorin-Oakenpants]

Just thought I should note this, from memory: but my understanding of what mozilla plan to do is

currently

• under settings>privacy & security> cookies and site data
• if you check "delete cookies and site data when firefox closes" this changes cookies to session-only = the lifetime pref = 2
  • this will change
• note: this is different to PB mode which uses cookies normally but in memory only
• note: session-only cookies have side effects

mozilla plans

• to deprecate the lifetime pref, because read this
• and instead use the sanitize on close cookie option, which is what arkenfox does
• i.e no such thing as session-cookies as a default = no side effects (shared/service workers), less code, easier sanitizing code paths etc

the issue

• the sanitize on close option does not respect site exceptions, but they'll make that work

so in hindsight

• I do not see any point in changing arkenfox to the lifetime pref when mozilla are working in the opposite direction - i.e migrate lifetime pref users to sanitize cookies on close

I have no idea how long before Mozilla get around to this, meanwhile, users have the override recipe, and eventually mozilla will migrate them off it and arkenfox will update the info in the section header about cookies - could be a year for all I know

Closing. Thanks for the insight on uBO too

[Thorin-Oakenpants]

^ just to be clear, I want arkenfox to be as usable as possible, I want users to be able to retain some cookies, but I'm also happy to wait for the bugs linked above to land, especially given arkenfox has nuked cookies on close for five+ years at guthub edit, nah, see next post

[Thorin-Oakenpants]

we are switching to cookie lifetime as session: sorry about your anecdotal cookie-remover.js uses, but this is no reason to not move to more compatible settings as a default - the ability to still clear on close but retain exceptions. you are of course free to override