- From: Elad Alon <eladalon@google.com>
- Date: Fri, 2 Oct 2020 16:35:40 +0200
- To: public-webrtc@w3.org
- Message-ID: <CAMO6jDOCOE-=-nU-wr98O-ZEJZ+okyfJmm=yQWKh9Wn26EFB+w@mail.gmail.com>
Hello all, We're proposing an API that would be very similar to navigator.mediaDevices.getDisplayMedia <https://www.w3.org/TR/screen-capture/#dom-mediadevices-getdisplaymedia>, but which only will be able to initiate capturing of the tab from which it is called (rather than provide the much wider selection of share-sources that getDisplayMedia has). In the case of getDisplayMedia, the Screen Capture TR <https://www.w3.org/TR/screen-capture/> says (bold-emphasis mine): > The user agent MUST let the end-user choose which display surface to share *out > of all available choices* every time, and MUST NOT use constraints to > limit that choice. This will be true for getThisTabMedia too, but there, the only “available choice” is the surface from which it is called (specifically, the browser tab). We’ll be sending a PR similar to this one <https://github.com/eladalon1983/mediacapture-screen-share/pull/3> against the Screen Capture TR fairly soon. The *main benefit* of this new API is that a simple accept/reject dialog can be presented to the user, rather than a complex picker (screen/window/tab). *Contrast getDisplayMedia picker in Chrome:* [image: image.png] *Potential dialog-box for getThisTabMedia:* [image: image.png] We think that the security properties of own-tab capture are no worse than the version that goes via the picker. We note that the application will have control over the surface that is being displayed, and that can cause some sharing of information that would otherwise be inaccessible, such as colors on visited links, or content of embedded frames, but we think that the risks are no bigger than for regular sharing, and that the proposed, simple, prompt is good enough to mitigate this concern. Your feedback is hereby solicited. :-) Thanks, Elad Alon
Attachments
- image/png attachment: image.png
- image/png attachment: 02-image.png
Received on Friday, 2 October 2020 14:38:20 UTC