ETP switches and dFPI

[ghost]

So FPI will make way for dFPI in version 96. I had some silly questions and since there is no separate Q&A section, here's new issue about it, similar to #1306

Will dFPI get disabled if I turn off ETP on any given site? I think site isolation will work fine, disabled for one site but for on for others. Is that the case?
I do this on a site so images can load properly(mind uBO is left untouched). Right now since FPI is enabled, never really bothered to care how ETP switches affects stuff on sites.

Currently in ETP section, I have selected custom mode with third party cookies disabled and all other options enabled. How will that change in strict mode?

Plus Temporary Containers is no longer recommended. So is there an alternative for it or put it another way, it can still be used right, just not as ultra privacy add-on?
I used it most on a streaming site which allows to view 3 videos, after which it asked for login. Thanks to TC I just created another container and all things worked fine. Obviously this is done in a different profile(with no changed prefs) for DRM.

[Thorin-Oakenpants]

Will dFPI get disabled if I turn off ETP on any given site?

I assume you mean the urlbar blue shield - This is something I want to confirm (I did mention it somewhere and I thought it was on my list - I just added it), but the answer is likely yes - it's meant to unbreak sites

At first I thought it was just the Tracking Protection (TP) which is one part of it. But even in standard mode, which doesn't have TP, the urlbar still has a toggle

In about:preferences#privacy when strict is enabled it says (emphasis mine)

Heads up!
This setting may cause some websites to not display content or work correctly. If a site seems broken, you may want to turn off *tracking protection for that site to load all content. Learn how

The link doesn't make anything clearer - it says

This will turn off Enhanced Tracking Protection for this site

So IDK the exact answer, it will be covered in the user.js in time and is listed in my ToDos in #1051

One way around this (if ETP exceptions disable dFPI) would be to use Multi-Account Containers and assign those few sites into their own containers

---

Currently in ETP section, I have selected custom mode

Custom mode was touched on in #1306 - AF is not going to maintain and support stuff about custom mode

I do not fucking care how it works and what prefs you can change to alter custom, or change strict. Since I am the only person doing all of this (aside from E providing diffs), and have been for the last year and a half (or longer), I refuse to deal with any of it. STRICT mode is going to be it. STRICT is literally named the hardest setting. Considering we were FPI for 4 years, I don't think anyone should give a shit about relaxing down to custom

---

I used it most on a streaming site which allows to view 3 videos, after which it asked for login

Just use Forget About This Site: it sanitizes it and your count will resume at 0.

• hamburger > history > right click history item > forget about this site
• customize toolbar, drag Forget button to toolbar

[ghost]

Thanks for clarifying, cheerio.

[Thorin-Oakenpants]

Just use Forget About This Site

or use one off Private Windows. When all Private Windows are closed, everything for PB is cleared from memory

[Thorin-Oakenpants]

What's wrong with Temporary Containers anyway?
Obviously asking to use in a relaxed profile and not as ultra privacy add-on to reduce FPing.

FPing is a stateless tracker, TC has nothing to do with this. TC, TCP (dFPI), FPI, network partitioning, containers are all about isolating state tracking

[Thorin-Oakenpants]

correct - the wiki says

• Temporary Containers, Cookie extensions
  • Redundant with ... snip
  • ❗️Sanitizing in-session ... snip
  • ❗️Cookie extensions lack APIs to work with Total Cookie Protection which will be the default

moving forward, I am not going to support FPI questions - it is no longer maintained. Mozilla's state partitioning and FPI are two different code paths, and upstream is not going to bother with both

/*** [SECTION 6000]: DON'T TOUCH ***/

user.js/user.js

Lines 1103 to 1106 in 2787da7

	/* 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]

FPI is pretty robust, but it does not cover service workers, which we now enable. That then means it becomes a recipe involved multiple prefs and yet more maintenance/support - such as dealing with OA syntax in FPI

[Thorin-Oakenpants]

anyway ... TC is still redundant with FPI

[crssi]

TC doesn't work with dFPI, I should've read full details on extension page.

I don't see it that way. Where did you find that out?

[crssi]

I should've read full details on extension page

^^ I am interested in this. Where on the extension page, what full details? Do you have a direct URL to that?

does TC work with dFPI?

I don't see why wouldn't. When a new tab/containers opens it has a clean namespace, but TC does not prevent connections that are not user initiated to be opened in any direction, where on the contrary dFPI do (AFAICT).

Actually, what do you exactly mean with "work with dFPI"? That the TC does not work anymore as extension, that does not meet your requirements/goal?

[crssi]

I think TC should not work with dFPI

I don't see a reason why not.

Even if TC has been updated to support dFPI, it was last updated on Feb 8 on add-on store

I don't see a reason that TC should have any special adaptation for dFPI, I think it should work out-of-the-box on as it is now.
Also when the extension was updated long time ago, that doesn't mean its crap... it might also mean that it was done so good that there is nothing to correct, at least not at this moment.

[Thorin-Oakenpants]

TC uses a different API for sanitizing

• Temporary Containers, Cookie extensions
  • Cookie extensions lack APIs to work with Total Cookie Protection which will be the default

The bugzilla linked is about the extension's "cookie" API or whatever you want to call it

At the API level, I am considering to introduce a new method to allow extensions to get the expected cookie jar (e.g. firstPartyDomain and/or the extension API representation for partitionKey) for a given tabId / frameId. I am considering this, because it is not really obvious which keys an extension should choose when they read or write cookies for a specific document.

^ edit: tl;dr: Add partitionKey support to cookies extension API

• this is why dFPI is broken for cookie extensions

None of this changes the fact that they are both redundant

• TC doesn't need to isolate anything
• Both (TC and cookie extensions) are not sufficient to create new IDs and is a false sense of privacy. Bad OpSec

[Thorin-Oakenpants]

dFPI and FPI are mutually exclusive

only in how the browser decides how to partition. this has nothing to with extensions. The problem with extensions is that each method needs to added to the cookies extensions API. Pretty sure FPI was lacking initially. Currently dFPI is lacking

[crssi]

First we're all sporty here right, just having a normal chat.

But of course 😄

Whats in my mind is that it depends what are the reasons to use TC.
In my work I need to be logged on to same web site as a different user (admin, test user, me as myself, etc...) at the same time and I think here the TC will still do the trick opening several different containers to the same destination.