Offering origin isolation through cross-origin isolation

[annevk]

The combination of COOP and COEP gives cross-origin isolation. As that combination creates a new browsing context group and everything fetched into that browsing context group needs to consent, it presents an opportunity to offer "origin isolation", the notion that agent clusters window agents find themselves in are keyed using an origin, rather than a site. In particular as those agent clusters are in a map owned by the browsing context group.

This would obviate the need for #4920 and various schemes to get rid of document.domain. It would require an explicit change to the document.domain setter to ignore any invocations of it. (As this is likely much more compatible than throwing and better than continuing to allow the origin to be mutable.)

Both Google and Mozilla folks are cautiously enthusiastic about this idea, but we'll have to double check existing content doesn't rely on the site granularity.

Thanks to @zcorpan for bringing it up last week.

(How exactly user agents end up doing process allocation in the end matters a little less, but this will give them the flexibility to do better, provided there are system resources to use.)

cc @whatwg/security

Bugs:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1601594

[domenic]

I'm unclear on the compatibility concerns you cite here. Since COOP+COEP are not deployed in the wild yet (hopefully), we should not have any concerns about expanding their behavior to also disable document.domain and SAB/wasm memory sharing.

[annevk]

The concern is that existing users of shared memory could not easily migrate to use these headers. I agree that this is likely minor and Firefox is okay with trying to ship support with all restrictions in place.

[domenic]

One issue here is that this doesn't offer developers much control over different types of origin isolation. For example consider a developer which wants a dedicated process for their top-level origin, but does not want to spend the resources on dedicated processes for each of the 30 subdomains that they embed as iframes. With a dedicated origin isolation signal, they could explicitly ask for origin isolation on the top-level origin, and give no such signal on the iframes' subdomains. Whereas if we rolled this into COOP+COEP, then there is no way to distinguish; all the iframes will need to have COEP at least.

(I guess maybe we could use the signal of "does an iframe have COOP?". But that's really weird since COOP is supposed to be for top-level frames only, right?)

That said, I still think that using COOP+COEP as a signal to disable document.domain and cross-origin same-site SAB sharing is very reasonable. Especially for document.domain, where in general we've been asking questions like "can we just say using a new API means you no longer get to use document.domain?". So I support this effort just in terms of the effects on those APIs. But we may still want a separate signal for origin isolation which browsers can use to make better decisions about process allocation...

[zcorpan]

My original suggestion was to disable document.domain if COOP or COEP is used at all, but that would likely make it harder to deploy COOP/COEP for sites where document.domain is used (use counter). So the next idea is to only disable it in this more specific case, which would also effectively result in origin isolation.

Having a separate explicit opt-in to origin isolation that also disables document.domain sounds reasonable to me.

[annevk]

Well, only disabling document.domain does not give origin isolation. You also need to change the way agent clusters are keyed, otherwise you could still have shared memory cross-origin.

[mikewest]

My main concern here is the deployment story discussed above: Chrome ships a number of APIs today that we'd like to lock behind CO{O,E,R}P once we ship them (aiming for the Chrome 82ish timeframe). If we can get away with preventing access to document.domain in the context of those APIs (I'm adding SAB metrics (which we somehow never had?!) in https://bugs.chromium.org/p/chromium/issues/detail?id=1029700), verify that we can stop posting SABs to same-site entities (#4920), and verify that we can drop same-site from the COOP definition, then I think we'd be well-served to do all of those things!

While those remain speculative, it makes sense to me to continue pursuing the explicit opt-in approach.

[annevk]

I pushed changes to #4734 that outlines how this would work in the HTML Standard, provided that https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e takes care of creating a browsing context group whose cross-origin isolated is true. I would appreciate feedback on all things.

[camillelamy]

To clarify Chrome's position here: we do support disabling access to document.domain and cross-origin SAB sharing in pages with COOP+COEP enabled.

However, we consider this different from 'origin isolation', which for us would imply constraints on the process allocation for COOP+COEP frames. We want to have some flexibility in our process allocation scheme to account for the user's resources. So, we are not in favor of automatic 'origin isolation' for COOP+COEP pages.