Origin isolation

[domenic]

Hello TAG!

I'm requesting a TAG review of origin isolation.

Origin isolation allows web developers to opt in to giving up certain cross-origin same-site access capabilities (namely synchronous scripting via document.domain, and postMessage()ing of WebAssembly.Module instances). This allows browsers to potentially segregate the origin into its own process. The developer can also provide hints to the browser as to why they are doing so, in the hopes of guiding the browser's process allocation.

Note that this opt in and the accompanying hints are delivered via origin policy (#127).

• Explainer: https://github.com/WICG/origin-isolation/blob/master/README.md
• Security and Privacy self-review: https://github.com/WICG/origin-isolation/blob/master/security-and-privacy.md
• GitHub repo: https://github.com/WICG/origin-isolation
• Primary contacts (and their relationship to the specification):
  • Domenic Denicola (@domenic), Google, specifier
  • W. James MacLean (@wjmaclean), Google, implementer
• Organization/project driving the design: Chromium
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5683766104162304

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the work on this design is being done (or is intended to be done in the future): WHATWG (for the portions that end up in the HTML spec); probably WebAppSec via WICG (for the portions that end up in the Origin Policy spec)
• Existing major pieces of multi-stakeholder review or discussion of this design:
  • The issue tracker
  • Some TPAC discussion
  • Mozilla standards positions repo issue, resulting in worth prototyping
• Major unresolved issues with or opposition to this design: there is some discussion about surface syntax for the hints in Bikeshedding issue on header design WICG/origin-agent-cluster#18.
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[domenic]

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.

[atanassov]

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.

[domenic]

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?

[atanassov]

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.

[annevk]

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

[domenic]

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?

[dbaron]

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.

[annevk]

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.

[domenic]

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.

[atanassov]

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.

[domenic]

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 whatwg/html#6192.

[kenchris]

I support that rename