Re: [mediacapture-screen-share] Let pages opt-in to capture. (#155)

To expand a bit on Chrome security position regarding capture opt-in, we see this as a larger problem of APIs that might leak data from cross-origin resources at the page-level. So whatever we come up with, we would really want the mechanism to be reusable for other APIs with similar security impact.

We have determined that requiring crossOriginIsolation is not enough for such APIs, as the threat model for crossOriginIsolated is APIs that might leak data at the agent cluster level, and not the page level (because the threat is a Spectre attack that is mitigated by out-of-process iframes and we don't want to lower this protection). Concretely, this means we need an additional opt-in from cross-origin frame. Note that this rests upon the assumption that COEP ensures that subresources loaded by the cross-origin iframe have either shared their content with the cross-origin iframe through CORS or opted-into being loaded in a potentially dangerous environment by setting CORP cross-origin. Because of this, we can take the opt-in of the cross-origin frame as an opt-in by the subresources without them having to individually opt them in as well. The iframe could after all just send the content of subresources loaded through CORS to other frames in the page through postMessage, and resources with CORP cross-origin have opted into being loaded into a dangerous environment (ie an attacker could load them directly in a crossOriginIsolated environment and do a Spectre attack on them). What's important for us is not leaking the iframe content, which is why we need an opt-in.

We also believe that the enforcement of the opt-in should be blocking load rather than disabling the feature. If we imagine extending this mechanism to other APIs, going with a disabling model means every single feature must implement a way to disable itself in the middle of execution if a cross-origin frames loads that has not opted into the API. This is likely to result in bugs leading to security issues as opposed to blocking the load, which is safe. Not to mention that we have issues with race conditions, as we must prevent execution of an API in one frame in response to a navigation in a cross-origin frame, two events that are asynchronous. That enforcement must be applied to every frame in the page, which essentially means that it needs to be required by the top-level frame in its response headers and will not change over the lifetime of the document (or we run into potential race conditions between frame creation and requesting access to the API).

With this in mind, we see two potential solutions.
1) Extending the COEP header as you propose

We would be a bit more partial to something like:
`Cross-Origin-Embedder-Policy: require-corp; required-apis html-capture x-bikeshed-other-api`
This leaves the possibility of defining a wildcard to allow all APIs we put behind the mechanism.

If we go that route, we should also define a Fetch Metadata request header to inform the server of the COEP required by the parent, like:
`Sec-Fetch-COEP: require-corp; required-apis html-capture`
This way, the server can evaluate whether they want to opt-into the API and answer accordingly.

Our main issue with this solution is that it ends up mixing two concepts in the same COEP header: the policy to apply to the resources a document embed and an opt-in for APIs.

2) Use required DocumentPolicy

Basically, we define an html-capture DocumentPolicy (off by default) and only allow the API to be used if the top-level frame sends a
`Require-Document-Policy: html-capture` header. DocumentPolicy then does the enforcement of the opt-in (ie no frame in the page can load unless it sends a `Document-Policy: html-capture` header, and no need for a Fetch Metadata request header because we will send a `Required-Document-Policy` header with each document request.

The issue with that solution is that the opt into the APIs is now split over two mechanism, crossOriginIsolated and DocumentPolicy.

**Now, do we require just COEP for page capturing, or crossOriginIsolated?**

From a security perspective, for page capture, COEP is sufficient. Since it is scopped to a page, COOP doesn't apply. However, as Elad mentioned, we are concerned about creating very different ways to have access to various APIs. Right now, we have:
- secure context
- crossOriginIsolated
- DocumentPolicy
- PermissionsPolicy
and various combinations of the above. We'd like if we could avoid adding yet another one. In case we are concerned about the additional burden on developers, COEP seems to be a lot harder to deploy compared to COOP.

Finally, crossOriginIsolated is currently exposed to the web, while the COEP status of the page isn't. If we go with extending COEP headers, we probably need to expose it so that developers can query which API they have access to.

@arturjanc and @letitz who have also been looking at this.

-- 
GitHub Notification of comment by camillelamy
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/155#issuecomment-812009563 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 1 April 2021 16:04:36 UTC