Re: [w3ctag/design-reviews] COEP reflection (Issue #742)

To pile on a bit:

> However, it seems like by allowing authors to detect when they're in a more locked-down environment, we're really giving them the ability to determine that they're in a more permissive environment

I think this is a misunderstanding. Or, at least, it's not as clear cut as something like Secure Contexts, as COEP is a tradeoff.

COEP imposes a restriction on your ability to load resources. Rather than being able to load anything at all via `no-cors` requests (e.g. `<img>`/`<script>`), a COEP of `require-corp` ensures that you can only load resources that [opt-into being loaded in your context](https://resourcepolicy.fyi/). In one sense, then, COEP reduces your capability.

In another sense, though, COEP is part of a structure that we believe allows us to enable powerful primitives like Shared Array Buffers. which could potentially enable side-channel attacks. If you opt-into COEP and COOP, you get SABs on the one hand, memory profiling APIs on the other, and whatever else we come up with behind the [`[CrossOriginIsolated]`](https://webidl.spec.whatwg.org/#CrossOriginIsolated) IDL attribute.

If we've done our jobs, developers on both sides of the COEP opt-in are appropriately empowered. Without `COEP: require-corp`, sites can include resources through `no-cors` requests, but they can't attack those resources with high-powered primitives that enable Spectre. With `COEP: require-corp`, sites can use those powerful primitives, but can't attack unwary resources.

With that in mind, I'm a little confused about the scenarios that you're worried about. Can you help me understand what developers would do with explicit reflection of a page's COEP that would leave the web worse off than it was in the status quo?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/742#issuecomment-1195496095
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/742/1195496095@github.com>

Received on Tuesday, 26 July 2022 13:38:00 UTC