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

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

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]”

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

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

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

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

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.

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