Locking a domain to a TC

[madduck]

Payment is one of those things where a site A redirects you to the payment site B, where you complete the payment, which will then eventually call a hook back to site A. Another case of this is OAuth2 logins, and there are other cases too.

With automatic mode, currently this means that a new TC is created for B, and when B redirects back to A, another TC is created, and since this third TC does not have the cookies of A, and A never finds out about the callback, the transaction fails.

Would it be possible for TC to remember that A is already assigned a temporary container, and while that container is alive, any new requests to A should automatically be opened in the same TC, even if another tab is opened.

Since TC already gets to assign a new TC to the second request back to A, all it really has to do is consult an in-memory lookup map.

[kamizoli]

I thought about the same problem and wondered if one could exclude e.g. paypal.com in gloabal " Exclude Target Domains " and then it would open in the same container as domain A.

But I find it not easy to get my head into the isolation logic. I would definitely benefit from some examples.

[madduck]

I don't want to maintain a list of special domains like that.

I also don't know much about how Firefox works, but here's my thinking:

When a new URL is visited, presumably TC is called via a hook of sorts. TC then looks at the current domain in the tab, and compares the URL.

Roughly, then the following happens:

1. If they match domain/subdomain, then TC probably doesn't do anything;
2. If the target domain matches a Domain Isolation pattern, then a new tab is created in a new temporary container, and the new URL loaded therein;
3. If the target domain does not match the current domain, and the new domain does not match an Exclude Target Domain pattern, then the new URL is loaded in a new tab in a temporary container.

We don't care about (1.) right now, and (2.) and (3.) really both effect the same result, so let's look at that somewhat closer:

TC needs to create a new container for the new tab. Depending on the configuration, it picks the next number, or the lowest available number that isn't used anymore.

What I am suggesting is that at this point, it first checks the existing temp containers to figure out if it has the domain already loaded.

Let me write some Python, because it's what I know best:

domain_to_tc = {};
if target_domain in domain_to_tc and not force_new_container:
    temp_container = domain_to_tc[target_domain]
else:
    temp_container = make_new_temp_container(target_domain)
    domain_to_tc[target_domain] = temp_container

new_tab.load(target_domain, temp_container)

Does this make sense?

Basically, when Paypal is done and I get sent back to example.org, TC determines that there's already an existing container spawned for example.org, and so it reuses that, which means that the success callback from Paypal will essentially be injected into the existing session, and it should just work.

Another way to look at this:

If you middle-click on any external link twice, then you get two new tabs, and they both have different containers, which doesn't really make sense. I'm all for ctrl-click forcing a new container (c.f. force_new_container in the above code), but I think the default should be reuse.

Do you agree?

[stoically]

Basically, when Paypal is done and I get sent back to example.org, TC determines that there's already an existing container spawned for example.org, and so it reuses that, which means that the success callback from Paypal will essentially be injected into the existing session, and it should just work.

That's an interesting approach to automatically solve payments and SSO. Challenges that come to mind:

• If the redirect happens based on a POST request it breaks again, since it's not possible to simulate one when reopening an request into a different container
• Copying all relevant data (localStorage, IndexedDB and Cookies) might be hard to do, since not everything is exposed though the WebExtensions API and multiple domains could be involved
• It might unknowingly leak storage back to the originating site if the same site is encountered while surfing, even if no SSO or payment was involved, simply because the same first party was visited again, which also plays into:

If you middle-click on any external link twice, then you get two new tabs, and they both have different containers, which doesn't really make sense

• One of the reasons TC exists is to not expose the same storage to the same first party when visiting it multiple times in the same session, so that such visits cannot be connected through storage easily

[crssi]

I don't remember if I mentioned it before, but I had something in mind like that:

Checkbox option to... If the target URL match to any in the configurable list, for example:

_sso=
.alipay.com
/oauth
/_login
//azure.microsoft.com/email/\?destination=https%3A%2F%2Fportal.azure.com%2F
/adfs/ls/
/auth
/cred_submit
/login
/logoff
/logon
/logout
/openid/
/saml/
/SAML2/
/signin
/signoff
/signon
/signout
/signup
/sso/
/websso/
/wsfederation
action=login
alipay.com/
logout=
...

then do not open in a new container and... ...returning back to source domain does also not open in a new container.

So it I am on a domain outlook.com and click login, which will lead me to live.com/login... then the target will not open in a new container, but remain in the same. On live.com page I do a login stuff, which will return me authenticated back to outlook.com, and returning to same domain from where everything started should also remain in the same container.

In that case the auth stuff can be remediated and will not break after.

[WhyNotHugo]

I'd be interested in this feature too.

When using automatic mode, if I log into a website on a container, and open another tab with that same website, I need to log in again. This happens often on things like github, gitlab, nh, reddit, stackoverflow, etc.

Reusing TCs if they match the domain of an existing solves this issue really cleanly.

[criztovyl]

Basically, when Paypal is done and I get sent back to example.org, TC determines that there's already an existing container spawned for example.org, and so it reuses that, which means that the success callback from Paypal will essentially be injected into the existing session, and it should just work.

That's an interesting approach to automatically solve payments and SSO. Challenges that come to mind:

• If the redirect happens based on a POST request it breaks again, since it's not possible to simulate one when reopening an request into a different container

As far as I understand at least OAuth does not use POST, right? I.e. it's redirects/GET instead? My personal experience leads me to assume that mainly SAML-bases SSO uses POST. I also assume here that SAML is not used much on the open web and rather inside corperate networks / related to business stuff, where I suppose isolation of the SAML provider and consumer is pretty useless because they're run by the same entity, or at least on behalf of it. So supporting redirects to open go to existing TCs might still be useful for the majority of cases.

I am unsure about PayPal-like payment flows, but I think they're also redirects with some URL parameters, similar to OAuth. (For me it sometimes works to copy the URL from the new TC to the old TC and the application will happily accept that; sometimes it seems the application rejects the PP token as soon as the application cannot match that to some internal session.)

• Copying all relevant data (localStorage, IndexedDB and Cookies) might be hard to do, since not everything is exposed though the WebExtensions API and multiple domains could be involved

If it's just redirects I suppose that should not be required; if I have site A open in a TC, get redirected to a second site B (e.g. SSO, payment) that opens in a new TC, I just want redirects that go to site A again to open in the original TC instead of a new one. (After confirmation, see below.)

• It might unknowingly leak storage back to the originating site if the same site is encountered while surfing, even if no SSO or payment was involved, simply because the same first party was visited again, which also plays into: [...]

(For redirects ...) In such cases an site like for MAC (the site asking you if you want to open the URL in assigned MAC or continue in TCs) might be enough to be in sync with the users intentions.

Maybe this could even be expanded more generally, possibly hidden behind a feature flag, where TC detects you have the same site open in a TC already and asks you if you want to use the same TC or another one. (Sounds pretty, not sure if it's actually useful.)