New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporary Containers vs First-Party Isolation #395

Closed
stoically opened this Issue Apr 1, 2018 · 27 comments

Comments

Projects
None yet
6 participants
@stoically

stoically commented Apr 1, 2018

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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 1, 2018

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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 1, 2018

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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 1, 2018

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

This comment has been minimized.

stoically commented Apr 1, 2018

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

This comment has been minimized.

stoically commented Apr 2, 2018

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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 2, 2018

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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 2, 2018

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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 2, 2018

^^ 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

This comment has been minimized.

Decopi commented Apr 2, 2018

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

This comment has been minimized.

stoically commented Apr 2, 2018

@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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 2, 2018

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

This comment has been minimized.

stoically commented Apr 2, 2018

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

This comment has been minimized.

Member

earthlng commented Apr 4, 2018

@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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 21, 2018

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

This comment has been minimized.

Decopi commented Apr 21, 2018

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

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 21, 2018

^^ 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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 21, 2018

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

This comment has been minimized.

Member

earthlng commented Apr 21, 2018

  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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 21, 2018

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 :trollface:

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

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 22, 2018

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

This comment has been minimized.

Collaborator

crssi commented Apr 22, 2018

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

@Thorin-Oakenpants

This comment has been minimized.

Member

Thorin-Oakenpants commented Apr 22, 2018

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

@stoically

This comment has been minimized.

stoically commented Apr 30, 2018

@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

This comment has been minimized.

Member

Thorin-Oakenpants commented May 1, 2018

@stoically 💋

@curiosity-seeker

This comment has been minimized.

curiosity-seeker commented May 31, 2018

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

This comment has been minimized.

Member

Thorin-Oakenpants commented May 31, 2018

^^ 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

This comment has been minimized.

curiosity-seeker commented May 31, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment