“Always Open in This Container” for entire domains/to include subdomains?

[ArchangeGabriel]

Hi there,

I’m new to containers and enjoying the feature, especially with this “Always Open in This Container” feature.

However, I was wondering if it would be feasible to add website in this category by TLD, e.g. *mozilla.org instead of www.mozilla.org, bugzilla.mozilla.org, wiki.mozilla.org…

They are TLD for which I would want that (archlinux.org is another example), and some for which I don’t (likely google.com).

Thanks!

[ArchangeGabriel]

Hum yes sorry, you’re right. Edited the title.

[groovecoder]

Container isolation is based on origins as defined for Same Origin Policy. So, we would need to seriously consider the web privacy & security effects if we made it (too) easy to assign (wildcard) subdomains to a container.

[jonathanKingston]

For clarity SOP considers port(EG: 80, 300, etc) and protocol(EG: http, https). We however don't.

As mentioned, there are some you won't want this feature for. Deciding on the right UI for this seems a little tricky.

[b0urb0n]

I think this would be particularly useful for people who want to ensure that information set by domain-wide resources (ie. behind their company's VPN) don't get disclosed to any other website. Someone might want to have anything that matches *.myworkdomain.com auto-open in the "Work" container. This would be easier than manually adding each host/URL.

Perhaps a disclaimer: "Beware: this feature, if mis-configured, could defeat the purpose all together." Or determining the minimum that one can wildcard as to not defeat the point of this feature:

Test	Pass/Fail
*	:x:
*.*	:x:
*.tld	:x:
*.domain.tld	:white_check_mark:
*.sub.domain.tld	:white_check_mark:
...	:white_check_mark:

[jonathanKingston]

@b0urb0n the problem also is that users want to restrict their search engine traffic from their mail provider.

They for example might want mail.google.com and docs.google.com into a work continer but not www.google.com.

This leads to the conflicting use cases as you mention. I'm not sure if there is an obvious resolution.

[b0urb0n]

@johnathanKingston that makes sense, I hadn't thought of that. At first glance, a solution would be to make the model favor explicitly over implicitly. But this may not be intuitive/easy for basic users.

Since domain wide rules is a solution to easy initial setup, maybe the better option is more a bulk management solution or ability to import from bookmarks in a special way.

[grssam]

I feel the use case to split second level sub domains would be pretty rare (*.sub.domain.tld). But as previously commented by others as well, I feel that an option to for all sub domains (single level) can be of much use and can be easily exposed via a simple check box in the popup confirmation UI:

[dschneiderch]

I was going to write a new issue but I think this fits here. Still I get an unexpected behavior with code.earthengine.google.com

If I open a tab in any container , and then go to code.earthengine.google.com, it automatically changes the tab to the container that I set up for my private gmail account. I don't think I ever set a container for code.earthengine.google.com. I believe the expected result is a login page for google in a container not set up for google.

But regardless, there are conflicts in whether there is a default container for this site. If I left click on the containers icon, the checkbox for "Always open in personal google container" is NOT checked. But, if I right click on the containers icon the first entry in the contextual menu "Always open in this container" IS checked. checking and unchecking these settings makes no difference if I start over with a new tab.

For context, university container is set for docs.google.com, sheets.google.com, photos.google.com personal google container set for maps.google.com, keep.google.com I never/rarely visit mail.google.com in the browser. I will note that if I open a default tab and then enter docs, sheets, photos, or keep.google.com, firefox will prompt me if I want to open the site in my assigned container. I think this is the expected behavior. This does NOT happen with maps.google.com - presumably because google redirects to google.com/maps. This might be a separate issue but I thought it might also be related.

So while I realize the handling of subdomains is a tricky issue but I wanted to report my experience with code.earthengine.google.com.

I'm on MacOS 10.12.6 with Firefox beta5

[mkurz]

A related problem based on the URL path instead of sub-domains: #976

[kathampy]

If a subdomain is explicitly assigned to a container, it should be excluded from any wildcard subdomain assigned to another container.

[ArchangeGabriel]

Just for the record, I don’t care anymore about this feature. See #1060 for the reason.

[lillesand]

I might be confusing two issues here, but there are two features I see sorely missing:

1. Being able to specify wild card rules. This is probably a super user feature, but I suspect that containers primarily are (and probably for quite some time will be) an advanced concept for advanced users. At least in my work a domain usually represents a context that I'd like to isolate.
2. Redirects. Because "Always Open in This Container" is purely a GUI-interaction I can do for the current page, I have some redirect URLs I'm simply unable to pin to a container group. This might not be a common use case, but it's definitely possible (and indeed real for me).
   1. Open service.my-corp.com
   2. Redirects to third party SSO solution (say Auth0 or Google)
   3. Redirects to third party service on another domain
   4. Because the third party service does not have the same domain as service.my-corp.com I'm unable to pin it to a container group

[soar]

Same problems with domains with redirect, for example AWS Console - https://<ACCOUNTID>.signin.aws.amazon.com/console which is redirected to https://console.aws.amazon.com - can't pin it to container.

[synthgab]

Hello,

I just came across this issue because I also use both the multi-account and the temporary container extensions, and my company is using Microsoft 365 which is based on 20+ different domains, some of which just there for SSO redirections !!

Unable to click quickly enough to add some domains to the « always open in this container » list, I began to try another way, and found a very dirty workaround: 1/ take note of the domain that should be added to the list 2/ go to about:config and set network.http.redirection-limit to 0 (no kidding !!) 3/ open the container tab and type in the URL (an error about redirect will be displayed) 4/ but this domain can now be addded to the list \o/ 5/ do not forget to reset the redirection limit to its default value ...

This seems rather complex, but it just has to be performed once for a broken domain/sub-domain, so for me, in the current status of this extension, it's acceptable.

Hope this helps...

[mkurz]

@synthgab Check these two comments, there is probably a simpler way by just editing storage.js: https://github.com/mozilla/multi-account-containers/issues/976#issuecomment-353465931 https://github.com/mozilla/multi-account-containers/issues/976#issuecomment-353463998

[TrekkieTechie]

It's surprising to me that including subdomains isn't the default behavior, to be honest. From a purely logical standpoint, subdomains are just that -- sub -- so if I say I want a domain to open in a given container, it follows that I want the entire domain to do that. The alternative is having to go through and manually add every single subdomain to that container, which can range from annoying to outright impossible (for websites that assign each user account their own subdomain, for example).

Even if you don't want to make it the default behavior due to some of the concerns discussed above, please expose a way for users to do this (for example, manually entering *.domain.com) that aren't affected by those concerns.

[ghost]

@jonathanKingston

They for example might want mail.google.com and docs.google.com into a work continer but not www.google.com.

Maybe I'm missing something but if someone's using mail.google.com and docs.google.com in a 'Work' container, does it really make a difference which container www.google.com is opened in? Even if it's opened in a different container, Google already knows that all the three (sub)domains are being visited by the same IP address so I don't think we gain any privacy advantages here. Also, I don't think that the "multiple Google accounts" case applies here because if someone wants to use different Google accounts in different containers, Google (sub)domains won't be pinned in a specific container.

[xarx00]

The discussion progresses very slowly, It seems to me it is still at the same point as at the beginning more than a year ago. Despite the many votes for wildcards, there is no progress in this and related issues. :-(

@jonathanKingston, @groovecoder I have a few points here (in reaction to https://github.com/mozilla/multi-account-containers/issues/473#issuecomment-298353233), though probably a little late.

1. FF Containers were originally (https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/) advertised as Contextual Identities. While you're treating them now as a security anti-tracking functionality? Has the Mozilla viewpoint shifted since then?

2. You argue against wildcards saying that they are not secure. In opposite, I consider the necessity to specify every single subdomain insecure. In particular when using this addon together with another container addon, e.g. the Temporary Containers addon. Your arguments against unsecurity of wildcards may be based on the premise that when a page in a container refers another page with unknown domain, then that page is opened in the same container. But with TC this is no longer true. Hence it may (and often does) happen that a page links/redirects to another page in a different "forgotten" subdomain of the same domain. And TC then opens the page in a tmp container, thus corrupting the functionality (e.g. single sign-on no longer works). If it was an addon different from TC, the referred page could be created e.g. in a default container and leak data this way.

3. It seems to me that you take seriously only a single use-case for the containers. Perhaps because of point 1. But there have been mentioned several other use-cases here. Not only use-cases - different ideas/intents of how to use the containers. TC addon is one such example. Why to stand against these different viepoints?

4. Unfortunately, the whole Mozilla policy seems to have shifted in FF Quantum towards "Users could harm themselves, we better not allow them to do that". Not allowing wildcards here seems to me in the same line.

I'd appreciate if you expressed yourself of what your intents with this addon are. Currently we're trying to persuade you to implement the wildcards, but it already lasts for too long, more than a year.

@sixpointzero Yes, it matters. I may be signed in to Google to check my e-mails in gmail, but at the same time I do not want google to know who I am while searching in its search engine. I use gmail very rarely, but often forget to log-out. So Google could hardly connect my dynamic IP with me reliably.

[pshem]

@jonathanKingston

They for example might want mail.google.com and docs.google.com into a work continer but not www.google.com.

Maybe I'm missing something but if someone's using mail.google.com and docs.google.com in a 'Work' container, does it really make a difference which container www.google.com is opened in? Even if it's opened in a different container, Google already knows that all the three (sub)domains are being visited by the same IP address so I don't think we gain any privacy advantages here.

An IPv4 address is not enough to track a user in most cases these days. IPv4 has reached a level where the vast majority of people are behind a NAT or multiple. An IPv6 address is enough, and, for an intelligence agency, an IPv4 address and browser fingerprinting also are, but Firefox tries to limit the extent of fingerprinting and the connection is only probable instead of certain. That's a big difference

I'm still waiting for an option to add domains by typing them in, including with wildcards, and it's getting more dire every month as outsourced authentication is creeping in.

[webserviceXXL]

This really would be a huge improvement for the multi account container. Especially if the path is respected too. Unfortunately so far the path was not considered here in the discussion even though other issues were already closed with a reference to this Issue. Like #976.

[wei2much]

Or provide an easy way to manually add domains to the containers' configs so I don't have to manually open up each tag and specify that domain to be always opened in certain containers. It would be much easier to manually generate some domain lists and paste it there.

[OdinGitDat]

For everyone in this thread I recommend Containerise. It allows for full domain regex matching for specific containers.

[AdKiller]

For everyone in this thread I recommend Containerise. It allows for full domain regex matching for specific containers.

Thanks! That sounds like just the fix. but at the same time I am hesitant to add yet another addon for such a basic feature that should be already included...

[vzool]

Hi, I'm not sure if this the right place for this. But, I think there is should be a two sub accounts for this: 1- Firefox (Default) only open for Vanilla Firefox. 2- Firefox (Development) only open for Firefox Developer Edition . Every sub account has its own extensions, passwords, history and everything but there are all connected under one primary email address. One can be opened in Vanilla Firefox and other can be opened in Firefox Developer Edition. And then the whole process of separation will make very sense for everyone. For the first time I noticed that there is a developer edition, when I installed it and I'm ready to do some development, but before I begun I liked to save my setup and Synced to other devices for future use then all my home stuff merged into this developer edition. :( I like the idea of Firefox Developer Edition been as a separate application for developers, but it is not separate from my home identity data. Because, I like to have one email address for my home/development stuff. At the end most of us are freelancers. ^_^ I hope that I made my point clear. Thanks <3

[Solid-Ice8]

@AdKiller, @OdinGitDat, @mckenfra,

Oh my god, pull & issue list is piling up...is there anyone from Test Pilot actually managing these?

If you don't plan on using Multiple accounts on domains like Google or Facebook, you can use Facebook and/or Google Container. Again, do not plan on using multiple / multi accounts.

If you plan on using multi accounts, DO NOT use the add-ons above.

You should all consider the recommended add-on : Simple Tab Groups (STG).

This add-on supports grouping. Yes, you heard (read) that correctly.

1. It has its own Temporary Container functionality. I haven't tried comparing this to the actual "Temporary Container" add-on yet (I have both installed), but it seems the add-on version seems to be better so far.

2. You can use wildcards on sub-domains. Sorry, I find STG add-on inferior to Containerise that I've tried and failed. And some features aren't compatible with MA-C (Multi-Account Container),

2 - a) I, myself tested the "Default Container" feature in Containerise, which isn't compatible with Multi-Account Container (you can see my issue I posted in there as well) and I chose Temporary Container over that function too..

2 - b) After creating a "Group", you can 'Edit Group Settings' and...you'll be in heaven as you'll see more advanced features. Everything is self-explanatory from there. Wildcard use is at the bottom.

3. I found the ability to set "Default Bookmark folder location", but it surprised me because this was actually in the "Options" section. This functionality will bookmark all your opened tabs. I'm not sure if it'll keep adding as you use open more and more tabs but...I would rather not use this.

3 - a) There's the add-on "Default Bookmark Folder" add-on for this if you like to choose specific locations.

3 - b) As a bonus, you can also use FoxyTabs to bookmark tabs left or right. I like this add-on as it can close duplicate tabs. Just in case you have a sensitive mouse (like mine) and open the exact same tab twice...or perhaps you've bookmarked the same site in multi locations.

[atjn]

I tried to use this plugin to isolate my logged-in Google pages from the rest of the web. After two hours of adding URLs, i have decided to remove it again, because it results in weird behavior, like suddenly logging me out, sending the page into an infinite redirect loop, or suddenly duplicating the tab into three separate tabs.

If i was able to write *.google.com, i would have been done in 30 seconds and would never experience any of these weird issues.

[Solid-Ice8]

@atjn , have you tried using the official "Google Container" add-on for this purpose?

You must delete Google Container from MAC (Multi Account Container) before using this add-on in order for it to work properly.

If all else fails, you can also try Simple Tab Groups. In there, you create a new group, then enter its "Group Settings". Near the bottom, you can set Regular Expressions for catch Tabs to enter wildcards (*).

[atjn]

@Solid-Ice8 thanks for the tip - as far as i can tell, there is no official Google Container. I have definitely considered the unofficial container, but i shouldn't have to install yet another plugin just to do that.

[xeruf]

There have been tens of issues and supporters of this issue, and it seems so trivial to implement. What's stopping this? My use-case involves bandcamp shops, which often have their own subdomains, yet I have one bandcamp account for all of them.

I think it would actually be reasonable that subdomains are included by default, and then you can still override it for particular ones, e.g. google.com - browsing container (includes mail & all that stuff) calendar.google.com - university container ...

[LinAGKar]

And on top of this, it would be nice if it allowed specific paths, so you could e.g. make a rule for www.google.com/maps/, without www.google.com.