“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