Add the Origin-Isolation header

[domenic]

See https://github.com/WICG/origin-isolation.

• At least two implementers are interested (and none opposed):
  • Chromium
  • Gecko
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/tree/master/origin-isolation
  • More coming: Outstanding web platform tests to write WICG/origin-agent-cluster#27
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1042415
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1665474
  • Safari: …

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

(Obsolete) Things that I needed help on but are now fixed:

• This has a similar problem as Add cross-origin opener policy #5334 in that it wants to do a secure context check before the environment settings object/Window/Document are created. It seems like we'll need to refactor the secure contexts spec a good bit, for both of them... But I'd like someone to confirm that line of thinking before I go off and do so. /cc @mikewest

• I'm not sure if changing the agent cluster key automatically makes document.domain a no-op, or not. I think by my current reading, IsPlatformObjectSameOrigin does not care about agent clusters, so this PR as-written does not prevent cross-agent-cluster sync access. Should we add an agent cluster check to IsPlatformObjectSameOrigin, and let the domain component change via the document.domain setter? Or should we store an "is origin-isolated" boolean on the Document, and bail out of the document.domain setter algorithm if that boolean is true? The former seems a bit nicer, but I'm unsure if there's any observable difference between the two. /cc @dtapuska

---

/browsers.html ( diff )
/browsing-the-web.html ( diff )
/iana.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/origin.html ( diff )
/webappapis.html ( diff )
/window-object.html ( diff )

[domenic]

Hmm, I think there is a big difference between just changing IsPlatformObjectSameOrigin, and storing a boolean on the document. If we only change IsPlatformObjectSameOrigin, then other same origin-domain checks will still pass. So I think we need to store a boolean, and also write tests for other such checks.

[annevk]

I like the idea though that changing the keying of the agent cluster is what disables document.domain. Unfortunately there's no clear way back from an agent cluster to its key. Setting a flag on the agent cluster similar to cross-origin isolated is something you could do though. That also avoids having to maintain a per-document boolean.

[domenic]

Did you see my latest commit? I think with the historical agent cluster key map, there kind of effectively is such a way back now.

[annevk]

Why is oiHeader indexable as such?

[domenic]

All structured header items are a pair of the actual value plus the parameters.

[annevk]

I guess Fetch should define how they translate to Infra then if we want to do this. Might also be nice for parameters.

[domenic]

I think the concepts used are already Infra concepts: pairs, maps, booleans, ...

[annevk]

Heh, if only they would have referenced it as well. But okay, that should make any formal equating pretty straightforward.

[annevk]

I noticed you still used "structured header boolean true". If they are the same we don't have to do that, right?

[annevk]

Most of this looks really good, but I think we should stick more to COOP+COEP design in a few places.

[annevk]

It's too early, but I can't help but think we want an abstraction to make this less awkward and encourage consistency in handling. No great ideas other than collapsing failure into null though. (Or maybe that is what we should always do?)

[domenic]

I do suspect collapsing failure into null might be what all callers want. Perhaps let's reassess after this lands, COOP lands, COEP lands, and CORP gets converted to a structured header. (And maybe by then Permission Policy / Document Policy might be ready too.)

[annevk]

I prefer the approach in that PR by modifying "obtain a similar-origin window agent" and inlining "obtain an agent cluster key".

I also wonder, if we did that, could we modify browsing context group's historical agent cluster key map before invoking that algorithm so it could use that map to make decisions, requiring us to pass less state around?

Furthermore, now that we tie state to browsing context groups, it almost seems like we should have different types of them. Those that carry a historical map and those that are cross-origin isolated. But some asserts is probably enough initially.

[domenic]

https://github.com/whatwg/html/pull/4734/files#r405428958 indicates we want to fold all three algorithms together. I'll give that a shot...

[domenic]

This turned out pretty nicely.

I didn't address your latest paragraph so I'll leave this un-resolved. If you have concrete suggestions (either for now or as a followup) then let me know; otherwise I wasn't sure where to go with it.

[annevk]

I was mostly wondering if we should make normal browsing context groups and cross-origin isolated browsing context groups more clearly mutually exclusive. We can address it in the context of cross-origin isolated.

[annevk]

It's unfortunate PR Preview no longer seems to work here. I added a space to try to trigger it, but it's not working.

[annevk]

Apart from the map issue I realized that another thing we need to agree on is how cross-origin isolated and origin-isolation restricted play together.

My initial take was that cross-origin isolated implies the latter, but this would do the wrong thing for things that are already keyed on origin. Perhaps we should revisit that as allowing those to be origin-isolation restricted despite it not meaning anything would simplify several things at this point?

[annevk]

I was mostly wondering if we should make normal browsing context groups and cross-origin isolated browsing context groups more clearly mutually exclusive. We can address it in the context of cross-origin isolated.

[domenic]

My initial take was that cross-origin isolated implies the latter, but this would do the wrong thing for things that are already keyed on origin. Perhaps we should revisit that as allowing those to be origin-isolation restricted despite it not meaning anything would simplify several things at this point?

The way I was envisioning it was that cross-origin isolated just causes requestsOI to be true (regardless of the Origin-Isolation header). Then the logic in this PR takes over and oiRestricted (and thus window.originIsolationRestricted) will be false if you were already keyed to an origin. But window.crossOriginIsolated would be true.

WDYT?

[annevk]

That could work I think. We'd change

<li><var>requestsOI</var> is true</li>

to also check for bcg's cross-origin isolated and where we write into the map (TBD) we add another conditional to only do so if bcg's cross-origin isolated is false.

[domenic]

where we write into the map (TBD) we add another conditional to only do so if bcg's cross-origin isolated is false.

I don't think this would be strictly necessary, because cross-origin isolation ensures consistency within a BCG itself. So the map would just be redundant for any BCG with cross-origin isolated pages; writing to it would be fine (and have no effect).

I guess maybe that gets to your point above about making normal BCGs and COI BCGs mutually exclusive.

[annevk]

If we did that I think we'd have to add a note, but maybe we should do that either way. (Agreed that there is no observable difference.)

[domenic]

This now has a secure context check. It, like COOP, needed to check the response's HTTPS state, so maybe we should have an abstraction? There's no great one though, since reservedEnvironment and response are separate anyway. The best we could do is something like

If request and reservedEnvironment do not represent a new secure context, then...

although I think there should be better names.

Anyway, this is now blocked on WICG/origin-agent-cluster#31, I guess.

[annevk]

into? We only have two instances of "in to" and both look suspect.

[domenic]

I think for cases like "zoom in" or "opt in" it's best to keep those phrases separate from the "to". There's nothing very concrete on this online; e.g. https://english.stackexchange.com/questions/422848/opt-into-vs-opt-in-to is unanswered and https://forum.wordreference.com/threads/opt-in-or-opt-into.3560327/ is wishy washy. The headline at https://www.wsj.com/articles/more-parents-opt-into-opt-out-1429893574 separates them at least.

[annevk]

If we change this whole addition to start with "Otherwise, if" we could keep the historical agent cluster key map and cross-origin isolated separated. I would somewhat prefer that as the less (unneeded) bookkeeping the better.

(It would also allow more easily for introducing different group types in the future.)

[domenic]

Hmm, I'll give it a try.

[annevk]

This part of the change is wrong. I initially read the algorithm like this, but that ends up making the map redundant as it would only ever contain origin values. The requestsOI conditional has to be part of overwriting the key only.

[domenic]

I think I misunderstood what you meant by keeping them separate; PTAL.

[annevk]

This works, but I think what would also work (and is preferable) is keeping this as

Otherwise:

• If requestsOI is true, set ...
• Modify map.

My "Otherwise, if" comment was about the step above this one.

[domenic]

Ah, thanks, that makes sense now. Done.

[domenic]

Alright, I've updated all the tests to use the standard window.originIsolated getter. And, the test suite is basically finished. (A couple PRs around popups are still going through review but they should land soon.) So, I'm now comfortable with this getting merged.

@annevk, want to do the final review?

[annevk]

This looks great apart from these minor nits around initializing requestsOI. Nice work!