Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Temporary Containers vs First-Party Isolation #395
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!
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.
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.
If you enable
Indeed, you could even go so far and enable
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.
Default off, but are automatically switched on (since Firefox57) if an Add-on is installed that requires the
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.
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.
Temporary Containers only uses one API to remove data, and that is
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
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.
My personal summary on the matter:
And finally, like you said, everyone has different takes on what level of privacy one wants - it's always possible to try harder.
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
Ahh yes. That's what I called
so much for me shutting up for a while
So is leaking your IP by not using a VPN etc. I do not find that relevant :)
Just focusing on the isolation factors : If you have FPI enabled, then you won't unbreak it, right!?. And configuring
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
Why bother to sanitize when in
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
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
You just answered that.
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).
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
Yep, that's possible. However, currently its only possible to disable (
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
Afaik the OA for PB is
That's what's indeed happening by using
Two additional things from #294 (comment) I want to address:
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.
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).
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).
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
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
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 :)
Hi @Thorin-Oakenpants !
I always used FPI+Container without add-ons.
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".
@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)."
I absolutely agree. That's why
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 :)
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.
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.
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.
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!
@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!
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
^^ 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)
^^ 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
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 )
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:
He explains everything in great detail and the 2 bullet points don't do it justice IMHO
Its meant as both. As an alternative it solves the cross-domain login problem (which will NOT be solved by the Tor Uplift -
^^ 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 :)
changed it (for now)
Thanks for adding TC to your Wiki. I've added
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.
FWIW, I've started the test on http://ip-check.info/index.php?lang=en twice.
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.
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
Thanks - good to know!
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.