User.js: FYI: don't use dFPI with FPI [1631676: resolved 78]

[Thorin-Oakenpants]

dFPI (dynamic FPI) is a new cookie setting introduced in FF77

this is network.cookie.cookieBehavior = 5 = "Cross-site and social media trackers, and isolate remaining cookies"

There are potential bugs with it, and you also don't need it if you're using FPI

• 1630796
• 1631676

[gwarser]

Did you skipped https://bugzilla.mozilla.org/show_bug.cgi?id=1630763 because it's fixed?

[Thorin-Oakenpants]

Nope. I just listed the one that says here be dragons (1630976) and the one that will fix it (1631676)

We'll have to wait and see how they apply that patch - I'll be interested to see if we end up with the same situation as in 1607249 (where setting from the user.js was ineffective) and how Enterprise Policy handles it

[Thorin-Oakenpants]

For those wondering: dFPI is a less strict version of FPI which solves those cross-domain login problems. It's work in progress, I'm not exactly sure how they relax some things (might be list based: e.g. YT + google), or what situations it's allowed (e.g. only when logging in?), and I expect it to become the default (way) down the track.

As for what dFPI covers, I am not sure - I think it's just web data (session/persistent storage, maybe workers?) - whereas FPI covers extra things like DNS cache, SSL session cache, HSTS, HPKP, etc - see section 4000

[Thorin-Oakenpants]

The bug has landed .. 18 minutes ago .. sorry for not noticing earlier

[Thorin-Oakenpants]

The fix was is silent - code falls back to FPI over dFPI, pref values are not updated to reflect reality, and it's not even a UI option except in nightly (79 as I type) so clearly not ready

follow up bug is 1637344 - no idea if that will sync reality to pref value, or how runtime vs user.js works

notes for later use

 * 5=(Block) Cross-site and social media trackers, and isolate remaining cookies (FF77+) (aka dFPI: dynamic FPI)
 * [WARNING] Do not use dFPI (option 5) with FPI (see 4001) as they are not fully compatible

[gwarser]

https://bugzilla.mozilla.org/show_bug.cgi?id=1649876 "Migrate FPI users to dFPI"

[rugabunda]

@Thorin-Oakenpants thanks for the info, is there any benefit at this point enabling privacy.firstparty.isolate.use_site, along side firstparty isolation?

[Thorin-Oakenpants]

I would just leave it all alone for now

[rugabunda]

I would just leave it all alone for now

Ok what about browser.cache.cache_isolation? is this compatible with fpi? what would you recommend?

[rusty-snake]

Ok what about browser.cache.cache_isolation? is this compatible with fpi? what would you recommend?

FPI already isolates the cache, there is no need to enable it.

[gwarser]

FPI already isolates the cache, there is no need to enable it.

Last time I checked browser.cache.cache_isolation was experimental. Was it enabled by default for FPI already?

https://bugzilla.mozilla.org/show_bug.cgi?id=1594004

[rugabunda]

browser.cache.cache_isolatio

browser.cache.cache_isolation was not enabled by default by FPI in about:config
https://groups.google.com/forum/#!topic/mozilla.dev.platform/eFx-93iBPpU
https://github.com/CHEF-KOCH/FFCK/issues/26

[gwarser]

And this: https://github.com/whatwg/fetch/issues/904

---

Ah, it was linked in CK issue.

[rugabunda]

I don't like the idea of logons working all the time at the expense of privacy; the feature that is in place already is superior, like with disqus and hyvor, if you want disqus to track you on every site you visit, disable "privacy.firstparty.isolate.restrict_opener_access", and login is just a click away... no headache. The tor developers and users will have none of anything that destroys or weakens privacy, it will be interesting to see what transpires. Tor will fork if need be.

[rugabunda]

And this: whatwg/fetch#904

Ah, it was linked in CK issue.

my question is if this is them re-inventing the wheel with dFPI, or if it actually does have some benefit for FPI

[Thorin-Oakenpants]

I think this whole conversation is becoming confusing and diverging from OP.

There's a lot of changes coming, and I would need a flow chart to understand them: something like this which explains principals

• There's fission (and I saw a presentation by the lead developer of that in June last year): this is more about isolating processes
• There are origin attributes (OAs) and they want to change how that is determined
• There is FPI vs dFPI
• There is a isolation thing: e.g. privacy.firstparty.isolate.use_site
• There is a partition thing: e.g. privacy.partition.network_state

And I have no knowledge of what it all means exactly and how they all work together (or clash)

Here is one of the meta tickets: https://bugzilla.mozilla.org/show_bug.cgi?id=1590107 - partitioning (this includes the ticket gwarser brought up: 1594004)

Now FPI was going to isolate font cache (pretty sure this is the graphics card cache) - that was 1560580, but this has been dropped and instead is covered by partitioning with privacy.partition.network_state (see 1647732)

Are you confused yet? I have some general ideas about all of this, but I'd rather look at an overall design doc: or something like the principals link above: but I don't think anything exists: and instead you have to go down a rabbit hole

As I already said, just leave everything alone: when they're ready, Mozilla will flip things on (and maybe they'll write a blog post explaining something). Meanwhile, nothing they do will (or should) affect FPI/dPFI: my understanding is it can only strengthen it. Some of these changes are independent of FPI/dFPI, so all users can benefit

[Thorin-Oakenpants]

I don't like the idea of logons working all the time at the expense of privacy

if some exceptions are allowed (maybe with user interactions/gestures) such as google.login or whatever, then it's not doing anything more than any other third party (except it's not isolated by the first party) - use uBO, uMatrix in hard mode or something

[gwarser]

my question is if this is them re-inventing the wheel with dFPI, or if it actually does have some benefit for FPI

I'm watching dFPI bug for months now, and still have no idea what it does.

when they're ready, Mozilla will flip things on (and maybe they'll write a blog post explaining something).

Maybe we should create "request for documentation" bug?

[Thorin-Oakenpants]

I'm watching dFPI bug for months now, and still have no idea what it does

Oh. I know what dPFI is: it's basically FPI but with exceptions (edit: and missing some parity until they catch up). What I'm confused about is how exactly the rest works

[Thorin-Oakenpants]

@tomrittervg Read my post 4 comments up. Are there any discussions of the overall arching design of partition + isolation + dFPI/FPI (and I'll assume fission is a completely separate thing to do with processes and memory)

[tomrittervg]

Reading only that comment: hopefully the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1649876 clears things up?

FPI is and will always be the thing it is now. Strict, partitioning (or isolating whatever word you prefer) everything by address-bar 'domain'. ('Domain' intentionally handwavey, see the second bullet below.)

If you enable FPI, whatever dFPI setting you have should be ignored, and you have FPI. The User Interface ought to show you some greyed out option or maybe hide it from you. I am unsure.

Things that may change in the future:

• A few tiny tiny things that never got isolated with FPI (like the font cache) get fixed.
• FPI currently isolates things by top level site, maybe we'll change that to top level origin. (Site: eTLD+1, port; Origin: full domain, port, scheme).
  
  
  
  • This does mean that while today http://example.com, https://example.com, and https://www.example.com all use the same 'jar' for FPI, in the future they might use three different jars. Will this cause more breakage? Unknown. (But probably...)
  
  
• The underlying implementation of FPI moves from the current codebase to a dFPI based codebase, but doesn't change current behavior. This change ought to be invisible but, you know, bugs. So testing is appreciated.
• The storage mechanics of FPI in the cookie jar migrate from storing [example.com||example.com]] for a top level example.com site to [[example.com||]. We would migrate people's data in that case. Again: this change ought to be invisible but, you know, bugs. So testing is appreciated.
• FPI users get some sort of prompt saying "Hey, we built this dFPI thing, it's a little less strict than FPI but hopefully resolves any breakage you have, would you like to try it? [Yes] [No] [Read More]"

[Thorin-Oakenpants]

@tomrittervg

Thanks. Didn't help much (for me), sorry: but that's OK. I know the OA will/might change (site vs domain or whatever), and I get the FPI/dFPI thing (and that dFPI will gain parity in what it covers). It's just slightly confusing that that there are now at least three or four prefs/words to control it all: the privacy.dynamic_firstparty.use_site is slightly ambiguous: dFPI is enabled/disabled by the cookie preference: but I'll assume based on the naming convention that it's only used when dFPI is enabled (note, I haven't looked up the related bugzilla specifically for this, so feel free to ignore me)?

I get it, the new prefs (partition, isolation) are independent and can be flipped for all users, and will eventually be so, right? And TB for example would have to flip e.g. partition (if they backported the code) in order to add font cache protection. But what's the difference between partition vs isolation? Purely for engineering?

new prefs in FF80

pref("privacy.dynamic_firstparty.use_site", true);
pref("privacy.firstparty.isolate.use_site", false);
pref("privacy.partition.network_state", false);

Anyway, no need to answer in a hurry, if at all. As I already said, we should just leave these all alone and that FPI won't be affected. I'm probably asking the wrong questions anyway :)

[tomrittervg]

privacy.partition.network_state

This leaves storage, permissions, cookie jars etc alone but isolates cached and network stuff by site. Nothing that should be observable to a website (except through side channels.)

privacy.dynamic_firstparty.use_site

For dFPI, this adds scheme to the dFPI key.

privacy.firstparty.isolate.use_site

I missed when this landed; I asked in https://bugzilla.mozilla.org/show_bug.cgi?id=1630869 for confirmation, but it looks like this changes FPI to include scheme (but not subdomain.) This hasn't been tested that I know about, but if you're using FPI and are inclined to test, yeah go and flip this one. Fair warning, it may log you out of everything though. I'm going to flip it later when I'm not in the middle of stuff :-p

[Thorin-Oakenpants]

privacy.firstparty.isolate.use_site

I don't have any persistent web data (except I allow about 4 cookies total), and I'd usually to wipe everything (ctrl-shift-del) before closing and flipping: but what the heck, I'll leave em and see what happens. I'll give it a go tomorrow maybe, and I'll keep an eye on site permissions (I have about 12) and extension storage (I remember the 71? issues very well!)

cool: now I know use_site means add scheme

[kah0922]

Don't know when this was added, but this is now in Nightly's experimental preferences list.

Edit: These are all flipped on by default.

[Thorin-Oakenpants]

^^ FYI: that was 1651120

[Thorin-Oakenpants]

@tomrittervg so.....

FPI already isolates stuff: e.g.

• FPI: DNS cache : 1337893

while I appreciate privacy.partition.network_state is doing some new things (font cache, maybe etags and windows.name), it is also doing some of the same things

• partition: DNS cache: 1639247

If you look at the meta ticket for partition, you can see many items that are duplicated: e.g. HTTP Alt Srv, image cache, network cache, etc

So my question is, what happens when both are enabled? Does one override the other? Does one use a different key (site vs domain) and that should be consistent (hence the _site_ prefs)?

[tomrittervg]

If FPI is enabled, it should override privacy.partition.network_state in all cases. Although I admit it's a bit difficult to see how that happens from the code...

[Thorin-Oakenpants]

FYI: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40123

[Thorin-Oakenpants]

FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1669716 - dFPI is also problematic for extensions

[Thorin-Oakenpants]

@tomrittervg (for when you have time)

If FPI is enabled, it should override privacy.partition.network_state in all cases. Although I admit it's a bit difficult to see how that happens from the code...

Just to muddy the waters 1640135 Consider using separate attribute to store first-party domain for dFPI -> 1667440 Should OriginAttributes::EqualsIgnoringFPD look at mPartitionKey (as an example of breakage/incompatibility?)

I said earlier

• There is FPI vs dFPI
• There is a isolation thing: e.g. privacy.firstparty.isolate.use_site
• There is a partition thing: e.g. privacy.partition.network_state

...

Now FPI was going to isolate font cache (pretty sure this is the graphics card cache) - that was 1560580, but this has been dropped and instead is covered by partitioning with privacy.partition.network_state (see 1647732)

I added the partition thing several releases ago: because it covers things FPI doesn't, and I think TB backported those

• 1647732 - isolate font cache (FF80+)
• 1649673 - isolate speculative connections (FF80+)
• and there will be more for sure (like popups)

So some things that were never covered are getting added to dFPI but FPI is being ignored (for lack of a better word). I get that TB can patch, and that Firefox will move to dFPI by default one day

The question: I have zero idea now if the partition pref still works with FPI: i.e seems as if FPI and dFPI are going to be coded as totally exclusive: and dFPI uses those partition and isolation prefs: now they (FPI/dFPI) seem to have a different (origin?) attribute and are totes incompatible?

[tomrittervg]

I checked and the font cache is isolated with FPI. I don't see any indication that speculative connections wasn't _originally_ isolated for FPI (I had thought it was) - that bug just isolates it if network partitioning is enabled.

I don't think anything is isolated for partitioning that isn't isolated for FPI.

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.