- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Jan 2021 22:13:14 +0000
- To: public-webrtc-logs@w3.org
Quoting @jan-ivar from a [related thread](https://github.com/w3c/mediacapture-screen-share/issues/156) > @eladalon1983 Since we ran out of time in the meeting I'm adding some feedback here. I'm going to ignore that we disagree on the security properties of the proposed API for a moment, to see if we can make progress on cropping orthogonally to it: Agreed - this is orthogonal. I will not misconstrue this discussion as implicit agreement over share-this-tab. > > From [slides](https://docs.google.com/presentation/d/1crumgYj4eHkjo04faLktPTg0QoYJhTFoosEBudfJBuw/edit#slide=id.g7954c29f8a_2_14) > > <img alt="" width="250" src="https://user-images.githubusercontent.com/3136226/105072152-84b26000-5a53-11eb-89dc-b2805846624a.png"> > > If I understand correctly, a top-level page from site A is capturing its tab and wants to crop the output to only include a sub-region _inside_ a sub-iframe containing a participating site B, Is that right? And cropping needs to be robust and frame-accurate enough to not accidentally share even a split-frame more, to avoid revealing sensitive info like speaker notes? Sorry, that's not the setup here. Instead of sites A/B I'll use sites L/R for left/right to make it easier to follow. The setup discussed has site L as its top-level (Slides), and it embeds site R (Meet), which is on the right. Site R is an application centered on video conferencing, and contains significant logic to handle them; site L does not have any video-conferencing logic. Both sites are collaborating, so they can postMessage anything that's serializable (e.g. IDs). Site L will communicate to its collaborator (R) that "the div you're looking to share is <crop_id>." Site R will then instruct **the browser** to crop to that crop_id - whatever it might represent. > If so, then this seems problematic on a couple of levels. For one, the iframe may be in a separate process, which might slip up on a frame here and there. And inherently having the party that decides what area should be cropped separate from the source being cropped seems like a dependency that would be hard to manage e.g. requiring different teams to coordinate (no pun intended). Although sites L and R are running in different processes, such coordination is possible for the browser - which is ultimately in charge of stitching together all frames in its compositing stage. It would not have been possible/feasible for anything other than the browser, I tried to argue in the slides (I'll also produce an explainer). > If we don't use explicit coordinates (which I could easily see going out of sync), relying on some agreed-upon `<div>` would also mean adding code to fish out said div from the iframe, and things can go wrong there a well (site B updating the `'id`). Also, site A would not see the `<div>` in site B's page unless they were same orgin. I propose a new type of ID (in [my last slide](https://docs.google.com/presentation/d/1crumgYj4eHkjo04faLktPTg0QoYJhTFoosEBudfJBuw/edit#slide=id.g7954c29f8a_2_44) - the one with the code sample - I called it "crop_id") that will be used explicitly for cropping. This will prevent breakage over current applications if they modify their IDs during runtime. A well-behaved application will not change the crop-ID during runtime; a misbehaved one will only shoot itself in the foot. (Note: I also suggest the IDs be chosen randomly to make them likely-unique.) > A safer approach seems to be to arrange for the participating page on site B to be doing the capture itself. It controls its own layout, and can specify a crop region using its own `<div>` easily. Permissions policy would still ensure that the end user perceives the request as coming from site A, so that shouldn't be a problem. I don't think the case of a single-frame application differs from a multi-frame application wrt to div-based-coordinates in any way other than that multi-frame applications need a crop-ID and single-frame applications can pass the div's DOM node as a parameter. I don't think ID-based referencing of divs is sufficiently more complicated than node-based referencing, and so I think we can go with the more general solution that also supports multi-frame-multi-origin applications. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/158#issuecomment-763175264 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 January 2021 22:13:18 UTC