Temporary Containers vs First-Party Isolation

Edit: You might be interested in https://github.com/stoically/temporary-containers/wiki/Comparison

---

Filing this as a follow-up to the comments made by @Thorin-Oakenpants here https://github.com/ghacksuserjs/ghacks-user.js/issues/294#issuecomment-377780022 regarding the proposal from @Decopi to add my Add-on Temporary Containers since #294 states discussion there should be avoided and new issues should be filed instead.

First off, let me say that I appreciate the time you took to write your thoughts down on the matter - some of that gave me new insights and I even slightly edited the AMO description to make sure that I don’t make false statements. Thanks for that!

---

FPI (First Party Isolation) already isolates all data by 1st party, the same as if every unique domain had its own temporary container

While it is correct that FPI essentially gets its own container, it should be noted that the container is not temporary. FPI data will remain on disk and is accessible from the First Party until cleared. Since Firefox currently lacks the APIs to clear all data on per-domain basis, it is not possible to make FPI temporary without clearing all browser data.

FPI covers far more than what containers do (e.g. OCSP, HSTS, HPKP, HTTP2, DNS cache and so on) FPI covers more items and is superior when it comes to isolation

Containers also facilitate the excellent work on OAs Origin Attributes, as you already said, and hence are capable of covering the same data FPI covers, however, by design containers indeed don’t cover HSTS (which is problematic because of supercookies, but so is browser fingerprinting in general - and of course, as long as you’re on the same domain, this also works with FPI enabled) or OCSP at this point - however, it is planned to enable that on a per-container basis in the future. Details about this can be found here, including links to the appropriate Bugzilla Tickets.

FPI is so effective, that it actually causes some (not all) cross-domain login issues because some websites effectively use supercookies for their login flow - the usual suspects: major sites that love raping your personal data (google-owned, facebook, etc - here are some bugzillas 1319728, 1336458, 1319839, 1319761, 1319756, 1316019

Containers can allow multiple simultaneous logins and does not block some cross-domain logins like FPI

If you enable Isolation > Global > Navigating in Tabs should open new Temporary Containers > If the Navigation Target Domain does not exactly match the current Tabs Domain (Subdomains also get isolated) in Temporary Containers, you’ll experience the same breakage on all those sites (but are able to manually unbreak that by configuring Isolation > Per Domain). That’s what I personally use.

Indeed, you could even go so far and enable Always, which would make it so that every navigation, even on the exact same domain opens a new Temporary Container. Some people actually have that enabled and that’s why I implemented an Advanced preference to close the old tab in case of Isolation. By default it’ll open a new tab in case Isolation takes place and keeps the old one open (to have the possibility to navigate back, which is lost if you use the “replace” setting).

So some login issues aside, FPI does everything and more that a container does, except…

Containers allow you to use “contain” the same domain multiple times - eg gmail account 1, gmail account 2 Note: PB mode one-off windows can do this, just not simultaneously

Being easily able to open new containers for every new tab (and to automatically contain external links into a new containers) was indeed one of the main motivations to develop the Add-on.

Containers come shipped (default off for now?) with Firefox, and using them in conjunction for one off sites is perfectly acceptable (just like a one off Private Window)

Default off, but are automatically switched on (since Firefox57) if an Add-on is installed that requires the contextualIdentities permission.

Did you see that? If you open FF in normal mode, this allows you to use one off PB windows for a site (not automatic like a container+domain-name, so you have to exercise control), and PB windows (i.e all PB windows must be closed) DO destroy all persistent data on close PB mode (when used from normal windows) is effective at wiping ALL data on close without having to resort to closing Firefox itself.

That was another motivation for the Add-on. Containers are cool, but if you wish to use them as additional measure to enhance privacy, you’d need to manually create them for every new Tab/Domain, remember to delete them and manually making sure that you don’t accidentally stay in the same container upon navigation.

Not sure if this is what is meant by double-keying or not, but FPI can work with Containers and PB mode. Note: Containers + PB mode can not. Without looking it up, it is something like this: (also see #240 )

FPI uses https://example.com^firstPartyDomain=example.com Containers use https://example.com^userContextId=1 PB mode uses ?? not 100% sure, I think its still a ContextId If you have FPI enabled and open in a Container or PB mode https://example.com^userContextId=1&firstPartyDomain=example.com << container https://example.com^??&firstPartyDomain=example.com << pb mode Here’s the key thing: if the OAs (plural) are not equal, then FPI isolates them. So eg example.com+FPI in normal, PB mode and container windows are all three separate FPI isolations

To my knowledge that’s how it works, yes. And that’s also why you can absolutely use FPI in combination with containers to enhance privacy even further.

The second part of your post, about clearing data, I will address in a new comment - because, seriously, the mechanisms for clearing data by host DO NOT EXIST for all persistent data types (AFAIK, and I’ve been digging into this shit for months 😃 ) I am thinking that extensions such as Temporary Containers are using the same APIs etc that other cleaners are using - eg Cookie Auto-Delete. And many persistent storage items do not have sufficient APIs to clear by host or time-range.

extensions that claim to clear (all) data can be misleading, and give a false sense of privacy by leaving behind (orphaned) tracking data

Hopefully one day, EVERY single type of persistent data can be cleared by a single API call by host or time-range and bulk cleared by OA = the holy grail IMO.

Temporary Containers only uses one API to remove data, and that is contextualIdentities.remove - which removes all userContextId tagged storage (including IDB). And even if it’d fail to do so, new contextualIdentities couldn’t access the same data, since the cookieStoreIds (that’s how the attribute is called in the API - it however refers to the userContextId used to OA-tag) are unique as long as the container feature is active.

That’s not what other “cleaners” are doing. Add-ons like CAD try to manually keep track and can (as of yet, more API support is in the making) only remove some limited data with APIs like browsingData.remove or cookies.remove.

But if you’re using FPI, then Containers ofter NOTHING you haven’t already got, just stating the facts

There’s nothing complimentary about them - FPI effectively overrides containers in the sense that the “container” is now useless as a data bucket, because everything is already isolated on a more granular level.

As you mentioned earlier, containers do offer the possibility to separate by OA even for the same first-party domain - something FPI alone can’t do.

I just had a quick look at the AMO page. Its a great extension

Thanks!

---

My personal summary on the matter:

• FPI is great and gives you additional Isolation of OA tagged data compared to containers
• Additionally using containers can make FPI even more effective by also being able to Isolate the same First Party (essentially giving you FPI per Container)
• The Isolation feature in Temporary Containers can automatically create new Containers if a Tab tries to navigate to a third-party. That is especially useful and unique compared to FPI. With FPI, if you navigate to a third-party (which then becomes a first-party), it’ll create its data with FPI OA tag which you can only clear completely (as of now) by deleting the complete browser storage. As you correctly stated, “traditional Cleaners” can’t help here. So, if I happen to navigate to the same “first-party” in the same browser session, then both navigations will see the same data. With Temporary Containers you can avoid that (for everything with userContextId OA tag).

And finally, like you said, everyone has different takes on what level of privacy one wants - it’s always possible to try harder.

Related issues: #8 #91 #97 #240

[rusty-snake]

Fun fact about reaction emojis: I can react to my own post.

[practik]

@crssi: I know you have to toggle privacy.firstparty.isolate.restrict_opener_access to false if you want to log in to Disqus, which is a commenting system – wired.com uses it, among others. That’s the only example of breakage that I’ve encountered in 5 months of using FPI.