search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
10.19k stars 517 forks source link

move from FPI to dFPI #1051

Closed Thorin-Oakenpants closed 2 years ago

Thorin-Oakenpants commented 4 years ago

ToDo:

Cleanup/Tests

dFPI bugzilla tree

original message

comment

Yes, DFPI and FPI use separate attributes and when FPI is enabled, the partitioning/isolation specific code isn't relevant because we're using the older FPI code.

There's no point enabling/adding the partition pref/info to section 4000

what we had for posterity

/* 4003: enable site partitioning (FF78+)
 * [1] https://bugzilla.mozilla.org/1590107 [META] */
user_pref("privacy.partition.network_state", true);
Thorin-Oakenpants commented 3 years ago

Intent to ship: Network Partitioning: https://groups.google.com/g/mozilla.dev.platform/c/uDYrtq1Ne3A

Thorin-Oakenpants commented 3 years ago

@gwarser

Pants, I will like to ask you something about containers in Firefox, your message just reminded me about it. Maybe you will know more about it and explain me whats going on. I think I have found some logic issue in containers handling.

I have google container, with google domain assigned to it, to open automatically. Also I have pref set to open all other domains outside this container (handy on gmail).

When I am on YT (not assigned to container), and I accidentally click on “sign in” (or when I forget about containers and want to sing in to another YT-related account), Firefox will redirect YT-no container to account.google.com google container, and back to YT-no container.

I’m pretty sure this should just fail, and I’m pretty sure this was failing before, but for some reason I’m now logged-in into my google account on YT. This is completely unexpected to me. Any page can just redirect me through other container to snoop for my data? WTH?!

Umm, can we chat in here, it's easier. And can we clarify some things?

So the container is not using eTLD+1? Do you gave FPI at all? Is this on nightly? I don't know much about containers (except that they're an OA just like FPI), and my impression is they're been ignored for a while now because priorities, and will get phased out like FPI (cuz partitioning, dFPI).

I'd be inclined to

Maybe you just need to group youtube and account.google.com in a container? or just accounts in it's own container?

I'm probably not much help, cuz I don't do any of the alphabet shit

seonwoolee commented 3 years ago

I'd just use Temporary Containers

Thorin-Oakenpants commented 3 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=1686296 dFPI rides the train

Thorin-Oakenpants commented 3 years ago

this is the one to watch, or at least read: about moving away from FPI (deprecate it) to dFPI .. there's just a few knobs missing right now - https://bugzilla.mozilla.org/show_bug.cgi?id=1649876

Thorin-Oakenpants commented 3 years ago

answering #1103

basically, FPI overrides

Just think of it as two sets: networking related stuff, and website storage stuff (cookies, service worker cache, IDB etc). FF85 turned on the network part, but the cookie behavior default is still 4.

note: network.partition (see lists below) and dFPI may cover something that FPI doesn't, but no-one is 100% sure (Tim and Tom from Mozilla both seem to think we're OK, and no-one is going to waste time backtracking on something that will ultimately be obsolete: see next paragraph). FPI has been stable now for a long time, so waiting until dFPI is ready is no big deal. But do see sysrqb's comment here - sysrqb is the lead developer at Tor Project

At some stage FPI will be deprecated and dFPI will be it. But dFPI is still being polished and is super not production ready (lots of exmaples but here is one: 1669716 - cookies extension API unaware of dFPI ).

Additionally, on top of that, there are some knobs and tweaks missing to gain some strictness parity with FPI (e.g. for Tor Browser standards)

some tickets

tl:dr: too early to flip to this

[1] https://groups.google.com/g/mozilla.dev.platform/c/uDYrtq1Ne3A

HTTP cache Image cache Favicon cache Connection pooling StyleSheet cache DNS HTTP authentication Alt-Svc Speculative connections Font cache HSTS OCSP Intermediate CA cache TLS client certificates TLS session identifiers Prefetch Preconnect CORS-preflight cache

[2] 1278037 - indexedDB (FF51+) <- initial ticket which also covers cache, cookies etc 1277803 - favicons (FF52+) 1264562 - OCSP cache (FF52+) 1268726 - Shared Workers (FF52+) 1316283 - SSL session cache (FF52+) 1317927 - media cache (FF53+) 1323644 - HSTS and HPKP (FF54+) 1334690 - HTTP Alternative Services (FF54+) 1334693 - SPDY/HTTP2 (FF55+) 1337893 - DNS cache (FF55+) 1344170 - blob: URI (FF55+) 1300671 - data:, about: URLs (FF55+) 1473247 - IP addresses (FF63+) 1492607 - postMessage with targetOrigin "*" (requires 4002) (FF65+) 1542309 - top-level domain URLs when host is in the public suffix list (FF68+) 1506693 - pdfjs range-based requests (FF68+) 1330467 - site permissions (FF69+) 1534339 - IPv6 (FF73+) and I believe it also covers font cache when they added that to network.partition

Thorin-Oakenpants commented 3 years ago

But dFPI is still being polished and is super not production ready

And yet it's riding the train for stable 86 (see comments higher up) [edit: for those using ETP strict mode, not everyone] - unless something happens quickly with outstanding issues, or they backtrack on that timetable - I expect breakage: extensions from above example, not to mention site permissions (since the key changed), etc

Just as well we set FPI and enforce a custom ETP setting with cookies. Because there is also a key change, everyone will have to update their site permissions - so I prefer than we (arkenfox users) control this when it is ready and forewarn everyone in advance

rugabunda commented 3 years ago

The recent update appears to have broken certain web functionality, such ass the hyvor comment sections, located at the bottom of the page there, and the video player on trunews.com; [update: actually the latter doesn't seem to work in chromium either] can I get a confirmation? I still use privacy.firstparty.isolate; no settings changed.

If using FPI, should we disable these?

network partitioning
    privacy.partition.network_state (defaults to true in FF85)
dynamic FPI (dFPI)
    network.cookie.cookieBehavior = 5 (Cross-site and social-media trackers, and isolate remaining cookies)

update quote

The referenced page comes with a BIG disclaimer stating that using the older user_pref("privacy.firstparty.isolate", true); will result in using the older FPI codebase and NOT the new concepts mentioned above (translated from the original German text). Src

UPDATE disabling/enabling FPI again fixed it.

Thorin-Oakenpants commented 3 years ago

If using FPI, should we disable these?

2701: network.cookie.cookieBehavior is already controlled in the user.js

user_pref("network.cookie.cookieBehavior", 1);
user_pref("browser.contentblocking.category", "custom");

privacy.partition.network_state (defaults to true in FF85)

Hopefully by ESR91 we can move to dFPI with some optional hardening knobs

Thorin-Oakenpants commented 3 years ago

@gwarser for your amusement

Thorin-Oakenpants commented 3 years ago

here's a nice write up on STATE tracking:

curiosityseeker commented 3 years ago

here's a nice write up on STATE tracking:

* https://hacks.mozilla.org/2021/02/introducing-state-partitioning/

I'm still not sure if I get it right. One of the comments on that site suggests that:

Total Cookie Protection = state partitioning = dynamic first-party isolation

I'm not sure if that's quite correct.

Hence, while TCP is (in my understanding) equivalent to Network and Dynamic State Partitioning, dFPI seems to be only a subset. TCP (by enabling ETP Strict Mode) implicates more settings. According to about:preferences#privacy, Strict Mode also protects against "Social media trackers", i.e. privacy.trackingprotection.socialtracking.enabled = true. I'm not sure if that's the only difference, though.

Is this summing-up correct or mere BS?

Thorin-Oakenpants commented 3 years ago

Off the top of my head in general terms

That's my understanding.

Note: AFAICT .. the term dFPI is/was a bit misunderstood/misused as the overall FPI replacement name. dFPI is really only about one group (TCP), not the whole FPI replacement

However, if I set network.cookie.cookieBehavior back to 5, ETP remains unchanged at Custom Mode.

That might be a bug. Did you close and reload about:preferences#privacy ? Not everything is listening for changes. And we already know setting cookies from user.js doesn't pickup ETP being custom at runtime. It's also a little messy right now: 87 was missing the option 5 in the drop down (they forgot to flip the mvp ui pref) - not to mention that FPI interferes

ETP in strict mode sets a bunch of things, such as the tracker list level, cookie behavior, etc, and now tracking shims

Now you can maybe emulate "strict" in custom: you can use cookie behavior 5 in custom, and the other options are there: except I don't see how to change the level, or how you get the new shims. I don't think those are important right now - as the level is nothing compared to uBO, and uBO also has some shims

Thorin-Oakenpants commented 3 years ago

the UI inconsistencies is probably somewhere in here: https://bugzilla.mozilla.org/show_bug.cgi?id=1645898 . I actually remember reading a bugzilla very similar if not the same as you describe, but now I can't find it. From memory the STR were a certain order. There's probably a few quirks until it's polished - in 87 86 it wasn't shown in the UI (they forgot) and only used in strict mode. In 88 87+ it's now visible in options - give it some time for bugs to surface :)

edited: fixed up versions mentioned: for some reason I keep thinking stable is 88 right now when it's 87

Thorin-Oakenpants commented 3 years ago

However, if I set network.cookie.cookieBehavior back to 5, ETP remains unchanged at Custom Mode

Now that I've had some sleep ... that's to be expected. You were in custom mode to start with, and you changed an individual setting - you did not change to strict mode which is a different pref(s)

edit: this is the pref that changes between standard, strict and custom mode. When you change individual settings like cookie settings in about:config, then listeners will auto change you to custom (since the settings no longer fit the preset "standard" or "strict"). I'm pretty sure there is no reverse logic, to reset the category if all the conditions meet preset standard/strict

And honestly, I do not know what happens when you set everything via user.js/about:config and they conflict

curiosityseeker commented 3 years ago

Thanks a lot for your comprehensive replies! Have I told you before that you're truly beyond compare? :+1: :+1: :+1:

In any case my view was definitively too simplistic, it seems :-(

e.g. in 1686296 they used "browser.contentblocking.features.strict", "tp,tpPrivate,cookieBehavior5,cm,fp,stp,lvl2"

tp = tracking protection on? huh? what?
tpPrivate = pb mode windows on? huh? (options are all windows or pb only)
cookieBehavior = 5
fp = fingerprinters on
cm = cryptomining on
stp = social/standard/strict/ tracking protection?
lvl2 = level two boss fight, beat that bitch, get to level 3

It seems that https://searchfox.org/mozilla-central/source/browser/components/preferences/tests/browser_contentblocking.js and https://searchfox.org/mozilla-central/source/browser/components/preferences/tests/browser_statePartitioning_strings.js contain the details but I haven't checked them yet.

EDIT: https://searchfox.org/mozilla-central/search?q=contentblocking&path=&case=false&regexp=false

However, if I set network.cookie.cookieBehavior back to 5, ETP remains unchanged at Custom Mode

Now that I've had some sleep ... that's to be expected. You were in custom mode to start with, and you changed an individual setting - you did not change to strict mode which is a different pref(s)

Yep, you're right. It's the same with the other modes, of course.

And honestly, I do not know what happens when you set everything via user.js/about:config and they conflict

So we have to wait until things clear up and more detailed documentation is available.

Thorin-Oakenpants commented 3 years ago

cool 👍 great link ❤️ 

const TP_PREF = "privacy.trackingprotection.enabled";
const TP_PBM_PREF = "privacy.trackingprotection.pbmode.enabled";
const NCB_PREF = "network.cookie.cookieBehavior";
const CAT_PREF = "browser.contentblocking.category";
const FP_PREF = "privacy.trackingprotection.fingerprinting.enabled";
const STP_PREF = "privacy.trackingprotection.socialtracking.enabled";
const CM_PREF = "privacy.trackingprotection.cryptomining.enabled";
const LEVEL2_PREF = "privacy.annotate_channels.strict_list.enabled";
const PREF_TEST_NOTIFICATIONS =
  "browser.safebrowsing.test-notifications.enabled";
const STRICT_PREF = "browser.contentblocking.features.strict";
const PRIVACY_PAGE = "about:preferences#privacy";
const ISOLATE_UI_PREF =
  "browser.contentblocking.reject-and-isolate-cookies.preferences.ui.enabled";
const FPI_PREF = "privacy.firstparty.isolate";

So in theory, we could manipulate strict mode 's default settings browser.contentblocking.features.strict and enable strict mode :) I don't see where the shims kick in (maybe it's built into lvl2?).

Until it's more refined, e.g. they add some extra knobs to harden TCP such as turning off the heuristics, we'll stick with FPI - most likely until at least FF94 (when ESR78.15 is obsolete)

[1] https://spreadprivacy.com/browser-privacy-protection/

Therefore, to really stop a cross-site tracker, the kind that tries to track your activity from site to site, you have to prevent it from actually loading in your browser in the first place.

^ there's more: less requests, perf improvements etc

curiosityseeker commented 3 years ago

Additionally, there is the issue of connections - it's better to block that making the connection in the first place (e.g. IP for starters) [1] - so I guess this makes uBO in medium/hard mode even more important

[1] https://spreadprivacy.com/browser-privacy-protection/

Therefore, to really stop a cross-site tracker, the kind that tries to track your activity from site to site, you have to prevent it from actually loading in your browser in the first place.

^ there's more: less requests, perf improvements etc

True, that's why I use uBO in Hard Mode with Javascript blocked by default. On the other hand, most trackers/adservers/malware sites are already blocked by the default filter lists alone. (FWIW, I've also added this comprehensive list).

And that's why I don't miss the fine-grained control by uMatrix anymore as the remaining XHR's are usually legitimate. And everything will be deleted by Temporary Containers after a couple of minutes, anyhow.

Thorin-Oakenpants commented 3 years ago

I added two override recipes for the current master in #1080 - how to set ETP strict mode, and how to use TCP in custom mode

rugabunda commented 3 years ago

@Thorin-Oakenpants is FPI still superior to DFPI as of FF88? I notice FPI was automatically disabled in about:config recently in firefox, and privacy.firstparty.isolate.use_site was enabled.

Thorin-Oakenpants commented 3 years ago

I notice FPI was automatically disabled in about:config recently in firefox

I haven't seen anything about migrating FPI users to dFPI - 1649876

I did read something about privacy.firstparty.isolate.use_site (I thought they were removing it), and I see my Nightly has it modified to true (I don't use FPI in my nightly or have any FPI'd data since I fully sanitize). I'm 99% sure I didn't set it. So not sure what's going on there.

TBH, I haven't kept up with it: I did find this comment somewhat enlightening

someday I do hope that all of the FPI code goes away, and the FPI behavior (that of being strict with no compromises) is implemented by the dFPI code as some sort of extra, hidden dFPI mode. I don't know when - if ever - that will happen

So my gut feeling is that as long as TB use FPI, then so will we, and we'll deal with privacy.firstparty.isolate.use_site when/if it changes in release

is FPI still superior to DFPI

Define superior. AFAIK:

Thorin-Oakenpants commented 3 years ago

IDK if Smart Block is all of the heuristics part of dFPI - see https://blog.mozilla.org/security/2021/07/13/smartblock-v2/

but seems like extensions.webcompat.enable_shims controls the whole smart block thing, so in theory you could use dFPI right now instead of FPI and it should be just as effective, probably more so (given eTLD+1/site scheme diffs?)

ghost commented 3 years ago

@Thorin-Oakenpants I'm a bit confused here so I'd be happy if you could help me out

dFPI: Blocks tracking cookies and isolates others to their each cookie jar. Temporarily allows a 3rd party cookie if it's needed e.g. for logins Smartblock: (From what I've read) Tries to unbreak a site if a script is blocked by ETP by using local stand-in scripts.

AFAICT they're not related. Isn't SmartBlock a feature to reduce the breakage made by ETP. If so, then the heuristic parts of dFPI shouldn't be related to SmartBlock.

Thorin-Oakenpants commented 3 years ago

dFPI is a work in progress, and not on by default: obviously lot of things break without shims or heuristics or whatever. There's a lot of moving parts, and I'm not an expert on it. I'm also not following it all that closely.

"Shims" or "Smart Block" , to me at least, does both: i.e

I'm also not 100% sure what happens when you disable ETP on a site: does that remove the isolation? I don't think it does, it just unblocks all connections: i.e unlock the tracker blocker part. This is one thing I like about FPI: there are no site exceptions and no 3rd party exceptions = super simple to understand. When dFPI gets that knob (hardened switch for Tor Browser), then we'll switch to it (and add info on the diffs between dFPI vs dFPI-hardened) . Until then I'm not following it all that closely.

ghost commented 3 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=1397624#c49

Dynamic State Partitioning to isolate all storages that are intended to store data (e.g. Cookies and localStorage) which can be enabled by setting network.cookie.cookieBehavior = 5 (also exposed via the options GUI). There are heuristics that allow access out if this partitioned sandbox to presumably avoid the breakages that the old first party isolation ( privacy.firstparty.isolate = true ) caused (e.g. paying on the PayPal popup called by the Steam storesite not working) which can in theory also be abused for tracking. But there are options to disable these heuristics (privacy.restrict3rdpartystorage.heuristic.opened_window_after_interaction, privacy.restrict3rdpartystorage.heuristic.recently_visited, privacy.restrict3rdpartystorage.heuristic.redirect, privacy.restrict3rdpartystorage.heuristic.window_open; presumably all set to true to enable the heuristics (the default) and to false to disable them - but the linked article isn't clear about that).

What are your thoughts about this? Are these prefs related to the heuristics provided by dFPI or is it something different?

Thorin-Oakenpants commented 3 years ago

no idea and I don't want to think about it until dFPI is ready and/or FPI is discontinued - reading non-mozilla people's interpretations/ideas/statements is not always a good thing to do (or waste time on)

It's not worth thinking about until Bug 1649876 (see tom's comment after the one you linked to) - FWIW, I've met Tom, had many an email conversation, he's replied to a few questions at arkenfox, and is super helpful and in the know (mostly: he has shifted teams/priorities a little bit) - but I hate to "pester" him.

I'm just going to wait (and not waste my time on it) until FPI is on it's last legs and/or they want to migrate everyone (in FF) and/or if TB change to a dFPI (hardened or not). FPI is officially abandoned and nothing more will be done: too much work to engineer and maintain both (although they might patch something for TB if it was really broken)

Thorin-Oakenpants commented 3 years ago

1683165 landed. It does not add a checkbox to custom (as per the bugs title), it adds a pref privacy.antitracking.enableWebcompat .. how it all works, IDK and IDC - maybe I'll address it in v93

Edit: Even though I waited two days ... I still spoke too soon - 1728110 ... Add a checkbox to ETP Custom

Thorin-Oakenpants commented 3 years ago

To electorate on #1256 where I discussed service workers

We use FPI. We disable SWers. Tor Browser starts in PB Mode and SWers do not run in Private Windows due to sanitizing issues. AFAIK SWers are not isolated.

Now I see that 3rd party SWers are not used in dFPI, which kind of confirms what I thought about FPI.

So when push (pun intended) come to shove, and we move to dFPI, we can make SWs 2302 inactive

Thorin-Oakenpants commented 2 years ago

almost there

96 or maybe 97 is looking good to leave the FPI train

I suggest readers switch to it now - and migrate your site exceptions to lose the FPI syntax. I'll make a sticky about it closer to the time

Thorin-Oakenpants commented 2 years ago

shim tree: FYI

Thorin-Oakenpants commented 2 years ago

just dumping here for later (edit @fxbrit )

https://old.reddit.com/r/firefox/comments/r4tk76/how_do_i_get_some_of_braves_privacy_features_to/hmjgfd8/

SmartBlock is essentially web resource replacement and is already enabled in Firefox whenever you have content blocking on, which is on by default for desktop private windows, or when you enable strict mode. It basically ships non-tracking, minimal versions of tracking scripts with Firefox as stand-ins for those scripts. (It's also on the roadmap to use it to let users opt into allowing specific trackers on specific websites, to get at the content they want with the least privacy risk).

so what I call shims (web resource replacement) are on regardless as long as tp? is enabled

and the heuristics only applies to Total Cookie Protection (the dynamic part of dFPI)

That seems to make sense to me now. Will confirm it all in time for v96

fxbrit commented 2 years ago

and the heuristics only applies to Total Cookie Protection (the dynamic part of dFPI)

and you don't like that part right? I think I've seen the console print out when shims are being used, I will pay more attention to it.

Thorin-Oakenpants commented 2 years ago

and you don't like that part right?

I'm happy with everything - just trying to understand it all. I'm particularly happen the web resource replacement isn't tied to Strict, but seeing as everyone will eventually be on ETP Strict ,.. it's a moot point and I don't really care :)

Thorin-Oakenpants commented 2 years ago

Would it be too premature or jumping the gun privacy wise to just jump right into dFPI

No. And dFPI has some advantages - works better with sanitizing, covers more things (probably), service workers are isolated (just added to FF96 a few hours ago), is being maintained (FPI is not)

Wouldn't it make since sense to wait for the Tor Browser guys ....

No. TB is not Firefox. TB uses PB mode, arkenfox doesn't. TB desktop is on ESR cycle and can afford to sit back, but FPI will be removed/deprecated and users will be migrated from it. No point waiting and delaying the inevitable for FF users - also everyone else is going to be dFPI (rollout is underway)

that there might be some potential gaps/security risks with trying to make a "Custom" hardened mode

we're not going to be using a custom mode, see #1281, and I'm not going to document and list and maintain all the bits and pieces for tweaking custom

Is there a chance there might be some security/privacy breakage or is it as simple as

I doubt their would be a security issue. Breakage, sure, but it literally can't be any more than you get with FPI.

If something breaks, you click the blue shield in the urlbar - IDK how that then affects the dFPI'ness of the 3rd parties when you reload to unbreak things (this is something I plan to find out) - but lets say it removes the dFPI'ness (so none of it is isolated), well those same 3rd parties would also need to be present in other sites you also clicked the blue shield on. I've never used the blue shield, so I don;t even know if it can be selective or it's all or nothing. But it's no worse that e.g. Brave's shield. But on that respect, FPI had no per site on/off switches. As long as you personally don't disabled it on sites, you're fine

And there is a pref to disable the heuristics part of dFPI (the dynamic bit) which is when it allows some 3rd parties to not be isolated on a site so you can login cross domain on that site - this is per session I think, certainly not permanent (i.e each time requires the user interaction such as clicking a login button)

AFAIK, the TCP (total cookie protection / dFPI) rollout currently underway, would enable that in all ETP modes (don't care about custom) - so that's should be the smart blocking and heuristics as well. Strict mode would just come with stricter lists and other extras like tracker protection

Thorin-Oakenpants commented 2 years ago

FYI

https://privacytests.org/nightly.html

while this doesn't affect us as much (because we're already on FPI), it's nice to know that all FF users will have TCP eventually (I am not sure of the rollout timeframe) - notice the service workers in normal mode. SWers (and IDB) are coming to PB mode too - the idea AFAIK is to encrypt to disk with a session-only key, which is lost on a crash - and to wipe the disk data on close (and previous remnants on open). This would then make it very hard for sites to detect PB mode

on a side note: this also means all FF users will have DNT enabled :)

TCP

Thorin-Oakenpants commented 2 years ago

^ the blob is a bit of a worry :)

ghost commented 2 years ago

@Thorin-Oakenpants What is the difference between Firefox 94.0 and Firefox 94.0 Private ?

Thorin-Oakenpants commented 2 years ago

Private = Private Window

ghost commented 2 years ago

So, TCP does not partition cookies in Normal window till now ?

rusty-snake commented 2 years ago

TCP/dFPI/ETPstrict/"how many names a thing can have" is not enable in normal windows by default.

Thorin-Oakenpants commented 2 years ago

What you are looking at is default Firefox. By default, currently TCP is only used in ETP strict mode (which is used in PB mode) .. but Firefox are going to be rolling TCP out

TCP/dFPI/ETPstrict/"how many names a thing can have"

edit: edit: edit: whack bulleting

ghost commented 2 years ago

@Thorin-Oakenpants, Do you mean They are going to roll out TCP in Normal windows sooner ?

If so, when will they ?

Thorin-Oakenpants commented 2 years ago

I do not know the timeline -> https://bugzilla.mozilla.org/show_bug.cgi?id=1731713#c0

By the end of the rollout program, TCP will be set as default to 100% of users.

Thorin-Oakenpants commented 2 years ago

Note: I have tested setting strict mode from user.js works

FF95/Dev96 new profile

change via about:config to be at odds with ETP strict - we end up as custom

network.cookie.cookieBehavior = 1
network.http.referer.disallowCrossSiteRelaxingDefault = false (default)
privacy.trackingprotection.enabled = false (default)
privacy.trackingprotection.socialtracking.enabled = false (default)
privacy.trackingprotection.cryptomining.enabled = false
privacy.trackingprotection.fingerprinting.enabled = false
privacy.partition.network_state.ocsp_cache = false (default)
privacy.antitracking.enableWebcompat = false
extensions.webcompat.enable_shims = false (hidden pref)
// browser.contentblocking.category = custom <- we end up on this anyway

restart, make sure everything sticks

close, add user.js with 
user_pref("browser.contentblocking.category", "strict");

reopen, do not open settings, open about:config
======
check - network.cookie.cookieBehavior = 5
check - network.http.referer.disallowCrossSiteRelaxingDefault = true
check - privacy.trackingprotection.enabled = true
check - privacy.trackingprotection.socialtracking.enabled = true
check - privacy.trackingprotection.cryptomining.enabled = true
check - privacy.trackingprotection.fingerprinting.enabled = true
check - privacy.partition.network_state.ocsp_cache = true

no change - privacy.antitracking.enableWebcompat = false (default is true in 95)
no change - extensions.webcompat.enable_shims = false (hidden pref)
Thorin-Oakenpants commented 2 years ago

one task to go :)

See updated previous post: these are not changed by user.js setting strict category (or when done via settings UI)

So that doesn't appear to be the case - which isn't an issue for us, we just flip what we want.

I need to check how these two interact: e.g

my understanding is that

Ahh, here's the other pref(s) I was thinking of

https://old.reddit.com/r/firefox/comments/rb2zry/quote_from_latest_950_release_user_agent_override/hnmhgez/

... if you don't want any webcompat interventions, there are several settings in about:configyou can toggle, each mapping to one of the sections in about:compat:

  • extensions.webcompat.perform_ua_overrides
  • extensions.webcompat.perform_injections
  • extensions.webcompat.enable_shims (SmartBlock)

(note that the SmartBlock section might not yet be in about:compat for your version of Firefox, as it was just added recently).

I see no reason to add the top two

Thorin-Oakenpants commented 2 years ago

hmm .. extensions.webcompat.enable_shims (hidden pref) is true in my FF95 (which is using ETP strict), and I didn't set it (pretty damn sure about this), so it must get updated in runtime, somewhere. My tests in a vanilla 95 showed it didn't change from user-modified false via user.js settings strict category, or via toggling strict mode in the settings UI.

Not an issue for us, we'll just enforce it

ghost commented 2 years ago

Given that extensions.webcompat.enable_shims sets itself to true even in a new vanilla profile with no setting changes whatsoever, my highly circumstantial guess is that the mere act of loading a profile to begin with sets the pref to true, since even in Standard ETP, SmartBlocking is turned on for PB. That being the case, I don't think it needs to any special enforcement unless Mozilla changes something on their end. I also wouldn't exactly call it a hidden pref, since it's one of the few showing up as modified on a fresh profile.

It's also worth noting that privacy.antitracking.enableWebcompat seems to be defaulted to true already.

Thorin-Oakenpants commented 2 years ago

extensions.webcompat.enable_shims

privacy.antitracking.enableWebcompat

ghost commented 2 years ago

Well, the funny thing about the value of extensions.webcompat.enable_shims is that even when I don't modify anything, it shows in about:config, albeit as a modified value. When I start a vanilla profile with ETP at Standard, it's true. When I start a fresh profile with ETP completely turned off, it's still showing in about:config and set to true with a user.js of:

user_pref("network.cookie.cookieBehavior", 0); user_pref("privacy.trackingprotection.enabled", false); user_pref("privacy.trackingprotection.pbmode.enabled", false); user_pref("privacy.trackingprotection.socialtracking.enabled", false); user_pref("privacy.trackingprotection.cryptomining.enabled", false); user_pref("privacy.trackingprotection.fingerprinting.enabled", false);

It's always showing as a modified pref regardless of whether it's true or false, but it's a pref that always seems to be visible and set to true in any profile unless you explicitly set it to false. That said, if a user-set false does need an explicit user-set true afterwards to revert it, then enforcing it as true is probably the best route anyway.

Thorin-Oakenpants commented 2 years ago

Right. I took a break and was going to dive into this another day - you're right, it's not hidden in the sense of how we use it, but rather runtime (default true) - like dom.push.userAgentID and a heap of other internal prefs: i.e it is always there

Trying to delete it, it just resets it :) never seen one like that before .. it's spooky at a distance - that rubbish bin icon threw me in my earlier notes

Given my test earlier, we should enforce default true

brand new profile runtime