move from FPI to dFPI #1051
Comments
Thorin-Oakenpants
changed the title
Also remove the redundant "isolate" in all the tickets. Get rid of the double asterisks (less noisy) and change indent to similar to RFP: note 4000 + 4500 section description indents are different to all the others, but they're also sort of special case
not used with FPI, let it ride the trains or we add it separately along with dFPI and privacy.firstparty.isolate.use_site at some stage
Thorin-Oakenpants
changed the title
|
Intent to ship: Network Partitioning: https://groups.google.com/g/mozilla.dev.platform/c/uDYrtq1Ne3A |
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 |
|
I'd just use Temporary Containers |
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1686296 dFPI rides the train |
|
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 |
|
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 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 [2] |
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 |
|
The recent update appears to have broken certain web functionality, such ass the hyvor comment sections, located at the bottom of the page If using FPI, should we disable these? update quote
UPDATE disabling/enabling FPI again fixed it. |
2701: user_pref("network.cookie.cookieBehavior", 1);
user_pref("browser.contentblocking.category", "custom");
Hopefully by ESR91 we can move to dFPI with some optional hardening knobs |
|
here's a nice write up on STATE tracking: |
Thorin-Oakenpants
changed the title
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. Is this summing-up correct or mere BS? |
|
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
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 |
|
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 edited: fixed up versions mentioned: for some reason I keep thinking stable is 88 right now when it's 87 |
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
|
|
Thanks a lot for your comprehensive replies! Have I told you before that you're truly beyond compare? 👍 👍 👍 In any case my view was definitively too simplistic, it seems :-(
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®exp=false
Yep, you're right. It's the same with the other modes, of course.
So we have to wait until things clear up and more detailed documentation is available. |
|
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 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/
^ 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. |
|
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 |
|
The shims are listed as SmartBlock in about:compat, and honestly, I don't see any reason why anyone would want to flip it to false. I could put it under don't touch (so it gets reset by prefsCleaner). The article you linked also uses https://blog.mozilla.org/security/2021/03/23/introducing-smartblock/ is better, it only states that SmartBlock is shims and it is tied to tracing protection
IDK if smartblock is required true for heuristics to work, and IDCare, cuz we will enforce it as true :) |
|
I think putting it under Don't Touch would be consistent with Arkenfox no longer supporting Custom Mode or messing with the prefs that make up ETP. Edit: Actually, by that logic, setting ETP to Strict could/should go into Don't Touch as well. |
Totally not into testing and supporting any custom ETP configs
True. I'm trying to think of all the things Strict has that Standard doesn't (standard will get dFPI) and there's not much: TP is one, the referer thing. Strict will get font FP protection as some stage. Who knows what else they will add to strict/pb mode (I think strict pb mode are always identical) So there's two sides to that: some people might find too much shit breaks in strict and prefer standard/custom - then what? But from AF's perspective you get the most protections, by default, as they're added I think for now I would like to keep an ETP section, otherwise I'll end up with a single pref for heuristics on it;s own and that would look weird |
|
fwiw I couldn't get was able to reproduce on a clean and existing profile I had to jank strict on like so: |
|
Has there been any indication/statements that Standard will get Enhanced Cookie Clearing along with dFPI as well? (Can't exactly judge based on PB Mode since ECC doesn't matter there.)
The contrary part of me answers that with "that's what user-overrides.js is for." Arkenfox encourages users to override settings that make using Firefox uncomfortable for them (hence the suggestion to set an even bigger window size than 1600x900 with RFP if they want) on a case by case basis. I think it'd be best in the long run to just keep encouraging and relying on Arkenfox users reading the documentation and making conscientious overrides that best suit their own use-cases, and that includes what settings they choose for ETP if Strict is too unusable for them. Arkenfox's own user.js template can (and should, in my opinion) still set Strict as the default and encouraged setting, specifically because Strict gives the best protections, like RFP. Maybe as a middle-ground, Arkenfox could set
Obviously not as good as Strict, but functionally not actually different from going from the default Standard in a clean profile and just flipping the cookieBehavior and ocsp_cache prefs so they at least get dFPI out of it. A quick check of those settings together in a user.js along with Obviously leaving users to "fend for themselves" with ETP isn't what we want, but I also think going with Strict in the template itself should be treated along the same lines as going with RFP and clearing cookies/sessions by default: override if it inconveniences you, but it's the default for a reason. |
Lols. I didn't mean where to do it, I meant I don't want to deal with answering people's questions or fucking around with all the prefs: such as what goes in strict etc
Well, you could enrol in the rollout - but strict is for pbmode which is too tight to land on everyone, and Arthur Edelstein (from Tor Project, then 3yrs at mozilla setting up ETP etc, but recently left) said something the other day to me that made me think dFPI rollout is not ETP Strict rollout (therefore it must be standard)
I can move the cookie behavior pref to ETP and enforce it to make it works
nope. AF is going strict: there is no point pissing around with custom IMO |
Yeah, that's fair.
I wasn't suggesting otherwise. Just that separately activating the cookie behavior pref within Don't Touch could both enforce dFPI (leave it on and don't touch) and still have a separate ETP section for turning on Strict itself, without any conflict. |
trackingprotection is required for dFPI edit: see, this is why I don't want to get into the nitty gritty of all this, and it's forever changing edit2:
no, it needs TP edit3: see #1051 (comment) |
|
Also, if anything breaks, you can use the Shield in the urlbar |
That's me told then. I was under the impression that dFPI was just the cookiebehavior pref, not the broader tracking protection ones as well. |
|
I could be wrong, fuck knows :) Arthurs statement suggests otherwise
But the FF article says
Now that doesn't mean that TP must be on for the list to be used. It will be interesting to see what the rollout to TCP actually does Once the rollout is done, and everyone is on TCP, then we can maybe look at supporting custom: but initially to keep it simple, I am only going to move forward with Strict Mode - just like in the past we only had one FPI |
|
re: 8cdb30c something somewhere appears to always set to standard on first launch, even on plain vanilla firefox to have strict persist seems all of these prefs must be default: on topic: also for documentation purposes: |
|
musical chairs .. i'm moving it back :) |
|
I added /* 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]the link perfectly describes how it provides "local stand-ins for blocked third-party tracking scripts" and mentions nothing about the relaxing of dFPI for cross-domain logins. So I'm happy with that but not sure how to word this though /* 2702: disable SmartBlock heuristics [FF93+] <- need something better
* heuristics something user-initiated something SSOs / cross-domain logins
* relaxes state partitioning for that site
* it is session only?
* [SETUP-HARDEN] blah blah what do I say in here
* [1] https://blog.mozilla.org/security/2021/07/13/smartblock-v2/ ***/
// user_pref("privacy.antitracking.enableWebcompat", false);
|
|
Assuming I understand the pref correctly, maybe under SETUP-HARDEN you could say something like "Setting this to false ensures explicit user approval is required before Firefox relaxes its tracking protections for better site functionality?" |
|
Assuming I understand the pref correctly, when false it stops the ability to relax 1st party isolation, not stick it behind user gestures (which is what it is behind by default) |
|
I'm mostly just going off of this bit from the first comment in the Bugzilla link:
Looking at it again though, I'm starting to think I misunderstood it. (Why does this have to be so confusing?) |
Until this week I have never bothered to dig into it, because we were on FPI and had plenty of time for it to mature etc. I don't think it's that confusing - we just need to read it. I shall DIG like a grave robber - but any help is welcome :) My gut instinct when I first saw the issues, was that they don't want a full TCP off switch - there are already ways to do that - ETP custom, and Here is a ticket
so both, to me, say webcompat, heuristics, and the last says "skiplists" - what exactly are skiplists? There's also a ticket for dev tools
But I could be wrong. I guess it's a case of lots of reading and seeing what tests they have written
It's all a bit ambiguous - does it skip the item and allow it, or skip the item and block it. So fucked if I know at this point. I'm probably wrong - hardening would the least of their worries |
|
https://phabricator.services.mozilla.com/D123663 - abandonned patch
that was the intent - to harden. which is what we want. There's a ticket somewhere about tightening up user-initiated stuff, and I suspect skiplists and automatic grants and storage etc are things allowed to unbreak websites - because they haven't added enough shims (e.g. login at FB). So I read everything so far as being hardening. I mean the pref for disabling skiplists, which was marked as a duplicate for our webcompat pref, was for testing, but now I read that both ways |
|
Thank you for making Arkenfox. I have some comments:
No, ETP custom settings are also applied in Private Browsing mode (FF95):
That is correct IMO, the setting: Blocking Cross-site cookies = Total Cookie Protection (TCP).
Ok, but this change (custom->strict) means a protection downgrade from AF95 (Blocking 3rd-party cookies) to AF96 (Allowing 3rd-party cookies with TCP).
IMO the AF95 defaults are better, because I never need 3rd-party cookies. |
tl;dr⭐ AF is not supporting FPI anymore: DON'T TOUCH Lines 1101 to 1104 in 7016c20 ⭐ AF is not supporting anything outside ETP Strict: DON'T BOTHER Lines 1207 to 1215 in 7016c20
⭐ IDCare - AF is using Strict, and PB Mode by default uses Strict notes
its not 100% but normally a non-pbmode pref overrides but only when it makes it more strict example
example
ETP is more complex, but I doubt they downgrade anything in PB Mode just because a user changes some UI settings
⭐ IDK and IDCare anymore: - AF is using Strict notes
⭐ Just don't! This is a false dicotomy We could just as easily use FPI and allow all cookies as well. No difference. The creation of site data does not negate FPI/dFPI. Protection is still the same - isolation has not changed. Who cares about 3rd parties when they are isolated. So what if they create a 3rd party cookie - it's no worse than a first party cookie notes
|
@Nallua
What do you exactly mean Thorin? There is Enhanced Tracking Protection(ETP) and one of the options within ETP is 'Tracking content' which can be turned on or off in ETP. When you talk about tracking protection, do you mean ETP of just the 'Tracking content' option? dFPI is a name for State Partitioning which is called Total Cookie Protection(TCP) in Firefox and because of this partitioning you get some tracking protection in general, but I don't read anything about the required 'trackingprotection' you mentioned? Why is tracking protection required? |
and subsequent notes about that |
|
I'm just trying to figure it out, I understand you will not bother because you will use strict anyway. I prefer not to use the strict setting because of the 'Tracking content' option, I prefer to use and trust my own ad-blocker. And besides that, 'Tracking content' breaks things that are supposed to be fixed again with SmartBlock, which even insert new privacy friendly scripts. I have my doubts about this solution and besides this all I never had problems with uBlock Origin. So I prefer not to use the 'Tracking content' option in ETP and I have to chooce the custom ETP setting. But apparently ETP strict does more than just the 4 checkboxes you can select in custom mode. I have seen your comments, for example:
I searched on this pref for some explanation and maybe how to set them manually. https://bugzilla.mozilla.org/show_bug.cgi?id=1529517
Or: https://wiki.mozilla.org/Firefox/Meeting/9-Apr-2019#Privacy.2FSecurity
Obviously some old code.. no idea where to find something newer, so I have to figure out wat |
No you don't understand because just asked me I am not interested Since it's practically just me (and E providing diffs), then I get to decide what the fuck I do. I will only support ETP Strict |
ToDo:
privacy.antitracking.enableWebcompat- see some dFPI questions #1337 & ac0820aextensions.webcompat.enable_shims- c8c8626privacy.partition.serviceWorkerscurrently only true for NightlyCleanup/Tests
network.cookie.cookieBehaviornetwork.http.referer.disallowCrossSiteRelaxingDefaultprivacy.partition.network_state.ocsp_cacheprivacy.trackingprotection.enabledprivacy.trackingprotection.socialtracking.enabledprivacy.trackingprotection.cryptomining.enabledprivacy.trackingprotection.fingerprinting.enableddFPI bugzilla tree
&hide_resolved=1to get the full listoriginal message
comment
There's no point enabling/adding the partition pref/info to section 4000
what we had for posterity
The text was updated successfully, but these errors were encountered: