some dFPI questions

[Thorin-Oakenpants]

@wisniewskit

Hi Thomas. Thanks for your work on ETP and Smart Blocking. I have a few questions if you have time, as it's not clear to me, there's a lot of moving parts to ETP

Also, TIA

---

Arkenfox has used FPI for the last four+ years and it's worked brilliantly (except for some cross-domain login flows where we suggested a secondary browser/profile). But moving forward, maintaining two code paths in Firefox is not feasible, and FPI is going to break things sooner or later, and using dFPI comes with benefits and tighter integration (e.g. with sanitizing), so the time has come ... we are moving to ETP Strict

I'm using these terms (correct me if it's wrong)

• "Shims": the code you substitute (extensions.webcompat.enable_shims) <- we're enforcing this as true
• "SmartBlock": the heuristics you use that allows clicking a FB widget to relax partyness (privacy.antitracking.enableWebcompat ?)
  • which involves shims?

The questions I have are

• is dFPI totally strict (ignoring heuristics like clicking a facebook widget)
  • see [1]
• what does privacy.antitracking.enableWebcompat = false do exactly
  • see [2]
• what happens to dFPI when a user adds a site exception for ETP?
  • i.e to un-break a site they toggle the ETP switch from the urlbar shield
  • I assume no state partitioning is applied (for web site data, not network partitioning) for all parties on that eTLD+1
  • I understand that this is limited to that eLTD+1 and that same parties elsewhere are still keyed (unless also excepted)

---

[1]

https://phabricator.services.mozilla.com/D123663

• To improve web compatibility, Enhanced Tracking Protection makes automated exceptions for certain websites and features. Disabling this option is not recommended, as it can cause websites to break

• are these exceptions what is meant by skiplists?
• where are skiplists in searchfox?
• is this different to SmartBlock heuristics and/or shims?

I get that dFPI is not FPI, and that's fine given our users and threat model. We just want to make sure we are correct in our documentation

---

[2] and also see [1] re: privacy.antitracking.enableWebcompat

https://bugzilla.mozilla.org/show_bug.cgi?id=1683165
https://phabricator.services.mozilla.com/D123614

• Controls the anti-tracking webcompat features. This includes:

  • All URL-Classifier and state partitioning skip lists (prefs and remote settings)
  • Storage access heuristics (opener, redirect, etc.)
  • StorageAccessAPI automatic grants (skips the prompt)
  • Allowing specific tracking channels on user opt-in (e.g. facebook login shim).

So ... privacy.antitracking.enableWebcompat = false

• disable all automated anti-tracking webcompat heuristics and skiplists 1683165
• toggle web compatibility features of ETP off 1742841

I cannot work out if setting this pref (privacy.antitracking.enableWebcompat) to false hardens or relaxes state partitioning. I've gone back and forth and read it both ways, and others have different opinions as well. I can't imagine why Mozilla would want to add a switch for hardening (which has been mentioned as something down the track for Tor Browser) but rather one that relaxes (for dev testing), but if you turn off the skip lists, heuristics etc then the default is to isolate? So color me confused

here's the relevant prefs with 2702 to be added

/*** [SECTION 2700]: ETP (ENHANCED TRACKING PROTECTION) ***/
/* 2701: enable ETP Strict Mode [FF86+]
 * [NOTE] ETP Strict Mode enables Total Cookie Protection (TCP)
 * [1] https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/
 * [SETTING] to add site exceptions: Urlbar>ETP Shield
 * [SETTING] to manage site exceptions: Options>Privacy & Security>Enhanced Tracking Protection>Manage Exceptions ***/
user_pref("browser.contentblocking.category", "strict");
/* 2702: disable SmartBlock heuristics [FF93+]
 * [SETUP-HARDEN]
 * [1] https://blog.mozilla.org/security/2021/07/13/smartblock-v2/ ***/
   // user_pref("privacy.antitracking.enableWebcompat", false);
/* 2710: enable state partitioning of service workers [FF96+] ***/
user_pref("privacy.partition.serviceWorkers", true);

/*** [SECTION 6000]: DON'T TOUCH ***/
/* 6008: enforce no First Party Isolation [FF51+]
 * [WARNING] Replaced with network partitioning (FF85+) and TCP (2701),
 * and enabling FPI disables those. FPI is no longer maintained ***/
user_pref("privacy.firstparty.isolate", false); // [DEFAULT: false]
/* 6009: enforce SmartBlock shims [FF81+]
 * In FF96+ these are listed in about:compat
 * [1] https://blog.mozilla.org/security/2021/03/23/introducing-smartblock/ ***/
user_pref("extensions.webcompat.enable_shims", true); // [DEFAULT: true]

/*** [SECTION 7000]: DON'T BOTHER ***/
/* 7016: customize ETP settings
 * [WHY] Arkenfox only supports strict (2701) which sets these at runtime ***/
   // user_pref("network.cookie.cookieBehavior", 5);
   // user_pref("network.http.referer.disallowCrossSiteRelaxingDefault", true);
   // user_pref("privacy.partition.network_state.ocsp_cache", true);
   // user_pref("privacy.trackingprotection.enabled", true);
   // user_pref("privacy.trackingprotection.socialtracking.enabled", true);
   // user_pref("privacy.trackingprotection.cryptomining.enabled", true); // [DEFAULT: true]
   // user_pref("privacy.trackingprotection.fingerprinting.enabled", true); // [DEFAULT: true]

[wisniewskit]

is dFPI totally strict

Not quite, dFPI is basically meant to help the transition to the strictest FPI model on the web we can manage, and right now that means having heuristics to prevent the worst site breakage full FPI causes (so more users can have better protection sooner). The specifics of the heuristics aren't my specialty, but my understanding is that they essentially involve letting sites share access to web storage if a user interacts with a page in certain ways, for a limited time.

Another thing dFPI will help us do is push sites to use a consent-based model when they need to share cookies, by asking the user with a prompt for permission to do so while they interact with the page. So the sooner we can enable dFPI for everyone the better, as far as I'm concerned.

what does privacy.antitracking.enableWebcompat = false do exactly

It's meant to disable such extra heuristics, so that users who want the strictest settings possible at the cost of site breakage can still have them (whether they use FPI or dFPI). I don't know the details of how it works for dFPI or other ETP sub-features, but in SmartBlock's case it disables the Facebook login helper without disabling the entire Facebook shim.

Speaking of SmartBlock, it is separate from dFPI. It does have some fixes for dFPI, which are temporary measures while websites become compatible with dFPI. But mostly SmartBlock shims are there to act as replacements for trackers which are blocked by the content blocker. They act just enough like the blocked trackers to prevent known site breakage, without the tracking. So if the content blocker doesn't kick in, SmartBlock does nothing.

The content blocker is active in private browsing mode by default, as well as strict mode ETP (and custom mode, as configured). The list of shims can be seen in about:compat. Disabling shims via the pref will disable all shims listed there, including the content blocker and dFPI related ones.

what happens to dFPI when a user adds a site exception for ETP?

My understanding is that disabling ETP with the shield icon for a site disables all ETP protections, including FPI/dFPI and the content blocker (so SmartBlock won't kick in). @Trikolon, could you confirm (and maybe check the other questions above and correct anything I may have gotten wrong)?

(As an aside, this is why I'm experimenting with SmartBlock as a way to let users allow certain trackers through on just certain sites, without having to toggle ETP off entirely on the site, and not having to mess around with learning which trackers are needed for what).

Hope that helps clear some things up; I'll try to find time to re-read your post ASAP, since I've likely missed a few questions.

[Thorin-Oakenpants]

Thanks for the quick reply. So unless Paul says different, I was pretty much on the money (from earlier discussions).

whether they use FPI or dFPI ... all ETP protections, including FPI/dFPI

Just to clarify, FPI in my usage is the pref privacy.firstparty.isolate which is incompatible with dFPI, and in fact FPI (edit: when cookie behavior is 5) triggers cookie behavior to 4 and network partitioning is ignored (because FPI already covers that)

Not quite, dFPI is basically meant to help the transition to the strictest FPI model on the web we can manage

that's the bit I'm not 100% sure on. I know about the heuristics and shims (they're "managed") .. because I get that you can't ship a broken product (and TCP rollout won't be strict mode), but I'm worried about the "un-managed" like some sort of free pass for too hard to do cases - what is the SKIPLIST ? :)

The specifics of the heuristics aren't my specialty

OT: In terms of breakage from FPI (tor browser etc) the only thing we really found was some cross-domain login flows. So I'm hoping the triggers are almost always going to be specific transient user gestures like clicking a button and not a mouse gesture :)

ETP toggle

Yeah, I knew (pending Paul's answer) that would be the case, otherwise how could users un-break things. That's cool, I can explain that and the cross-domain risks of too many exceptions (the odds are low though IMO). Would be nice if ETP's per site setting eventually had a slider (off-standard-strict)

[wisniewskit]

which is incompatible with dFPI, and in fact FPI triggers cookie behavior to 4 and network partitioning is ignored

Yes, I think that patch/setting only affects dFPI and SmartBlock right now, as you expect (and for SmartBlock only affects opt-in behaviour for shims marked as needsShimHelpers "optIn" here).

but I'm worried about the "un-managed" like some sort of free pass for too hard to do cases

Just for the record, I meant "managed" as in "the strictest settings we can successfully have on by default". We of course want the least management possible (ideally none!). But as you say, this isn't an easy goal to achieve, especially given how many legacy/unmaintained sites are out there which users still rely on. After all the goal is for users to have strong protections, not make them want to avoid them.

I'm hoping the triggers are almost always going to be specific transient user gestures like clicking a button and not a mouse gesture :)

I feel the same way, and I'm under the impression that the rest of the anti-tracking team does as well. The SmartBlock-related workarounds should all trigger on user navigations or login popups (which should be caught by the popup blocker outside of a click), for instance.

Would be nice if ETP's per site setting eventually had a slider (off-standard-strict)

That could be nice. I'd also like to find ways to detect whether and why a site might be broken, so we can keep them working without having to fiddle with the shield icon at all (that's why SmartBlock is a thing, of course).

[gitthehubs]

@wisniewskit

Hi Thomas,

Thank you for your answers. I have a short question if you don't mind.

Firefox introduced Total Cookie Protection in Firefox 86 and it was enabled in ETP strict mode. But can you enable TCP in ETP custom mode as well? Is the dynamic partitioning in state partitioning always active with ETP despite your settings(basic, strict, custom) or is TCP only active in ETP strict mode? Is TCP just the cookiesetting 'cross-site cookies - includes social media cookies' ("network.cookie.cookieBehavior", 5); or are there more settings involved?
See also the the setting ("browser.contentblocking.features.strict", tp,tpPrivate,cookieBehavior5,cookieBehaviorPBM5,cm,fp,stp,lvl2,rp,ocsp); which adds more settings for ETP strict then we can choose in ETP custom.

I am just wondering because I am thinking of turning off the Tracking content option in ETP custom because I have my own ad-blocker uBlock Origin to take care of that. Or would you just advise ETP strict mode with uBO ad-blocker?

Thanks in advance!

[wisniewskit]

@gitthehubs

or are there more settings involved?

IIRC it's just ("network.cookie.cookieBehavior", 5) for normal windows and ("network.cookie.cookieBehavior.pbmode", 5) for private browsing windows.

That other pref lets Firefox know what set of pref values is considered strict mode (so the UI code knows which mode you're in, for example).

And yes, the label you mentioned is the one for TCP in about:preferences, but note that it's changing soon tocross site tracking cookies, and isolate other cross-site cookies.

Or would you just advise ETP strict mode with uBO ad-blocker?

That's what I've been using, and it hasn't been a problem for me so far. SmartBlock won't kick in if you disable Firefox's content blocking, and it offers different site fixes related to blocking trackers (surrogates) than uBo, so it might be good to keep both running.

[gitthehubs]

@wisniewskit
Indeed, I forgot to mention ("network.cookie.cookieBehavior.pbmode", 5) for pb mode. :)

Thank you for your answer!