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

Chrome Security shared the view that a confirmation-only flow would require security measures roughly in line with what you suggest. I'd love to resume this conversation and try to agree on the details.

The way I see it, we have two new requirements - (1) site-isolation and (2) a new header. We think the new header should apply to documents. Site-isolation will allow sub-resources to opt into being captured by their document, and the new header will allow one document to opt into to being captured by another. Embedded documents will also be opting in on behalf of the sub-resources which they embed.

Rationale for applying the header only to documents:
1. The site-isolation requirement suffices to receive some opt-in from resources.
2. Resources are same-process with their embedding document, and therefore cannot reasonably expect to be fully protected from readability by those documents.
3. Resources will typically be embedded from further afield than documents. The onus of COOP/COEP is already great enough. Requiring an additional header might stymie adoption.
4. Headers have a non-zero bandwidth cost.

For the shape of the new header, I think it would be useful to first decide what we expect the behavior to be. I think that it's important that failure of a document to opt-in using the header would not prevent loading the document, but rather, it would (1) break off on-going captures and (2) prevent the initiation of new captures. One rationale for this choice is the expectation that for most applications, flows involving screen-capture are not the primary flows. Especially screen-capture initiated via gCBCM. For example, in Google Slides, editing slide decks, reading decks written by others, commenting on decks, etc., are much more common use cases than sharing using gCBCM. It would be preferrable to keep these flows intact 100% of the time, at the cost of (rarely) breaking off a gCBCM-initiated capture. I expect the majority of other applications will see things similarly.

If we agree on the above (suppress capture instead of prevent loading), then we need a new header that lends itself to such behavior. This rules out [document policies](https://wicg.github.io/document-policy/), at least in their current form, because they prevent loading of non-conforming documents. [Feature-policies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Policy), I think, could be bent to work here. It would require that we use two policies, and that we use the second one creatively, but I think it will work, and will spare us the need to define something new.
1. First, we'll use a feature-policy like [display-capture](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy/display-capture), probably with a new name, to allow embedders to give gCBCM-calling permission to embedded frames. For this feature-policy, we'll only care about it when it's specified on the iframe-tag; it only goes "down" the tree.
2. Second, we'll define a new feature-policy called `capturable-by` or something similar. We'll only care about it when it appears in the HTTP header; it only goes "up" the tree. It will allow a document to opt into being embedded by specific embedders.
3. Finally, we'll define capturability to be transitive. This means that if the top-level document (TL) has two frames F1 and F2, and if F1 has opt-into being captured by TL using `capturable-by`, then F2 can call gCBCM if-and-only-if TL gives F2 permission to do so using `display-capture`. This means TL can give F2 permission on behalf of F1, too. This requires some custom code that maintains a permission tree, with permissions of type 1 going "down" the tree and permissions of type 2 going "up" the tree.

Wdyt?

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


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

Received on Wednesday, 17 March 2021 22:53:51 UTC