Expose isolation state to the page?

[domenic]

Now that we're no longer based on origin policy, a page can't tell whether isolation succeeded by using self.originPolicyIds. They have to instead check for side effects, e.g. whether setting document.domain succeeds or whether sending a WebAssembly.Module works.

Should we expose an indicator on the page, e.g. a self.originIsolated boolean, to make this easier?

The main use case here would be to let pages track when origin isolation fails, and send this back to the server as telemetry. Examples of how such failures could occur:

• If you messed up your header syntax.
• If you configure your server in a way that does not uniformly send Origin-Isolation headers for all pages on the origin, then loading a page without the header will prevent future loads in that browsing context group from gaining isolation.

Both of these failures should trigger console warnings, but that doesn't help with the telemetry use case.

Perhaps an alternate approach to the problem would be to add reporting API support, hmm. (Or we could do both!)

[domenic]

I've heard from folks testing this in origin trial that this state would, indeed, be useful, for basically the reasons stated above. So I'm inclined to spec this as window.originIsolated.

I think I'll omit it from workers since, as discussed in the README, origin isolation is only relevant for documents.

[annevk]

There's still whatwg/html#5476 and such, but yeah, hopefully.

[domenic]

While speccing and implementing this I've come up with a couple issues worth discussing:

• What do we do for detached iframes? Add the Origin-Isolation header whatwg/html#5545 figures out the return value via the Window's browsing context's group's historical agent cluster map, and the browsing context becomes null in that case. So that would cause it to start returning false. That's kind of weird though; being origin-isolated is an immutable property of the window. (On the other hand, if you re-insert into the parent document, you get a new Window, so it's not like it's flipping back and forth... it's just a one-way transition to false.)

  I'm inclined to leave this as returning false for now.

• Should this return true when a Document's site is the same as its origin? I.e. in the two cases where obtain a site returns an origin. I think probably "yes" since those pages are origin-isolated (i.e., their agent cluster key is an origin)... However, that's a bit trickier to implement.

Thoughts on the above welcome, even if they're just agreeing with my conclusions :).

[annevk]

I would have expected this to work like cross-origin isolated, with a boolean on the agent cluster (which argues for exposing it in dedicated workers as well, after all).

It's an interesting question whether an agent cluster that's keyed on an origin (sandboxing, IP address that's a secure context) gets this by default or whether they still need to opt-in.

[domenic]

I would have expected this to work like cross-origin isolated, with a boolean on the agent cluster

We could do that, but it'd be redundant with the information in the BCG's historical agent cluster map. So I'm not sure about the added value. We'd basically have to pick a time to copy from the historical agent cluster map into the boolean.

(which argues for exposing it in dedicated workers as well, after all)

I could go either way, but I kind of like keeping it on Window only from an author perspective, since it emphasizes that this only impacts things in window agents.

It's an interesting question whether an agent cluster that's keyed on an origin (sandboxing, IP address that's a secure context) gets this by default or whether they still need to opt-in.

Note that this only impacts the boolean return value. They "get" origin isolation itself automatically.

[annevk]

Well, it's not redundant upon discarding its browsing context, despite still being isolated. I think that indicates the model is wrong. I guess I could see not exposing this to dedicated workers, but if someone wanted to use this as a signal that it's okay to import some sensitive stuff from a server, that would seem useful in dedicated workers too. (The latter is easy to address in the future though.)

[domenic]

Hmm OK. Well, I guess I'll copy the boolean around then. And it should be on all workers, not just dedicated, right? If it's supposed to be agent cluster level?

[annevk]

So that's an interesting question. Shared/service worker agents belong to an agent cluster that in principle is origin-bound, but in practice implementations might put them in the same process as an window agent's agent cluster keyed on a site.

For cross-origin isolated it's important that cross-origin isolated agent cluster processes do not mix with non-cross-origin isolated processes, but maybe that doesn't matter here as this mostly-but-not-entirely cares about disabling document.domain and shrinking the window agent's agent cluster, right?

If it doesn't matter, I think it's only needed for window agent's agent clusters, but maybe since all agent clusters are a single type it's hard to avoid saying something for the others.

[domenic]

this mostly-but-not-entirely cares about disabling document.domain and shrinking the window agent's agent cluster, right?

Right. Origin isolation isn't intended to give you security guarantees like crossOriginIsolated does. This boolean is basically meant as a reliable, synchronous way of telling whether sending WebAssembly.Modules to cross-origin same-site pages will succeed, or whether document.domain will work. (Maybe the domintro should stress that...)

---

So I think we have a two possible coherent stories:

1. originIsolation means "is this global's agent in an origin-keyed agent cluster".

   • This returns true for opaque origins, IP addresses, etc.
   • This works inside dedicated workers, basically telling them information about their parent
   • This does not exist inside shared/service workers, since their agent clusters float freely and are not in any BCG agent cluster map (i.e., they have no notion of keying)

2. originIsolation means "is my postMessage() and document.domain more restricted than usual"

   • This returns false for opaque origins, IP addresses, etc. They are exactly as restricted as before.
   • This does not exist inside workers, since as discussed in the README there is no observable impact for them.
   • Maybe the name should instead be originIsolationRestricted or something? That loses the symmetry with crossOriginIsolated, but that's probably a good thing on this branch.

Laying it out like this, I lean slightly toward (2). It also has a stronger correlation with the Origin-Isolation header, which seems nice, given the use cases in the OP. (Imagine a poor web developer monitoring their metrics and wondering why so many pages are suddenly reporting origin isolation, only to realize it's because some other team started using sandboxed iframes.)

What do you think?

[annevk]

2 sounds fine to me (though to be clear I do think we want to track this on the agent/agent cluster directly as discussed above).

[domenic]

I've updated whatwg/html#5545 with (2); feel free to review. (In general, that PR is ready to go except for the HTTPS restriction.)

[domenic]

This returns false for opaque origins, IP addresses, etc. They are exactly as restricted as before.

A subtlety here is what we do for opaque origin/etc. pages that explicitly request origin isolation with the header. The current HTML PR returns false, saying that the header was a no-op so no restrictions are applied and window.originIsolationRestricted should reflect that. But this imposes some extra complexity on both the spec and the implementation.

So here's another model to consider:

3. originIsolation means "did the Origin-Isolation header (potentially from another same-origin page in the agent cluster) take effect"
   • This treats opaque origins, IP addresses, etc. the same as normal pages. The getter returns true if the header is sent and there was no document previously loaded into the agent cluster without the header sent.
   • This does not exist inside workers, since the header is ignored when loading them.
   • In this case the name should stay originIsolation, I think.

(3) vs. (2) amounts to removing whatwg/html@493762e#diff-36cd38f49b9afa08222c0dc9ebfe35ebR88893-R88899.

---

Also worth noting: it looks like Chromium returns undefined for most properties of the Windows of removed iframes, so we're unlikely to be able to pass the test that motivates tracking this on the agent cluster. But I'm still fine to keep that in the spec and tests.

[domenic]

Some discussion with @annevk in IRC suggested that (2) is probably slightly more useful for authors than (3), despite the moderate increase in implementation and spec complexity.