[Feature Request] Better support for isolation with SSO flows

[watsonarw]

Using temporary containers with the "Different from Tab Domain and Subdomain" isolation setting can often break the login flow of apps which use SSO. This can currently be addressed by adding a per domain record for each domain, with an exclusion rule for the other one. This can get cumbersome if the SSO flow redirects through more than two different domains during the login process. An example of this is Trello.

When logging into Trello with a linked Atlassian account. The login flow goes from trello.com -> id.atlassian.net -> trello.com -> auth.atlassian.com -> trello.com. In order to trace this flow, I needed to turn off isolation, and follow the requests in the network tab in dev tools.

Google, Microsoft and others have similar login flows that go through multiple different domains.

In order to support this with per domain rules, I need the follow per-domain exclude rules:

• trello.com
  • id.atlassian.net
  • auth.atlassian.com
• id.atlassian.net
  • trello.com
• auth.atlassian.com
  • trello.com

A neater/simpler way to manage this would be to introduce the concept of "equivalent domains" or "grouped domains". By allowing someone to mark trello.com, atlassian.net and atlassian.com as equivalent, and treating them (and their subdomains) in the same way as though they are equivalent (or subdomains) when it comes to isolation, supporting SSO flows like this could be much simpler.

As a bonus, a default list of "equivalent domains" could be included for "common" sites (e.g. Google, Microsoft) so that those domains will work out of the box without needing to configure it.

[stoically]

Domain grouping sounds like a good approach. Some prior discussions on the topic: #407, #432 (comment)

Would probably make sense to implement that with #397

[breakwaterlabs]

My experience has been that this is mostly a problem because "navigation" is such a broad category, and for some things (direct clicks, address bar navigation) I want it on "domain / subdomain", and for redirects I want it on "never". Generally each tab is going to start its own isolated container, so I am not worried about that navigation flow sharing data across redirects; in fact, it is very rarely the case that things will work at all if the redirect spawns a new container.

I might suggest that an easy fix for this would be to break out "Redirects" and "Popups" from "navigation from address bar". Spawning a new container for address bar / click navigations (different from sub/domain) but keeping container across redirects and popups is a fairly simple, low configuration way of allowing most applications to work even with SSO flows.

A longer term fix might be to reorient the "Isolation" settings to Break down by Isolation setting (of which there are only 4) rather than by navigation type (of which there are potentially many), and instead add the navigation types to the isolation settings. This would allow more navigation types down the road.

[stoically]

Something I stumbled over while reading https://blog.mozilla.org/en/mozilla/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/. It seems that TCP works based on the same maintained list as ETP, but using containers instead of "just" blocking cookies. So if TC would consume that list and embed it, it could offer an "open in new temporary container if domain is not on the SSO list". Just have to figure out where in the mozilla source repositories the list lives.

[BayLee4]

@stoically I had a look and it seems TCP doesn't work with an allow-list, and instead use heuristics to determine which cookies to allow. The heuristics are listed here, some of them being actually very similar/identical to some suggestions proposed here in the related issues, for instance #407 (comment)

Source