Renaming the Origin-Isolation header

[domenic]

Recall that origin isolation is specified in terms of the web-observable effects of deprecating certain legacy APIs. This gives the browser the option to put the origin in its own process, but it does not guarantee it. In particular:

• Some browsers might not implement the technology necessary to do so (out-of-process iframes)
• Some browsers might decide that the memory overhead is not worthwhile, depending on the device in question (e.g. low-memory Android phones)
• Some browsers might use other isolation technologies, like (for Chromium) "Blink isolates", to give performance isolation but not the same security-isolation that processes provide

Additionally, there is the case where the user may have visited another, non-isolated page on the origin, in the same browsing context group, which makes origin isolation not apply at all (much less give process-per-origin semantics).

Unfortunately, Chrome folks have noticed a few instances where people thought the Origin-Isolation header gave security guarantees:

• One internal team bundled COOP and Origin-Isolation, on the misunderstanding that they were both security isolation primitives
• https://bugs.chromium.org/p/chromium/issues/detail?id=1151223 was originally filed as a security bug report, from a member of the Edge security team, talking about how to use blob: URLs to "escape" origin isolation.
• Sometimes we've given internal talks about security projects, and said unfortunate things like "first we did site isolation, and now we're allowing you to opt in to origin isolation!" I.e., the Chrome security team has been using the "site isolation" branding for years as as security feature indicating site-per-process, so the fact that origin isolation is not necessarily origin-per-process makes for some gaffes.

As such, we're considering if it might be better to rename the header, so that it's more obvious that (a) it's not security isolation in the same sense of "cross-origin isolated"; and/or (b) it's a request that not always able to be fulfilled. Ideas we've come up with so far are:

• Origin-Performance-Isolation: a little narrow and not perfectly accurate, but hopefully makes people realize the main use case is not security-related.

• Origin-Keyed-Agents or Origin-Keyed-Agent-Cluster: extra jargon, which should hopefully make people read the documentation. Could also prefix with Request- to indicate the failure mode where something else in the BCG prevents it from taking effect.

• Origin-Keying or Request-Origin-Keying: similar to the previous bullet, but a little less jargony

Any thoughts? @annevk

[annevk]

How about Origin-Agent-Cluster? (This also goes back to maybe having two types of agent clusters, site agent clusters and origin agent clusters.) I think using "agent cluster" is rather good as it tells you exactly what you will get.

@littledan @syg @codehag if we go down this route this would be the first time "agent cluster" (or even "agent") ends up exposed as a term. What's a good way to get feedback on this from others in TC39?

[syg]

Had a chat with @domenic and I'm convinced that Origin-Agent-Cluster is a fine name in the context of using unfamiliar (and nuanced) jargon to entice web devs to look up what it does.

My original concerns, which I've convinced myself are fine:

1. https://tc39.es/ecma262/#sec-agent-clusters has normative requirements on the termination strategy for Agent Clusters. The requirement is that all agents within an agent cluster be terminated at once if no reporting API is available. A naive reading might be that agent clusters are a maximal set of termination, but the requirement is only that it is minimal set of termination. Since this is previously unexposed jargon, there shouldn't be any confusion to the web dev here.

I'd like to confirm though: implementations can all meet the minimal set of termination requirement when this header is set, right?

2. Devs might be confused that the term "Agent" says something about threading, so this header is for threading, given that it's mostly pops up in the context of SABs. Again, given how relatively obscure "Agent" is, I don't think this is a big deal.

[annevk]

If they can meet it today, they should still be able to meet it, given it's a minimum and this strictly subsets the scope. (It is kinda about threading in that you might get more threads/processes for your site, depending on the implementation, but yeah, no guarantees.)

[syg]

We chatted on the TC39 editor call about surfacing the name agent cluster. We have no concerns nor do we think it even needs plenary sign-off, so go ahead.

[annevk]

A point @sideshowbarker brought up on IRC is that the API should probably be renamed as well and I guess the feature name in general?

cc @whatwg/documentation

[domenic]

Yeah. For the feature name, I'm thinking "Origin-keyed agent clusters"?