Introduce "cross-origin-isolated" permission

[yutakahirano]

Introduce "cross-origin-isolated" permission to allow a document to
control whether nested documents can access features that require
securer context, even when COOP+COEP are enabled.

Fixes #5435.

• At least two implementers are interested (and none opposed):
  • Chrome
  • Firefox
• Tests are written and can be reviewed and commented upon at:
  • Add tests for 'cross-origin-isolated' permission web-platform-tests/wpt#24600
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1115379
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1658677
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=215407

(See WHATWG Working Mode: Changes for more details.)

---

/infrastructure.html ( diff )
/webappapis.html ( diff )
/window-object.html ( diff )
/workers.html ( diff )

[yutakahirano]

@domenic @annevk Can you PTAL?

For documents We use #allowed-to-use.
For dedicated workers the permission is inherited from the ancestor document.

Shared and service workers don't inherit the policy. This comes from the fact that we don't inherit COEP for these workers, but web developers who want to use APIs requiring securer context to sniff process memory shared with the parent document can use service worker to do that, assuming the worker and the frame are hosted by the same process (this is not guaranteed but they often are). Do you think it's problematic? I thought about this for a while but couldn't find a good solution.

[annevk]

Well, per the current model a shared/service worker that is cross-origin isolated would not be put in the same process with something that is not cross-origin isolated. It's not really clear how you delegate to shared/service workers though and whether shared workers need to be isolated the way they are for secure contexts. There's quite a few gotchas it seems with using permission delegation here (and perhaps in general when workers are important).

[yutakahirano]

@domenic, do you have any opinions?

[domenic]

Sorry about not responding earlier. I can be more responsive on this going forward, now that I understand it more fully.

I think shared/service workers should be treated as "roots". Their cross-origin isolated status should only be controlled by themselves and the headers they set.

For dedicated workers, automatically inheriting from their parent seems fine, since they must be same-origin to their parent. (Or they can be data: URLs, but data: URLs also inherit this sort of thing, generally.)

---

On this PR generally, it seems like we will need to refactor things so that the crossOriginIsolated getter steps can be called from elsewhere. In particular I wonder if it's confusing to have separate "cross-origin isolated" (the boolean set at creation time) and "effectively cross-origin isolated" (what the getter steps return). Plus the "cross-origin isolated permission" boolean. I'm not sure what the best architecture is though, and perhaps it will be modified given my above comments...

[yutakahirano]

How about the following?

---

Environment settings object

An environment settings object is an environment that additionally specifies algorithms for:
...

An effective cross-origin isolated: A boolean represents whether it is allowed to use APIs that requires cross-origin isolation.

Script settings for Window objects

The effective cross-origin isolated: Return the logical conjunction of the surrounding agent's agent cluster's cross-origin isolated and whether its associated Document is allowed to use the "cross-origin-isolated" permission.

Script settings for workers

The effective cross-origin isolated: Return worker global scope's effective cross-origin isolated.

(Note: worker global scope's effective cross-origin isolated is defined similarly to the current change).

The WindowOrWorkerGlobalScope mixin

self.crossOriginIsolated returns the relevant settings object's effective cross-origin isolated.

[domenic]

That sounds pretty good to me! Two notes:

• Perhaps better names would be something like "COOP+COEP headers set" (for Window's current "cross-origin isolated") and "cross-origin isolated" (for the settings object field, which we call above "effective cross-origin isolated"). I would like to avoid any object having cross-origin isolated = true if thatObject.crossOriginIsolated returns false.

• As usual, adding new fields to settings objects requires modifying https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm and https://drafts.css-houdini.org/worklets/#script-settings-for-worklets

[yutakahirano]

Updated.

I like "agent cluster's cross-origin isolated" more than "COOP+COEP headers set". We use the value for important decisions (e.g., document.domain behavior) and while it may not be exposed via crossOriginIsolated I think "agent cluster's cross-origin isolated" is more important, and deserves a simpler name.

I will create PRs for service workers and worklets.

[domenic]

I like "agent cluster's cross-origin isolated" more than "COOP+COEP headers set". We use the value for important decisions (e.g., document.domain behavior)

Interesting. And I guess we don't want to turn document.domain back on if the permission isn't delegated. OK, that makes sense then.

I wonder then about the name "effective cross-origin isolated". Maybe "allowed to use cross-origin isolated features"? Any bikeshedding is welcome. (But there's no need to update the PR for naming stuff right now; we can wait until everyone is settled to go through more changes.)

I will create PRs for service workers and worklets.

Actually, since I already have PRs out for related changes, how about you just add comments to w3c/ServiceWorker#1527 and w3c/css-houdini-drafts#998 saying what the algorithms should be, and I can edit my PRs to include them?

[domenic]

What is the reasoning for this? data: URL workers have their own separate agent clusters, so I would think they should be allowed to use cross-origin isolated features...

[yutakahirano]

This is because "data:" origins are opaque. We need these worker-specific logic because permission policy doesn't work with workers (w3c/webappsec-permissions-policy#207).

[domenic]

Right, they're opaque, so they should be treated as cross-origin isolated, right? So this should be set to true, if anything...

[yutakahirano]

I'm talking about hte "cross-origin-isolated" feature. The worker is cross origin compared to its owner, and it is not able to set permission policies for data: workers so the default policy ("self") is applied, which means effective cross-origin isolated is false.

[yutakahirano]

Also, according to https://html.spec.whatwg.org/multipage/webappapis.html#obtaining-a-worker/worklet-agent and https://html.spec.whatwg.org/multipage/webappapis.html#obtain-a-dedicated/shared-worker-agent a dedicated worker's agent cluster is its owner's.

[domenic]

Sorry, I was confused with data: URL iframes, which are their own agent cluster. OK, this is probably fine... I'll do a more full re-review.

[domenic]

Hmm, upon re-reviewing I am still confused why we want to prevent data: URL workers from using cross-origin isolated features. I know they have a different origin. However, for other important things, we inherit from the parent, even though they are cross-origin. For example, for embedder policy.

[yutakahirano]

Yeah, we can choose either way. Ultimately that will be resolved in w3c/webappsec-permissions-policy#207 but to be honest I don't want to be blocked by the issue. I'm fine with either options, but starting with effective cross-origin isolated: false and changing the value to true if necessary (when w3c/webappsec-permissions-policy#207 is resolved) seems safer than the other option from the compatibility perspective.

Please note that for COEP we didn't have options. As the owner and the worker share the same agent cluster we needed to inherit the value when the owner had COEP: require-corp.

@annevk do you have opinions?

[domenic]

Got it. I understand now, and agree this is a good conservative default. I will push a commit adding a note about that reasoning.

[yutakahirano]

Thank you the review! Somehow "commit suggestion" didn't work so I addressed the comments manually.

Reg feature and permission: I was under the impression that spec authors were replacing "feature" with "permission" (w3c/webappsec-permissions-policy#359), but I'm happy to accept your suggestion in this change.

[domenic]

@clelland are Permissions Policy things called "permissions" now, or still "features"? The spec still talks about features (example).

[domenic]

Hmm, upon re-reviewing I am still confused why we want to prevent data: URL workers from using cross-origin isolated features. I know they have a different origin. However, for other important things, we inherit from the parent, even though they are cross-origin. For example, for embedder policy.

[domenic]

In IRC @annevk suggested "cross-origin isolated capability" as the best name for what this PR calls "effective cross-origin isolated". I am happy with that as the final name. I will push a commit renaming in that direction.

[domenic]

I pushed a commit with editorial changes and additions. This LGTM. I believe also the discussion in #5435 was positive enough from @annevk that we should count that as Mozilla support; @annevk, please let us know if you disagree.

So I'll merge this on Monday or Tuesday unless I hear otherwise. In the meantime, you could file bugs on the various browser issue trackers, pointing to this PR and the web platform tests PR.

[yutakahirano]

Thank you! I filed a bug for each implementation.

[annevk]

To follow-up here, Mozilla is indeed supportive of this and happy to follow Chrome.