- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Dec 2020 15:53:27 +0000
- To: public-webrtc-logs@w3.org
Cropping is a different issue that we happen to be interested in, and only one example of why it's useful for the application to know that it is capturing its own tab. Shelving it for the time being, let's please examine the scenario of a game running in the browser, and wanting to stream itself to a service like Twitch. The streaming service could "publish" an iframe or a script that can be embedded in a game, implementing that functionality. The alternatives I can think of are less preferable. They include: (a) Each game re-implementing the streaming capability, probably by importing the streaming service's code into their own codebase. I don't think that's a reasonable alternative, as the copied code would be running *same-origin*, and would have to be scrutinized before being imported; likely it either won't be scrutinized, or it would be running an older, already-scrutinized revision; also not very secure. (b) Passing frames and audio via postMessage, which would be prohibitively inefficient. Also, since iframes can embed additional iframes, I am not sure that "capture only this iframe" solves the issue of isolating what is captured. I think an opt-out mechanism for being captured by one's embedder would still be necessary. And once such a mechanism is provided (for other readers - I have suggested such a mechanism elsewhere), I think it can be used for making a safe implementation of capture-entire-tab. On Tue, Dec 1, 2020 at 4:21 PM Jan-Ivar Bruaroey <notifications@github.com> wrote: > An iframe only capturing itself would not cover some interesting use > cases. For example, a document being presented to a VC, by embedding an > iframe of the VC's application inside the document-editor application. > > @eladalon1983 <https://github.com/eladalon1983> A security property I > like about *"capture itself"*, is requiring explicit code in the capture > target. Easy to grasp, ensures buy-in of the target, and no-one has to > worry about being captured by other origins (except through the existing > hyper-user-driven getDisplayMedia picker API). > > I was even wondering about enforcing this by checking current global > object == relevant global object, to enforce this: > > await iframe.contentWindow.navigator.mediaDevices.getDocumentMediaWhatever() // SecurityError > > Or a game capturing footage of itself by embedding an iframe which also > contains code and visible controls for managing the capture, annotating it, > and uploading it to a remote server, possibly one which streams it to > remote viewers. > > I don't understand this use of *"itself"*. Can't it put code in the > parent as well, use postMessage etc? We seem to be making much stronger > assumptions about the capture target's involvement elsewhere, e.g. *"Since > the app can take for granted that the captured content is of itself, it > knows how to crop sensibly".* > > I feel strongly we shouldn't be over-capturing, only to create a need for > inventing cropping APIs next. > > I think we can lean on apps to use iframes to capture exactly what they > want to send and no more. This is the web after all, so I'd aim for > stronger integration than the existing modality. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-736621543>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFIX22CZEGFYXSZ6KSJLRC3SSUCYTANCNFSM4SHNXW3A> > . > -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-736641900 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 December 2020 15:53:29 UTC