Hi TAG! A friendly ping for any thoughts you have here.

I'll note that the concept has been simplified a couple of times, first moving from origin policy to a header-based design, and today dropping the hints in favor of a simple boolean. We're hoping to start an origin trial in Chrome within the next 6 weeks for this new, simpler version.

Hi @domenic! We did start the review just didn't write replies quickly enough, sorry.

The overall use case, feature proposal and explainer look great we have only few comments/questions (@hober will follow up with more).

As you've been working on this solution, have you considered and/or tried to make the feature behind a functional API rather than UACH? In other words, express hinting author needs via something more explicit like a web workers API that controls what will be in a separate process? In general I feel like explicit APIs are better than hinting as they give web developers better predictability.

I'm a bit unsure what your last paragraph is asking. How does it interact with the non-goals section in https://github.com/WICG/origin-isolation#objectives ? And what is UACH?

Oh well, it seems like my reply from 10 days ago was just sitting in my edit box here :( sorry for delay.

Further, for whatever reason when reading and writing the comment to you I was thinking about User Agent Client Hints and referred to your response header additions as UACH.

As to the non-goals section you pointed out, I'm assuming you're referring to the 2nd point about 'Give web developers visibility into process allocation.". I did see this and also the first goal where you state the isolation is guaranteed and also "consistent web-developer-observable behavior regardless of implementation choices". This all led me think about this feature as better exposed through an explicit API, similar to web worker. Was that something you considered and rejected?

Again, sorry for the delay. Let's try and push this to completion soon.

By API do you mean something you call from JavaScript? How would that work?

This all led me think about this feature as better exposed through an explicit API, similar to web worker. Was that something you considered and rejected?

I too am confused by what feature you're referring to. The consistent web-developer behavior that origin isolation gives is allowing developers to opt in to the removal of some edge-case functionality (document.domain and sending WebAssembly.Modules to cross-origin same-site destinations). Are you using "this feature" to refer to those removals? What would an explicit API for those removals look like?

So one thing that I found difficult reading the explainer is that it makes a number of references to documents that are cross-origin and same-site. After reading the definitions of these concepts I think this is something that can result from use of document.domain, although I'm not particularly confident given that I didn't find a formal definition of "cross origin" (I found "same origin" and "same origin-domain"). Given the frequent references to documents that are cross-origin and same-site, it might be good if the explainer gave a brief summary of what that means so that it doesn't require digging through the definitions to understand it.

We should maybe define cross-origin as meaning "not same origin" and cross-site as meaning not https://html.spec.whatwg.org/#same-site as they are often used in less formal settings. But yeah, the minimal process boundary for browsers is a site, not an origin, due to document.domain. And origin isolation as well as COOP+COEP try to change that largely by disabling document.domain but also by shrinking the agent cluster boundary.

A simple example of two pages that are cross-origin but same-site are https://www.example.com and https://example.com. (no document.domain involved.) I'll add this to the explainer.

We reviewed this proposal one more time during our June 29 breakout. At this point we are happy to see it continue to evolve with the HTML community.

@dbaron issue about clarifying the concepts of cross-origin and same-site seems well handled.

@atanassov (my) issue about exposing the functionality behind an API such as document.domain has been self-answered after re-reading the explainer and your additional comments, thus, I consider it non-issue at this point.

Given all issues have been address to our satisfaction, closing the review.

FYI, we are planning to rename the feature to "origin-keyed agent clusters" (the header would be Origin-Agent-Cluster), as we encountered folks who thought that "isolation" meant security guarantees. See more details in https://github.com/whatwg/html/issues/6192.

I support that rename