“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
*	❌
*.*	❌
*.tld	❌
*.domain.tld	✅
*.sub.domain.tld	✅
...	✅

[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:
#976 (comment)
#976 (comment)

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

[grahamperrin]

specific paths

▶ #691 in particular, #691 (comment)

[waluwaz]

I also wish the feature was available. See below recent examples that bring me outside my expected target container.
consent.google.com
www.google.com

mybank.bank.com
www.bank.com

fr-fr.facebook.com
www.facebook.com

Back in 2017, https://jotter.jonathankingston.co.uk/blog/2017/04/04/containers-assignment/ didn't seem to aim at separating www.bbc.com and non-"www". flavours. See the section "When you click a link to bbc.com you will see this prompt asking you to confirm opening in the container you asked for".
Thank you

[Hyperlynx2]

edit: looks like it is available, in a Firefox-authored extension: https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/

[osamabck]

I am not sure exactly where this feature is currently but from what I understood it does bring some security risks, or unintended issues like linking your search engine history to your email (in case of google for example).

I am not sure if its been suggested or discussed already but why not just have a manual edit/add option.
Currently the only way to add a url to a container is to open that url then using the extension "always open in", two of the most frustrating issues I have with this one, is having to manually open every url I want and add it to the container, and it doesn't work for middleman pages like some authentication page, that will redirect you instantly, which causes the main site to fail loading/authenticating.

In the manage containers section I can see the list of containers I have, I can delete, rename, restrict to designated websites, give a color or icon, delete a website from the list, but that's about it. If I can add/edit a website, instead of just removing, I can then write in the domain and subdomains I want in a specific container, it doesn't need to use a wildcard I can input everything myself but at least writing it down into the container directly is way faster.

[raffraffraff]

Containerise solves this. My security issue with Containerise isn't that "it solves the problem" (which is what some of you seem to care about), my issue is that it's a 3rd party add-on that requires permission to 'Access your data for all web sites'. The lack of movement on this issue is sending people into the arms of an extension that, if compromised and updated with malicious code, would be a nightmare.

Suggestions:

• Enable wildcard matching on the whole URL path
• Leave the default action for 'Always open this site in' to match the domain only (no change for most users)
• Let power users manually edit the tab/URL assocations
• Make the 'Open this site in your assigned container?' more useful. Right now it wastes a whole browser asking me to choose between A and B, without letting me choose any of my other containers. Infuriating.

My story, which I'm sure will resonate with others: For work, I have to juggle multiple accounts for AWS, Google and others. Without pattern matching across the whole URL and path, this whole concept fails for my primary use case. I'm actually better off launching separate Firefox instances on different profile paths, using account sync features across them, and writing a desktop UI+script that launches URLs in the correct instance. But that's just daft.

[osamabck]

Containerise solves this. My security issue with Containerise isn't that "it solves the problem" (which is what some of you seem to care about), my issue is that it's a 3rd party add-on that requires permission to 'Access your data for all web sites'. The lack of movement on this issue is sending people into the arms of an extension that, if compromised and updated with malicious code, would be a nightmare.

Suggestions:

* Enable wildcard matching on the whole URL path

* Leave the default action for 'Always open this site in' to match the domain only (no change for most users)

* Let power users manually edit the tab/URL assocations

* Make the 'Open this site in your assigned container?' more useful. Right now it wastes a whole browser asking me to choose between A and B, without letting me choose any of my other containers. Infuriating.

My story, which I'm sure will resonate with others: For work, I have to juggle multiple accounts for AWS, Google and others. Without pattern matching across the whole URL and path, this whole concept fails for my primary use case. I'm actually better off launching separate Firefox instances on different profile paths, using account sync features across them, and writing a desktop UI+script that launches URLs in the correct instance. But that's just daft.

I have been using Containerise for about 3 or 4 months now and man! does it make my life painless! Its such a little feature but being able to input the url directly, instead of having to open each website individually one by one makes things so much easier.

I still don't know why this isn't included in the main extension, I am guessing (might be wrong) the rules list is some sort of a JSON or some list, so just allow access to it and problem solved (for my use case at least).

Also quick note! Containerise is also open source and available on github (I believe its a fork of the main extension) in case anyone wanna take a look at it.

[julie777]

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.

I believe that SimpleTabGroups is complementary to multi-account containers. I use both.

STG provides groups of tabs that I can open an close at will. These groups include tabs from many websites, some of which I want to keep isolated from each other. I also save, unload and restore groups as needed to keep from having hundreds of tabs open all the time.

Multi-account containers lets me keep certain websites isolated from all others. I tend to have a MAC container for each web site that I log in to, such as StackOverflow, my bank, GitHub, etc. I don't use MAC for grouping as that violates the security that I am trying to enforce.

An of course I also use the specific Facebook container extension because Facebook is incredibly hard to isolate.

To summarize,
I STG groups to provide a specific working environment (convenience and efficiency).
Independently and cooperatively I use MAC to make sure my information is kept isolated to the website that needs it. (security)

Update: STG breaks some of the functionality of Firefox multi-account containers.

[julie777]

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.

I just want to clarify quickly for those not interested in reading about policy.
An origin is composed of (http://mail.google.com:81/somepage)

• protocol http
• host mail.google.com
• port 81

If any of these is differs then the origin is different (read dangerous to share with). This means that mail.google.com and docs.google.com and google.com are all different origins and should/could have separate rules for containment.

Having the default be the safe way is a good idea IMHO. That said, I put all my google services that are logged in to the same google account in the same container. But that doesn't include google.com.

[radupotop]

Apparently there's been a PR for this open for ages:
#1500

No movement from Mozilla.

[i-am-the-arm]

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

This is my biggest use-case. It's super annoying to navigate to someband.bandcamp.com and not stay within the same container. It seems like this has been a request (or an issue?) for a couple years now; I don't understand why it's so difficult to implement. Can someone help me understand what's preventing progress?

[tukusejssirs]

I am not sure if this is the right issue to provide my feedback (maybe I should write this in #691), but I wish we could specify whether to always open a website in a container by domain, subdomain, with or without a specific URL path. Regex support would be awesome

Imagine that I want to define the following rules:

URL	Regex	Container	Notes
github.com/my-username/	https?://github.com/my-username/.*$	Personal	open all repositories under my-username in Personal
github.com/my-company/	https?://github.com/my-company/.*$	Work	open all repositories under my-company in Work
gitlab.com	https?://gitlab.com/.*$	Other	open all URLs with the gitlab.com domain in Other
project.my-company.com	https?://project.my-company.com/.*$	Project	open all URLs with the project.my-company.com subdomain in Project
my-company.com	https?://my-company.com/.*$	Work	open all URLs with the my-company.com domain (but not the project.my-company.com subdomain) in Work

Compare this with how Bitwarden does it: it provides a dropdown with some options how to match the provided URL (more info).