search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
332 stars 56 forks source link

COEP reflection #742

Closed ArthurSonzogni closed 1 year ago

ArthurSonzogni commented 2 years ago

Bonjour le TAG!

I'm requesting a Early design review of COEP reflection.

Description

Add the API:

self.crossOriginEmbedderPolicy;

It reflects the environment's cross-origin-embedder-policy's value.

The possibles values are: unsafe-none, credentialless, and require-corp.

Question for w3ctag

The initial design is to add the API as part of the global object, similarly to the pre-existing crossOriginIsolated:

window.crossOriginIsolated         [pre-existing]
window.crossOriginEmbedderPolicy   [new]

Should we continue adding API one by one here? @mikewest suggested this could potentially be nested behind a new window.policies since COEP is part of the policy container. It might also make sense. WDYT?

Links

Further details:

ArthurSonzogni commented 2 years ago

Gentle ping ;-)

Both Webkit and Mozilla replied adding this API looks reasonable. They don't have a strong opinion about the API location. Would you have some opinion before I proceed with enabling this by default in Chrome?

torgo commented 2 years ago

Hi @ArthurSonzogni we're putting this on the agenda for next week so hope to be back to you by EOD Wednesday.

atanassov commented 2 years ago

@ArthurSonzogni,

We will be able to review this if you can provide an explainer that puts this in a bit more context. Please remember that although we are often reviewing security-related proposals, we do not share all the back story of this proposal and how it fits together with other technologies. What is the user need that is being serviced here? What kinds of threats does this protect the user from? How can the developer employ this technique? Etc...

Lacking use cases we can follow and review, we encourage use of our explainer template in order to capture all the other important bits in a single place - other considerations, code examples, privacy, security and a11y considerations etc. Can you please write one?

Also: in your response to question 2 of the Security and Privacy questionnaire it's a little confusing: do you expose, or do you not expose the info specified?

ArthurSonzogni commented 2 years ago

Thanks @atanassov for your initial look! I updated the explainer to follow more closely the template. See diff.

Also: in your response to question 2 of the Security and Privacy questionnaire it's a little confusing: do you expose, or do you not expose the info specified?

We expose an information that was previously deductible via other means. It is polyfillable.

hadleybeeman commented 2 years ago

Hi @ArthurSonzogni, this is a good start. What's still missing is a discussion of the user need. For example: as a user, I need [] so that I can [], and then how this API accomplishes that.

As far as we can tell, this is telling the site when the security features are turned off. Can you help us to understand the user benefit? And who are the expected users of this feature?

mikewest commented 2 years ago

Hey @hadleybeeman and @atanassov!

This feature (like Window.isSecureContext, Window.crossOriginIsolated, and Document.permissionsPolicy, etc.) aims to provide a pages' author with information about the security properties a given page has opted-into. These properties govern certain subtle aspects of the page's behavior, and potentially impose requirements on resources the page attempts to embed. @ArthurSonzogni's explainer lays out a few of those potential decision points in the "Motivating Use Cases" section.

While I appreciate your laser-focus on the end user, this feature's impact on the users' experience is quite attenuated, as it aims to provide developers with information that helps them construct a page in a reasonable way by understanding the constraints within which they're working. This is particularly relevant for libraries, ads, widgets, etc. that need to function correctly in a wide range of environments, but it's certainly also useful for authors aiming to gradually migrate towards more secure setups, such that they might be responsible both for pages that assert a COEP, and pages that don't.

Does that help?

plinss commented 2 years ago

Our primary concern here is the way that this capability will ultimately be used. We're happy that there is all sorts of work going on to make web pages more secure and preserve more of the user's privacy. 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 and rather than assume less capability, opt-in to older behaviors that may be more abusive to the end user.

Is this really creating a better web or just allowing the "old way" to carry on longer?

ArthurSonzogni commented 2 years ago

Sorry for the delay, I was on vacation. Thanks @mikewest for your post, and @plinss for your reply! I wasn't expecting a push back on this feature. You provided nice question/arguments, let's see if I can provide the right ones in a reply:

opt-in to older behaviors that may be more abusive to the end user.

Could you please let me understand why you believe the default COEP value may be abusive to the end user? I don't believe it is. This is key to the whole question.

We created COEP:require-corp and COEP:credentialless, as dependencies to access more powerful features like SharedArrayBuffer or high resolution timers. The default COEP:unsafe-none is still used by 99.996% of top-level documents. I know 'unsafe' looks like a scary name. It was done purposefully as an incentive for developers to prefer the two other values, if they can. This would be 'unsafe' only in a context where access to SharedArrayBuffer or high resolution timer is granted, we don't do this. So that's fine unconditionally. If we did, the attacker could exploit the Spectre vulnerability with sufficient bandwidth and they might extract non public data without opt-in from weak cross-origin entities.

On the other side, COEP reflection is already polyfillable. If there was a reason not to expose this information, the battle would have been lost already. So not reflecting its own COEP state doesn't help anything.

You might now ask: Why a supported implementation is preferable to a ~polyfill? The polyfill requires sending some fetch() requests and observe the side effects of COEP:

So, at best this is just annoying for legitimate developers, without preventing sufficiently motivated ones from accessing the information.

COEP:reflection is a part of anonymous iframe whose goal is to allow more website to deploy COEP.

Is this somehow convincing?

mikewest commented 2 years ago

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. 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] 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?

plinss commented 2 years ago

We understand that this isn't making anything worse than the status quo, our concern is more about 'is this helping to preserve the status quo'?

To be more explicit, the primary stated use case seems to be for ads to choose their behavior. What would the different behavior be?

e.g. Without this feature, will ads be more likely to assume the COEP restrictions are in place and have a lighter touch (that is presumably better for the end user), where having this feature allows them to detect when they're in an unrestricted context and perpetuate exiting behavior (which may not be as desirable for the end user)?

Also, our concern here is a bit broader than COEP reflection, but also applies to other policies that may be exposed in the future.

ArthurSonzogni commented 2 years ago

For this use case in particular, I will ask them to reply directly here.

My recollection is that for publishers who want to continue monetizing their site and use SharedArrayBuffers, they have no choice other than registering to the reverse origin trial. It was meant to be temporary, we need to close it. If no solution is provided, they will be broken. We identified anonymous iframe as a solution.

For ads, knowing if COEP is enabled allows to know beforehand the