getThisTabMedia

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

Received on Friday, 2 October 2020 14:38:20 UTC