Total Cookie Protection& Multi-Account Containers

[ruihildt]

As far as I see, Mullvad Browser currently doesn't currently use Total Cookie Protection (network.cookie.cookieBehavior & network.cookie.cookieBehavior.pbmode are set to 1 instead of 5). Are there any downsides of enabling Total Cookie Protection in contrast to Mullvad Browser's current default setting of blocking all third-party cookies?

Mozilla has an article about Total Cookie Protection & Multi-Account Containers: https://blog.mozilla.org/en/products/firefox/extensions-addons/how-firefoxs-total-cookie-protection-and-container-extensions-work-together/ To me it sounds like Multi-Account Containers don't have any general privacy benefits over Total Cookie Protection like @ph00lt0 already said unless you want to separate sessions on the same domain, which is a likely a rarer case.

Is it safe to enable Total Cookie Protection (network.cookie.cookieBehavior = 5) right now as a user on Mullvad Browser or is that fingerprintable somehow?

If I've interpreted this all right, I'd say Multi-Account Containers definitely shouldn't be preinstalled but a recommended could be made with an explanation about what benefits it actually gives over Total Cookie Protection (once adopted). This issue can also be solved with browser profiles to a degree.

Originally posted by @felschr in https://github.com/mullvad/browser-extension/issues/23#issuecomment-1510451811

[Thorin-Oakenpants]

some answers/info

• Total Cookie Protection (TCP) uses dFPI (dynamic first party isolation). TB/MB use FPI, i.e no dynamic part so TB/MB are actually more strict in this regard. Basically the dynamic part allows cross site cookies for e.g. logins/SSOs (single sign ons) and is gated somewhat behind user gestures, and is somewhat temporary (15 days since last use?)
• TB/MB start in Private Browsing mode (PBM), so all windows are private windows. Private windows are essentially a container (id 1), and thus containers cannot be used inside a container. tl;dr - containers are incompatible with private windows
• cookie settings
  • ETP (enhanced tracking protection) is kinda not used by TB/MB, and the UI is removed to avoid confusion. In essence, we use custom settings and block all third party cookies (value 1). I'm not sure on the logic for that, since site data is already partitioned to 1st party, but I also don't think it breaks much as cookies are phased out and we don't allow any relaxation in FPI. Some other values don't make sense, since we don't ship (AFAIK) with tracker lists (value 4), and we can't block all cookies (value 2) as this would break too many sites. And value 3 seems like a waste of time IMO since we sanitize

FYI: and ETP standard/strict controls this

// 0 = Accept cookies and site data
// 1 = (Block) All third-party cookies
// 2 = (Block) All cookies
// 3 = (Block) Cookies from unvisited websites
// 4 = (Block) Cross-site tracking cookies (default)
// 5 = (Isolate All) Cross-site cookies (TCP: Total Cookie Protection / dFPI: dynamic FPI) [1] (FF86+)
user_pref("network.cookie.cookieBehavior", 1);

[Thorin-Oakenpants]

updated value above (sorry, I pasted an older description that was missing value 5)

Value 5 uses dFPI. TB/MB do not use dFPI, it uses FPI which is completely different engineering (i.e it's not even dFPI minus the d part). And we set user_pref("privacy.firstparty.isolate", true); which in code disables dFPI.

No one has bothered to check out the ramifications of all this, since it's not supported and not envisaged that users would do it (we hid the UI for a reason)

tl;dr: don't play with prefs in about:config