-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Renaming the Origin-Isolation header #6192
Comments
How about @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? |
Had a chat with @domenic and I'm convinced that My original concerns, which I've convinced myself are fine:
I'd like to confirm though: implementations can all meet the minimal set of termination requirement when this header is set, right?
|
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.) |
We chatted on the TC39 editor call about surfacing the name |
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 |
Yeah. For the feature name, I'm thinking "Origin-keyed agent clusters"? |
Also renames the feature from "origin isolation" to "origin-keyed agent clusters" and renames the getter from window.originIsolated to window.originAgentCluster. Closes #6192.
Also renames the feature from "origin isolation" to "origin-keyed agent clusters" and renames the getter from window.originIsolated to window.originAgentCluster. Closes #6192.
Follows whatwg/html#6192.
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:
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:
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
orOrigin-Keyed-Agent-Cluster
: extra jargon, which should hopefully make people read the documentation. Could also prefix withRequest-
to indicate the failure mode where something else in the BCG prevents it from taking effect.Origin-Keying
orRequest-Origin-Keying
: similar to the previous bullet, but a little less jargonyAny thoughts? @annevk
The text was updated successfully, but these errors were encountered: