FWIW, parts of the proposal being in the FAQ is somewhat confusing, but an interesting trick to get me to read that.

Sorry for the confusion, Anne. I wasn't trying to be tricky. Which portions would you have appreciated seeing earlier in the document?

The details behind Transport/Isolation/Injection as they seem a rather core part of the proposal. And reading it again I also realize it does not help with window.frames and "cross-origin" history manipulation, which is fine, but adds some confusion as they are part of the threat model.

it does not help with window.frames and "cross-origin" history manipulation, which is fine, but adds some confusion as they are part of the threat model.

I think that COOP/COEP would help mitigate this threat (insofar as it would require victims to opt-into being attackable (which, hopefully, they wouldn't do)). Given the cross-origin/cross-frame nature of both window.frames and window.history, it seems clear that at least this aspect of their behavior should be gated on those features. As you say, they fit the threat model.

The question, then, is how we ratchet down over time. I think that's more a practical question of deployability than one of principle. It seems quite possible to begin holding new APIs to a reasonable standard, and at the same time begin to figure out how to hold older APIs to the same.

The primary feedback I'm hoping to get at this point is whether the threat model itself is the one we ought to keep in mind when considering how to ship new features. If so, then we can figure out together what lines we'll be able to practically draw around which set of APIs.

Two questions from looking briefly at the explainer:

1. the Proposal section has a list numbered 1/2/3/4. I think use case 1 corresponds to Transport, 2 corresponds to Injection, and 4 corresponds to Isolation. Is 3 also about Isolation?

2. Is there an explainer somewhere for the new isolation primitives (COOP, COEP, CORP, etc.)?

Thanks, @dbaron!

The Proposal section has a list numbered 1/2/3/4. I think use case 1 corresponds to Transport, 2 corresponds to Injection, and 4 corresponds to Isolation. Is 3 also about Isolation?

Exactly. 3 and 4 are different aspects of isolation, hopefully mitigated to some extent by COOP and COEP, respectively. I'm happy to combine them if it makes things clearer.

Is there an explainer somewhere for the new isolation primitives (COOP, COEP, CORP, etc.)?

Some of the details in @arturjanc's excellent https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit are outdated, but the broad strokes haven't changed.

@annevk recently went through the doc to make it in line with spec changes we've made over the past couple of months, so it should be mostly up-to-date.

The MDN page about SharedArrayBuffer has other useful high-level information about the various isolation primitives.

Yves and I looked at this during our Wellington F2F. In general we're happy with the approach, our primary concerns are about how the additional securer modes will be invoked. It seems like a proliferation of additional HTTP headers (COOP, COEP, et al) and their interactions is getting to be fairly complex and will be difficult for people to reason about and deploy correctly.

While not directly part of this issue, we'd like to see some work to consolidate and harmonize the mechanisms that would trigger the different modes. e.g. can 'Isolation' be governed by a single CSP like header, and CSP cover all of 'Injection'?

For COOP/COEP in particular, note that the restrictions they impose are orthogonal; we expect them to be deployed independently, and for those deployments to take some time and effort. This possibility of incremental deployment is one reason for the design we ended up with, in addition to the philosophical stance that smaller, more primitive features are the right place to start. That said, I agree that it is complicated, and some higher-level abstraction might be valuable. That feels like something we could layer on top, Isolate-Me: ?1-style, in the future.

+1 to what @mikewest from an author's point of view. Given that the different mechanisms here control different aspects of the application's behavior (and, at least for the time being, serve different use cases), it seems good for developers to have separate switches to individually test and deploy each mechanism.

In the long term, I would like to consolidate the individual features into something easier for developers to understand, similar to how the Scripting Policy concept merges the relevant elements of CSP and Trusted Types. This will also make it easier to move towards enforcing them by default in some classes of applications, potentially leaning on this proposal. But I don't think we get there without the individual primitives -- if we cannot deploy them separately, we certainly won't be able to deploy them as a bundle.

@plinss, @torgo: This is still labeled as "pending external feedback". Is there anything more y'all are looking for?

Thanks Mike! We updated the labels and we're going to pick it up on our plenary call this week.

Peter Dan and I talked again about this during our last breakout. We are still worried that the added complexity might lead to those beneficial security measures being rendered useless by a bad usage of them, so we encourage to put emphasis on deployment and guidance to avoid people relying on bad pre-baked solutions.

Do you have any guidance as to what kind of guidance would be reasonable for us to provide as we iterate on this proposal? After reading the minutes, it's not really clear to me what aspects of this proposal you see as risking confusion or causing complexity. If there's something we could reasonably do to reduce either or both, I'd love to do it.

Ping. :) I hope to start rewriting the secure context doc sometime this week or next, and would love to incorporate y'all's thoughts around avoiding complexity.

To me, what might cause confusion is the deployment of extra HTTP headers, like COOP for [SecureContext=Isolation]. The text says "the page needs to", which ask for a global evaluation of the need, but I fear that some people will find recipes like "for this API to work the way you want, set COOP to this and be done" instead of figuring out if it can be done another way to preserve stricter security settings. The fact that extra parameters on [SecureContext] are per API and page modifiers per... page might be a source of confusion.

My expectation is that each given feature will be defined with a set of requirements in IDL (as we do for [SecureContext] today). Web developers wouldn't need to decide what the set of restrictions for a particular API would be, but we'd collectively decide things like "performance.measureMemory requires COOP/COEP."

It seems to me that that's going to make things less complicated, as we'll have a few buckets into which to put each feature, rather than trying to craft individualized mitigations with a specific threat model for a specific feature.

My hope is that the decision for developers then is "Do I need this API?", and the requirements are clear.

I'll take all this into account when sketching out the document. Thank you!

Hi @mikewest - we're just discussing in our TAG virtual f2f - we're happy to close this issue and thanks for being receptive to our feedback. As noted, we remain concerned about complexity for the developer. We'd like to encourage you to bring the work into "WebAppSec + IDL" (as indicated above) as soon as possible.

Hey TAG folks! The WebPerfWG decided to limit the resolution of performance.now() in non-isolated contexts, and I'm now interested in shipping this in Chromium.

Generally, this seems to fall under the same considerations as this TAG review, so I'm curious if y'all would want me to open a separate TAG review, look at this under the lens of this one, or consider this as something that falls under this already-reviewed issue. Thoughts?