Re: getThisTabMedia

I love the idea.

How do you suggest the application would be able to identify the "tab"
without the user selecting it?
Would it be based on a text filter, e.g. getTabDisplayMedia("Screen
Capture") would then identify the "Screen Capture" tab because of its
naming?
Would it automatically pick the first such available or would it bring up a
picker dialog again if there are several matching ones?

Cheers,
Silvia.


On Sat, Oct 3, 2020 at 12:40 AM Elad Alon <eladalon@google.com> wrote:

> 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
>