Temporary Containers vs First-Party Isolation

[stoically]

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 #294 (comment) 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

[Thorin-Oakenpants]

Thanks for this @stoically . Much appreciated. I will read (haven't yet) but not reply right now as I think it's better to digest and think about it, rather than regurgitate anything I said in the other discussion.

I've never looked at TC before, and only had a very quick (30sec scan) of the AMO description basically after I had written everything. Basically, everything said so far was about my knowledge on FPI and containers as shipped in FF, and my knowledge of how FF allows sanitizing. Sorry if I meant to imply anything was iffy re your extension. My point was i need to vet if i am going to recommend it.

[Thorin-Oakenpants]

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

Ahh yes. That's what I called 1st party tracking and I brought it up. I also only just commented that in TC (not plain containers) that if it was new ContextId per visit then this brings something new (and a better solution IMO) to the table

[Thorin-Oakenpants]

so much for me shutting up for a while 😁 just making notes as I read OP

but so is browser fingerprinting in general

So is leaking your IP by not using a VPN etc. I do not find that relevant :)

---

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).

Just focusing on the isolation factors : If you have FPI enabled, then you won't unbreak it, right!?. And configuring Isolation > Per Domain is the same as FPI, right?

---

Just asking: Lets say a user doesn't enable FPI (they do not even know it exists, they have never heard of about:config, it is default false for a reason = the bulk market). They only know about and care about Containers. They are in Isolation mode that breaks logins. Can they set Isolation > Per Domain on a whitelist to unbreak the login failure?

---

Why bother to sanitize when in Isolation>Always? Just thinking out loud...

---

Not sure if this is what is meant by double-keying or not

I actually think double-keying is the OA. i.e the first key is the domain, the second is the OA. The fact that some OAs can be chained is a bonus

---

Temporary Containers only uses one API to remove data, and that is contextualIdentities.remove

Yes. A couple of my comments/questions were about this. I wondered how PB knew what to remove. I'll quote myself on one of them

I am not 100% certain that some ContextId data types that can't be cleared by host, can't be cleared by OA, so correct me if I'm wrong

You just answered that. contextualIdentities.remove can clear IDB by contextid. Nice ❤️ I'm learning new stuff too, thanks. Sanitizing is only going to get better. Makes me wonder why PB mode doesn't allow IDB yet - do you know what PB mode uses as its OA?

[stoically]

So is leaking your IP by not using a VPN etc. I do not find that relevant :)

I just found it relevant because I personally think that everything that is used to identify or track you but isn't an "official" storage API (like cookies and localStorage) is to be considered fingerprinting (also including IP or UA).

Just focusing on the isolation factors : If you have FPI enabled, then you won't unbreak it, right!?. And configuring Isolation > Per Domain is the same as FPI, right?

With FPI enabled you can't unbreak in this case, that's correct. Strictly speaking, you can't achieve the same effect with containers as with FPI currently because of not included HSTS and OCSP in the container OA - but other than that is configuring Navigating to does not exactly match under Isolation > Per Domain or Isolation > Global basically the same as FPI - but per Container ("preventing" 1st party tracking).

Can they set Isolation > Per Domain on a whitelist to unbreak the login failure?

Yep, that's possible. However, currently its only possible to disable (Never) or relax ("include Subdomain") based on the "source domain" (the one loaded in the Tab) and not separately only for specific Target Domains. But it's on the list.

Why bother to sanitize when in Isolation>Always? Just thinking out loud...

Essentially removing old Temporary Containers (I'm assuming that's what you mean with "sanitizing") isn't really necessary at all, right. However, you could open an old TC again (since they're just normal containers from Firefox's perspective) using the normal container UIs (native or with e.g. Multi-Account Containers) - so it's a potential privacy risk and hence they get removed. On top of that it would clutter storage heavily especially if you're in Automatic Mode and/or use the Always isolation preference. Besides that it makes for some neat statistics (if you enable them). 😁

Makes me wonder why PB mode doesn't allow IDB yet - do you know what PB mode uses as its OA?

Afaik the OA for PB is ^privateBrowsingId=1. The cookieStoreId from the WebExtensions API for PB is firefox-private (firefox-default for the default container and firefox-container-N for containers). Some discussions why IDB is disabled in PB altogether (and concerns about how that makes PB users easier fingerprintable) are in 781982.

if Temporary Containers assigns a new ContextId (#294 (comment))

That's what's indeed happening by using contextualIdentities.create, yes.

[stoically]

Two additional things from #294 (comment) I want to address:

I also wouldn't include the word security - this is all about privacy.

Containers actually do something for security too, like also described under Benefits and Use Cases in the official document:

Isolates a site's credentials to a container, helping prevent CSRF, clickjacking, or other attacks which rely on the presence of ambient credentials.

• A user has their online banking sites open in the banking container. An attacker attempts to exploit a CSRF by tricking the user into clicking a link on Facebook (open in the Home container). The CSRF is sent without the bank's credentials and the attack fails.

then that would mean each instance of a same-domain visit would be a new isolation (obviously no existing tab of that domain should be open)

It doesn't matter whether there's already the same First Party loaded in another Container Tab. Thanks to OA they wont see other data from the same First Party - because they have different OA tags (userContextIds in this case).

[Thorin-Oakenpants]

You've obviously worked a lot with containers/contextids. I am probably misunderstanding some features or configs in TC. I need to load it up in a nilla profile and have a play, and read thru items in your repo, which is starred.

Thanks for the PB OA info - it bugged me not remembering what it was :) PB not using IDB is a PITA (especially with Web Extensions that use IDB) and a small part of why we do not recommend starting in it (the other is lack of control over cookies etc). They really should have sorted that out ages ago.

Sanitizing - its what I call removing all that persistent data within the scope of what we are talking about - one of Mozilla's cleaning up modules is called sanitize.js. That said, in our context, I'm talking about data set by websites - namely cookies, localStorage, IDB, appCache, service workers cache. There are of course other persistent data such history (I see you have a feature for that), site permissions, saved passwords, form data, CAs etc.

I can see some possible problems/barriers (I need to check them first), but I can definitely see a TC config that absolutely adds more privacy (to our user.js, which is only a template, we can't control what users do with it).

It doesn't matter whether there's already the same First Party loaded in another Container Tab. Thanks to OA they wont see other data with different OA tags (userContextIds in this case).

I need to try it out and stop asking generalized questions, it's just muddying the waters :) I need to understand what exactly each mode does, and to specify under what mode something works or breaks.

Thanks for your input 💋

[Thorin-Oakenpants]

I read your Fingerprinting section at the end on AMO. Some points

Panopticlick, AmIUnique etc, while they give values for certain metrics and are useful for looking up bundles of info in one hit, are useless in determining how unique you are right now, in the real world. See #352 . People get so hung up over the user agent (years of data which is not static), or do not realize for example that if spoofing a unique canvas on every request, that their entropy will always be unique.

Firefox, via the Tor Uplift, has a pref we call RFP (privacy.resistFingerprinting). This aims to lower entropy (not raise it) by first limiting precision if feasible, then spoofing values, and lastly blocking outright. The whole KEY to RFP is that users in the RFP subset are all the same (all it needs is significant numbers to buy into using it). Fiddling with FF to do what has already been invented, will only make matters worse.

FP is over-hyped, in the sense that other factors (assumed) should be done first - such as blocking 3rd parties, disabling JS, etc. Even some server side tracking can be thwarted with FF prefs (eg SSL session id tickets).

Also consider that it's taken a very very long time, with regressions and backtracking on decisions, to even just get the UA spoofing right (and it still isn't fixed). Don't waste any time on adding unneeded feature creep to an extension that's core feature is enhancing containers

You've spent a lot of time with containers etc, I've spent far too much time on FP'ing (5 or 6 years). Trust me, you do not need to waste resources on this. Solutions already exist, especially the RFP pref one, which can do things that extensions cannot, since its baked into the code. Not only that, but it has patched long standing holes in eg navigator (which only applies when RFP is enabled).

TL;DR: waste of time

• it's extremely complicated and takes a lot of work
• its already been done, a thousand times
• is already available in Firefox behind a pref
• or an aspect of it like canvas has special dedicated extensions
• deviation from RFP can easily render RFP useless (so your features may just screw things up )
  • we even have an RFP alternative section in the user.js, all inactive, so users know these should be at default when using RFP
• takes away resources from the core functionality/purpose of TC

FP'ing will never be fully defeated IMO. The only way to do it properly is via OpSec. While definitely a threat, it's massively over-hyped, and other measures are far more effective (eg 3rd party blocks, JS off by default, about:config prefs) in sticking you in the too-hard-to-do basket for tracking companies . There is way too much lower hanging fruit and companies will not waste time and money on it. 95% of users out there willingly give away their tracking. Not saying we don't work on defeating it though :)

[Thorin-Oakenpants]

^^ not knocking anything, just don't want you to waste you time and resources :)

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

Out of curiosity, what did you change?

[Decopi]

Hi @Thorin-Oakenpants !

I always used FPI+Container without add-ons.
First time I saw T-C add-on, I was skeptic, not about the Firefox' Container usability, but skeptic about the T-C' add-on functions.
I decided to test T-C add-on, and was using it that I found the value of this add-on.
The fact I can open 50 tabs in 50 separate and different containers, everything automatically and in seconds... and the fact that after closing containers in "x" configurable minutes, content is wiped (or at least most of the content)... these facts caught my attention on T-C add-on.
Expert users always have many different ways to do something. But in real world, average users don't have alternatives. T-C add-on can help average users by automatizing all process, improving privacy/security.

In my case, the value of T-C add-on relies on both: "The usability of Firefox' Containers, improving privacy/security" mixed with "Expansion of Firefox' Containers functions".
As you said, it is not the Holy Grail, but for a lightweight 350KiB add-on... T-C adds good privacy/security improvements for average users.

@Thorin-Oakenpants It is great to see you able to vet/review Temporary-Containers add-on. Thank you for your time/attention. I do liked your comments:

"I am probably misunderstanding some features or configs in TC. I need to load it up in a nilla profile and have a play, and read thru items in your repo, which is starred."

"I can definitely see a TC config that absolutely adds more privacy (to our user.js, which is only a template, we can't control what users do with it)."

[stoically]

@Thorin-Oakenpants

I absolutely agree. That's why

• I've only mentioned measures against Fingerprinting that don't revolve around tweaking the browser, but instead just: Tor Browser, Different Browsers or Profiles, VMs or even different Hardware
• I'll only introduce fingerprint resistance features in TC if I can switch on well-proven configurations, like resistFingerprinting on a per-Container basis. Be assured that I don't bother with implementing half-baked stuff that effectively only makes you more unique

Out of curiosity, what did you change?

I've changed

• "the data" to "data" in the short-description
• "isolates all local data" to " isolates local data" in the "privacy?" section. Although it links to the Containers document, I guess "all" can be misleading
• Explicitly added "except HSTS and OCSP" to the OA list
• And just now "The less extreme approaches are different profiles or browsers, with significant different configurations, Add-ons and User-Agents." to "The less extreme approaches are different profiles or browsers, with significant different configurations.". Although I actually mean different Browser Versions with User-Agents in this case, that might be misleading too.

[Thorin-Oakenpants]

Ahh OK. I misinterpreted your intentions about building in anti-FP'ing measures. Probably because (and no offense) I see you have some referer stuff, and history cleaning, and I see that as feature creep.

That whole FP section is bit naff IMO :) don't hate me cuz I'm beautiful. A lot of it doesn't quite ring true, and its confusing, especially to laymen. As for enabling RFP, the pref is exposed for you in the Privacy API. It will get an about#preferences UI soon (I'm guessing FF62 now, more likely 64)

Not sure of you meant this, but I would not flipping it on/off for various domains/contextids (js can run on any tab at any time, so you risk leaks), and I would not recommend it being turned off anyway as it protects so much. The whole point of it is that everyone buys into all the time.

At the moment it will be probably be changed from boolean to integer, so it can have 3 states: off, all windows, PB only. Ticket is 1404017

---

FPI same story: 1397624 - this ticket is where you should be. Maybe they can build in an option for FPI & containers - ask em :)

[stoically]

Probably because (and no offense) I see you have some referer stuff, and history cleaning, and I see that as feature creep.

Referer stripping is implicit to how TC works. Because Navigations get reopened and only the GET URL is used to open the new Temporary Container Tab, all Header informations are gone. I'd have to implement a feature to change that, actually. 😁 Deleting History like it is currently implemented is just a workaround until per Container History is supported (1283320). I don't see the feature itself as creep, because if I open a Temporary Container, I'd expect to have at least the choice that the history is temporary too.

A lot of it doesn't quite ring true, and its confusing, especially to laymen

Guess you're right. Moved the section into the GitHub Repo and only placed a link on AMO. Will look into adding some links to the Wiki article that are better resources. Would be cool if you have recommendations.

As for enabling RFP, the pref is exposed for you in the Privacy API.

Right, I'm aware. However, it's a global setting and hence would not only affect TC - so in it's current form, I personally think it's out of scope for TC.

Not sure of you meant this, but I would not flipping it on/off for various domains/contextids (js can run on any tab at any time, so you risk leaks), and I would not recommend it being turned off anyway as it protects so much

The way I personally see it is that, being able to switching on resistFingerprinting just for Temporary Containers would be great. My browsing in Permanent Containers is uniquely identifiable anyway most of the time, because I'm logged in, enabled 2FA and such things. I choose to give up some of my privacy in them - would be great if it could be made not so easily linkable to my TC browsing. The only way to currently achieve this is having one browser just for TC with resistFingerprinting and one for permanent containers - which is not exactly convenient.

Thanks for ticket pointers!

[earthlng]

@stoically wow wow wow what a fantastic addon! Great idea for an addon and very well implemented with lots of settings, super clean code, very nice and polished Options page, incredibly detailed "About this extension" page, I mean just WOW. The amount of work and thought you put into this is amazing. Thanks!

[Thorin-Oakenpants]

I've adding TC to the wiki - its a great extension. Sorry if I came across as doubting (not the extension itself, but what the APIs could cover) - I'm like that, always questioning. Even if it didn't offer extra, it still offers alternative ways to "contain/isolate" and sanitize.

---

added as follows: wiki page link

• Temporary Containers ^{✔ Privacy (stated on AMO)} | GitHub
  • This can achieve almost everything First Party Isolation (FPI) does without breaking cross-domain logins
  • In an hardened setup, this can even isolate repeat visits to the same domain, which FPI alone cannot.

---

^^ I didn't want to go into details. With Web Extensions API still needing further work, it will be a little while until sanitizing, containers etc can reach full potential. If you think the two bullet points can be better worded, let me know. These are the two main things that matter IMO (trying to keep it really short) - 1. as an alternative 2. adds something (I did not state with or without FPI)

PS: I still haven't tried it out yet - soooo busy. Plus in my setup, I would not benefit from it (yet)

@stoically 💋 ❤️ 👍 Keep up the great work

PPS: I didn't check for web_accessible_resources or for TC or MC, or MC's privacy policy - someone else can do that

[Decopi]

Congratulations @stoically ! I believe that at TC add-on/extension page, you should mention the addition of TC to the Wiki.

[Thorin-Oakenpants]

^^ actually @KevinRoebert did that which i only noticed the other day - see https://addons.mozilla.org/en-US/firefox/addon/clearurls/ .. scroll down to A recommended extension... . Thank you Kevin 💋 a very nice touch and succinctly worded

TC is very pretty well known already (4K+ users) - we get over a 1K unique visitors here per fortnight. Hope we drive some more traffic and users your way. Your AMO is already long, don't feel oblligated in any way, we're fairly niche but probably fit your target market :)

Also, IF you want more exposure, I can hook you up with an article at ghacks.net (you can most likely write it as a guest writer - Martin Brinkmann is a super cool all round good guy and very accommodating )

[Thorin-Oakenpants]

PPS: 💋 for @Decopi too for bring this all up. It was high time we got around to it (note the timing of the Facebook data "scandal" and sudden interest in containers - eg launch of FB container etc)

[earthlng]

1. as an alternative

It's not meant as an alternative to FPI, you can use both in combination.

Instead of the 2 bullet points I'd just copy or paraphrase this from his github readme:

Detailed informations about the Add-on can be found on AMO. There's also this long-read article and some informations are available in the Wiki.

He explains everything in great detail and the 2 bullet points don't do it justice IMHO

[Thorin-Oakenpants]

It's not meant as an alternative to FPI, you can use both in combination.

Its meant as both. As an alternative it solves the cross-domain login problem (which will NOT be solved by the Tor Uplift - privacy.firstparty.isolate.restrict_opener_access is being removed as well - its an unsolvable problem due to the login flow using evercookie techniques) . So it offers a viable alternative to some people. As a combo in a hardened config it can offer same-domain repeat visit "isolation", so it enhances FPI in that regard. Users can make their own choice what to do.

^^ I really feel that these two things are really important for consideration .. fk, I used the word really, edit: sht, did I really use it twice in the same sentence

The AMO is already linked. But for sure, we can always improve what I wrote (eg I didn't mention any shortcomings that containers have over FPI), but I didn't want to write too much. Rather than tinker with anything right now, lets wait for @stoically :)

[Thorin-Oakenpants]

changed it (for now)

• Temporary Containers ^{✔ Privacy (stated on AMO)} | GitHub
  • This can achieve almost everything First Party Isolation (FPI) does without breaking cross-domain logins
  • In an hardened setup, this can even isolate repeat visits to the same domain, which FPI alone cannot
  • Required reading: [1] AMO description [2] Article [3] TC's Wiki

[crssi]

hmmm... @stoically archived TC project.
I hope he wasn't scared away. 😞

[Thorin-Oakenpants]

Because the two lines wrap awkwardly, I made them into a single bullet point, slight word changes. looks way better now

[stoically]

@Thorin-Oakenpants @earthlng

Thanks for adding TC to your Wiki. I've added

You might also want to check out github.com/ghacksuserjs/ghacks-user.js, which has comprehensive informations regarding Firefox configurations and a list of Add-ons.

to the TC AMO. Let me know if you want to see something changed.

@crssi Unarchived again. Currently haven't much time to work on TC and thought archiving might be good idea, but since I plan to work again on it in the future it might give the wrong signal.

[Thorin-Oakenpants]

@stoically 💋

[curiosity-seeker]

FWIW, I've started the test on http://ip-check.info/index.php?lang=en twice.
The first time with FPI only - result: Tab Name and Local Storage are reported as not protected.
Second time with FPI + TC - result: Tab Name and Local Storage are protected.

This suggests that TC makes the Conceal window.name script superfluous.

EDIT: Tab History is reported as not protected. However, only the sites previously opened in the same temporary container - i.e. sites within the same domain - can be detected. This suggests that TC makes the Conceal history.length script superfluous, too.

[Thorin-Oakenpants]

^^ Cool

I plan on using TC myself at some stage (soon - been following all the issues etc). It's almost the solution, but I also see another answer coming in Storage v2 and the new Forget Site code (except it wipes site passwords and permissions) etc - when its all done, they could open it up via an API and it would be a single call (by host, or by time range).

window.name is planned to be covered by FPI but currently isn't. TC clears history (for that container, or for that domain as it closes? it would make a difference if used multiple domains in a set container) I believe, hence history is "hidden" and history.length is not needed

[curiosity-seeker]

window.name is planned to be covered by FPI but currently isn't.

Thanks - good to know!

TC clears history (for that container, or for that domain as it closes? it would make a difference if used multiple domains in a set container)

I'd say: for that container. And multiple domains in a set container are only used if you chose "Never" in Isolation -> Global -> Navigating in Tabs should open new Temporary Containers , IMO.

[atomGit]

Atavic pointed me to this thread in reference to a question i had - i read all this before and read it again now, but i'm not seeing an answer

scenario... FPI is enabled - you visit a domain - then you disable FPI and revisit that same domain

does the data from the first visit remain isolated from the second?

i realize that with FPI enabled, data for the second visit would go into the same container for that domain, but what happens when it's disabled?

[Thorin-Oakenpants]

does the data from the first visit remain isolated from the second

yes. because the origin attributes have changed

No containers, no FPI
https://example.com=example.com

No containers, FPI enabled
https://example.com^firstPartyDomain=example.com

in a container, no FPI
https://example.com^userContextId=1

IN a container, FPI enabled
https://example.com^userContextId=1&firstPartyDomain=example.com

If the OA is different then it is isolated. FPI also works with Private Browsing mode. PB mode is another OA. The only combo that can't work is Containers in PB Mode.

Note, that just because you change your OA, that doesn't mean the "old" (other isolated/OA'ed or zero-OA'ed) data is removed - it's still there. So if you went to goats.com in normal default FF ... and got a cookie, then you switched to using FPI ... you would get a new cookie, but the old one would still be there if you ever switched FPI off.

[atomGit]

thanks for the explanation - that makes sense to me

[crssi]

@atomGit is there any reason to disable FPI? Asking out of curiosity, since I have no problem at all with FPI enabled.

[Thorin-Oakenpants]

ContentId=number ... the first 6 (or 7?) are reserved AFAIK (4 of them for the default containers that ship) .. and then they start at 7 (or 8?). That's what TC does .. every new container - a new id number. Hence everything is always isolated.

[Thorin-Oakenpants]

crssi: cross domain logins that effectively utilize supercookie flows break. Think using FB to login into another service, or google accounts for youtube, etc. There are fuck tons of these, cuz .. greedy targeting marketing race to the bottom to track everyone

[atomGit]

is there any reason to disable FPI? Asking out of curiosity, since I have no problem at all with FPI enabled.

not that i have personally experienced, but as Pants said... however x-domain log-ons are not always broken apparently - ex. i can log into AMO which redirects to firefox.com without disabling FPI, but maybe they hard-coded that one(?)

certainly a lot of shopping sites will break i suspect

[crssi]

So... FPI enabled I go to YT and do a login with google account is expected to break?
I just tried that (never before) and it works as it should.

At least 10 users are using "my" profile, some are heavy shoppers and I am light one... no one never experienced an issue.
For sure there was a lot of breakages around FPI was introduced and several versions of FF afterwards, but last year till now, none I am aware of.

Do you have some real case to test?

Cheers

[Thorin-Oakenpants]

So... FPI enabled I go to YT and do a login with google account is expected to break

No (I have no idea for that pairing) I was just giving examples. What breaks it is the "supercookie flow" (arthur's words, not mind) ... go and read scrolls of comments about it in bugzilla. Not every cross domain login works like that - it's just how some sites implement them

[Thorin-Oakenpants]

• cross-domain / login issues
  [lots: here are some] 1319728, 1336458, 1319839, 1319761, 1319756, 1316019, 1340949 - breaks FF Sync's Manage Accounts

[crssi]

I have tested 1319728 and it passes as it should with FPI enabled.
Tested 1319839 and for sure the login passes, which on a bugzilla is stated not desirable by opener. But here TC can kick in to make login fail, if you wish.

I haven't tried the FB ones... but my mother is using staff like that A lot and she don't complain.
I also do not have pixnet account to test 1316019.

Those tickets were opened 2 years ago and latest update about 8-9 months old.
Is it possible that those problems were resolved over some other tickets?

The point is that all of my "test" users are using FPI for several months now, not that they are aware of, since they don't care... most of them care only that everything works as they expect, and no one has reported any breakages back, at least not something FPI related. Believe me, I listen to a lot of bitching, if things breaks.

[Thorin-Oakenpants]

IDK .. I don't use ANY of those sites or ANY cross domain logins. Not much has happened with FPI to be honest for a long long time (except adding in little forgotten things like favicons, etc). They were even going to remove privacy.firstparty.isolate.restrict_opener_access, but then didn't - and then even added some stuff - read 4002 (but that change is in FF65). I do know they fixed FPI and a few other things such as Pocket (but I think that's FF66). So NFI mate :)

All i knew is that there was a hell of a lot of FPI breaks shit tickets. In the FPI sticky I listed some, which is what I copypasta'd at you. That was 18 months ago or more.

At the end of the day, if it doesn't break shit, then be happy :) But it DOES break shit, cuz stoically said so, he gets people telling him because he's a dev with tens of thousands of users, most of whom will blame the extension, and he has to troubleshoot it all

[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.

[rugabunda]

It breaks uploading photos on disqus. The only other problem I have noticed is it can slow browsing and loading of web pages up to 3-25 seconds depending on the page, the latter notably facebook. While others are fine.

[practik]

Someone please give me eyes and a -1 on my last comment so I can have one of every emoji :-)

@rugabunda, how are you measuring those delays and identifying FPI as the source? I'm curious to check and see if I'm experiencing the same thing on my own system (though I don't use Facebook).

[Thorin-Oakenpants]

Someone please give me eyes and a -1 on my last comment so I can have one of every emoji :-)

Done

[Thorin-Oakenpants]

I fucked it up and gave you a second rocket.. what do these new emoji's even mean? Some of them are ambiguous

Not sure if this is just slang, but "he needs a rocket" is short for "rocket up the ass", as in, he needs a kick in the pants (but that's not why I added a second rocket, I just like the emoji) ... and I have no idea what eyes mean: I can read than in a dozen different ways

[practik]

I think you can take your rocket back if you click it again, but I don't mind having two, I like the emoji too. And now that I know about "needs a rocket" I may have a new way to use it :-) But yeah, no idea about the eyes here either … Giving you the side eye? Pervin' on your post?

[rusty-snake]

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