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

> `Cross-Origin-Embedder-Policy: require-corp; html-capture`

1. I think `html-capture` is more appropriate for element-level capture. We should probably go with `embedder-allowed-viewport-capture`, `viewport-capture`, or something similar. Wdyt?
2. I'm generally OK with this approach, and I believe Chrome Security would be too. (I got a positive signal for both this approach as well as for using a [required document policy](https://wicg.github.io/document-policy/#require-document-policy-http-header).) One potential problem I see with this approach is that AFAICT, this mixes the concepts of requiring a feature and permitting it. IIUC, a document that wishes to consent to `embedder-allowed-viewport-capture` when embedded, but which does not require it when loaded as a top-level document, would need the server to conditionally set the field, and I am not sure this is ideal. Wdyt?

> To clarify, By "site-isolation" do you mean COOP+COEP or just COEP?

I see your point about COOP not being strictly necessary, but Chrome Security believes it would be less confusing to developers if feature requirements fall into one of a small number of buckets, and are not mixed-and-matched on a per-feature basis. I suggest we start out with COOP+COEP and relax later if appropriate, [and I think you suggest the same](https://github.com/w3c/mediacapture-screen-share/issues/155#issuecomment-807273293).

> To clarify what we're talking about, these are resources that set Cross-Origin-Resource-Policy = "cross-origin" but not Access-Control-Allow-Origin, keeping their opaqueness, yet would be captured by this feature.
...
But I'm not 100% sure this isn't a problem. Are there sites out there serving personal info from cookies this way, relying on it being opaque?

The Glitch sample is very useful for people who, like me, are making their first steps with COOP/COEP/etc. I'll be referring others to it. Thank you for setting it up!

I understand how CORP-without-ACAO, meaning the resource is embeddable but not readable, sounds problematic. But IIUC, a malicious document could use Spectre to read any embedded resource anyway, meaning CORP-without-ACAO would not really protect against a malicious document - only make legitimate sites' lives harder. Please correct me if I am wrong, though.

> Continue discussion on blocking loading vs killing capture.

My own opinion is still that killing capture would be preferrable, but Chrome Security has expressed the opinion that, should `embedder-allowed-viewport-capture` be joined by `feature2`, `feature3`, etc., then these different features would all have to separately support unexpected break-off, doing so in a race-condition free way, etc. I understand this consideration. If the consensus (modulo me) is that we should suppress loading, then lets do that.

> Why not Cross-Origin-Embedder-Policy: require-corp; html-capture or just make up a header?

Please forget my earlier reference to **permission**-policy; it's no longer relevant. I am not entirely opposed to `COEP: require-corp; feature1...` But I still see potential value in using **document**-policy instead. I think it would create a clear separation between requiring a feature and permitting it. And we won't have to standardize another header, which is a plus.

> Or :visited for instance.

There is a finite set of user-data mining opportunities presented by either gVM/gDM. I think we should, separately, identify them and come up with proposals for what a user agent SHOULD/MAY do while a capture is active in order to protect the user's privacy. Note, however, that the user might actually be intending to share these, e.g. if receiving support from a trusted relative; IMHO, it would be good to leave the final decision to individual UAs.

> It is unclear whether this API should expose the whole tab or just the context (and children) in which this API is called.

Exposing just the context (and its children) would make the feature equivalent to `element-level capture`, modulo "element" being only frames. Element-level capture comes with some benefits and some drawbacks, and it's often a matter of perspective which is which. For example, it would capture obscured content but would **not** capture obscuring content - either a blessing (avoid capturing app-based menus hanging over a presentation) or a curse (subvert the user's expectations of what is being captured). My position is that this is a **separate**, desirable feature. @jan-ivar, IIUC, you're also now of this opinion?

**Clipping to the dimensions of a given element**, on the other hand, is something Chrome is very much interested in following up on later as issue #158. (Please ignore crop-ID vs. transferability vs. other solutions for the time being.)

Btw, perhaps we should save non-security topics for issue #148 (everything getViewportMedia-related other than security) and issue #158 (cropping/clipping). Wdyt?

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/155#issuecomment-811953823 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 14:39:46 UTC