Summary of domain management issues

[kurahaupo]

The assignment of domains to containers is a great idea, but there are numerous shortcomings in the current implementation, and the handling of the related reported issues has become very fragmented, with tickets being closed as "duplicate" after extended periods of discussion, often without clarity around whether the underlying issue has been or will be resolved.

So far the accepted solutions have focused on wildcards and/or ancestor domains. As I hope to illustrate here, those only solve some of the problems.

I was prompted to create this issue when #1833 was closed, as my comment there still need tracking.

1. Pages may redirect through a domain outside the container, and it's not possible to get a stable page load in the other domain, there's no opportunity to add its domain to any container.
2. Because of this, Limit to Designated Sites is almost useless. When the user lands on a page that requires an authenticated session, it may redirect to another page to get the user to log in; if they're already authenticated there, they immediately get redirected back.
   When those two pages are not in the same container, this can result in an endless loop. (see Can't select "Always open in container" on a redirect loop (e.g. splitwise) #640 & [Feature Request] Provide way to associate a URL that redirects with a container. #1335)
   This is particularly problem for any sites that use generic OAUTH between unrelated domains.
   This is also problem with larger service providers with many TLDs. For example, Google has google.something and youtube.something registered in most top-level domains (hundreds), and more than 50 subdomains for products, each of which redirects to an account. subdomain (usually but not always in .com) when it requires authentication.
3. Having to load the first page from a domain without container protection exposes the user in the very way that containers are intended to prevent (see Tagging sites for the first time is cumbersome #719), so we need a more prophylactic ("guard in advance") process (see [Feature Request] Ability to assign domains to a container, without visiting the site #1317).
4. Having to load a page and then add the domain is quite slow and cumbersome when dealing with a large number of related domains, so we need a reasonable bulk handling process.
5. Pages may include components in domains outside the container, particularly JS. Without using the "Network" inspector in the Developer Tools, this can be quite hard to find. We need still need "open this page in container", but it should offer all the domains connected to this page, not just the top-level one.

I believe we need all of these:

• manual addition of domains (see Add the ability to edit the domain list #839, Way to manually edit URLS opened in/assigned to containers without opening up tabs? #1057, Feature request: Manually edit which sites open in a container #1180, A user can manually add a site to "Always open in [container]" #1227, Feature Request: Manual editing for sites assigned to a container #1501, Manually add URL's to a container #1670)
• ancestor domain grouping (see Root domain or domain template in the Site List #1833);
• pattern matching (see Always open URLs that match a pattern in a container #691, Feature request: Manually add domains to container (ideally with wildcards) #1991);
• allow domains to be opened in multiple containers while not allowing them in all containers, especially those that act as (X)OAUTH providers (see Forwarding domains support #837);
  • ideally, this would be separate from a preferred container for the domain, and
  • would only permit page to be loaded from a domain where the referrer was already in the container;
• automated or confirmed addition of redirection domains;
  • same, but with white/black lists;
• automated or confirmed addition of domains for components (img, js, css, iframe, etc)
  • same, but with white/black lists;
• a mode where every time you visit a new site, it asks which container to open it in, even when "not in a container" (in the default container).

I note the connection with issues #640, #691, #719, #837, #839, #1057, #1075, #1180, #1227, #1317, #1335, #1501, #1670, #1784, #1833, #1991.

I note the connection with pull requests #1500, #1627, #1688, #2033, #2114, #2352.

[kurahaupo]

@dannycolin as per your suggestion in #1833

I've allowed this to be categorized as a bug as the infinite loop between an OAUTH client site and an OAUTH provider site should not occur.

[dannycolin]

I suggested you open an issue only if one specific use case isn't covered by another issues. A summary isn't a specific use case. Pointing connection to other issues means these problems are already addressed there. Also, this issue doesn't follow the bug report template that is mandatory.

[kurahaupo]

So where does a coordinating overview belong?

Having multiple open issues that give different symptoms with the same underlying cause, without coordination, often results in different people working on different partial solutions; stomping on each other's code in "rebasing hell", wasting effort, and getting demoralised.

Any "how to reproduce" would start with "sign up for any service that allows you to use an alternative OAUTH provider, where signing into takes you into a different domain". If you really want me to a file an issue that looks like that then sure, I can do that, but you could simply have asked me to reword this ticket rather than closing it.

[dannycolin]

I do understand and appreciate your concern about not losing sight of all the use cases. I also want to point out that closing an issue as duplicate doesn't mean we forgot about things that have been said in the closed thread.

When someone will work on a feature request, they will also have a look at the duplicates to make sure their solution covers the use cases mentioned in them. Of course, in the limit that the developers judge acceptable because in some cases some use cases can't be implemented for multiple reasons: lack of time or resources to include all of them, harmful features and so on.

If a use case isn't implement by accident, we'll be more than happy to fill a report for this one. But again, this isn't something that happens a lot.

Also, keep in mind that I'm doing all that on my free time as a volunteer who like you wanted to see more development happening on Multi-Account Containers so I do have at heart this project. If you still have questions don't hesitate to ping me on our Matrix server in #containers:mozilla.org or in a direct message if you prefer to keep the discussion private.

You can find instruction on how to join our Matrix server at https://wiki.mozilla.org/Matrix

[xanoni]

Workaround that helps with some of the redirection issues described in various tickets: #1670 (comment)

EDIT: improved workaround in the subsequent comment