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.

[domenic]

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.

Er, I think this is a bit confusing, because origin isolation refers to (a specific, origin-policy-based developer mechanism for) disabling document.domain/SAB. Whether a browser uses that to perform per-origin process isolation, is an implementation detail.

Just a terminology mixup...

[annevk]

@camillelamy has Chrome tried shipping some of the restrictions around SAB yet or is still too early to start updating the relevant tests?

As for what process allocation scheme you use and the boundary of those processes, none of that is currently governed by the specification. I suspect where we'll end up is pointing out some of the Spectre-associated risks and ideal boundaries on Spectre-impacted systems, but not mandate anything in particular.

Edit: to bring that back to "origin isolation", here that only refers to what the specification would allow for and what is observable (minus successful Spectre-attacks). (And yeah, there's also an origin isolation feature that's rather distinct, but also only deals in what it allows for and what is observable (again, minus attacks).)

[domenic]

We have not started implementing the SAB restrictions yet, although we've begun discussing how to do so.

What's worse, we have a bug which makes testing the SAB restrictions hard: any web platform tests would presumably follow the spec and use messageerror, but Chrome would instead send a message with null.

Given this I personally think the best course would be to add tests (or subtests within the same test file) for SAB restrictions, using messageerror, and Chrome will fail those until we both (a) add the SAB restrictions; and (b) fix our messageerror-vs.-null-message bug. It'd be great if we could avoid modifying existing tests to in a way that loses coverage, though.

[annevk]

As for the tests: to a large extent this is about changing the expected results of existing tests, right? We already have same-origin, same-site, and cross-site coverage. And they all use the headers (and we have tests for expecting failure when the headers are not present). The question is about changing the results for the same-site tests. (And adding tests for the specific document.domain setter "failure" we want.)

As for Chrome, what is the tracking bug for this? I looked around the various blocked on/blocking issues of https://bugs.chromium.org/p/chromium/issues/detail?id=922191 and didn't spot anything.

[domenic]

As for the tests: to a large extent this is about changing the expected results of existing tests, right?

You're right; I'd forgotten that. In that case changing the existing tests makes sense to me (and I'm happy to help with review).

My main concern was hindering COOP/COEP testing by somehow making their results dependent on SAB sharing. But I realize now that you'd be modifying a different set of tests entirely, so it's all good.

As for Chrome, what is the tracking bug for this?

What do you mean by "this"? I linked to our messageerror vs. message bug above. Other bugs I could imagine you wondering about are implement self.crossOriginIsolated and modify process allocation logic for COOP and COEP.

[annevk]

Particularly scoping agent clusters differently and modifying the document.domain setter. (Process allocation is an implementation detail and self.crossOriginIsolated is only tangentially related. We'd have it even if we didn't do these additional things.)

[domenic]

Ah, I see. I'm not sure what the tracking bugs are for that, and will defer to @camillelamy and @yutakahirano.

[yutakahirano]

Filed https://crbug.com/1058309.

[annevk]

Note that Firefox is implementing this now (not yet shipping) and as part of that (see https://bugzilla.mozilla.org/show_bug.cgi?id=1601594) we modified several tests. This probably still needs more document.domain tests though.

cc @chihweitung