Re: getThisTabMedia

With regards to security and privacy, I think having an API where screen
sharing is limited to only the browsing context of interest is great for
reducing the risk of accidentally sharing the wrong window or tab which can
easily happen when sharing "entire screen" for example.

On Tue, Oct 6, 2020 at 9:25 AM Henrik Boström <hbos@google.com> wrote:

> I think this is a good idea. At first I thought this could be achieved
> with a constraint on getDisplayMedia (by allowing this particular
> constraining on sources), but we may want to add more features in the
> future that can take the fact that this is tab-only into account, so for
> extensibility I think a separate API for this use case could be beneficial.
>
> If we do introduce a tab-only API, it is worth discussing whether the API
> should be "share this tab only" (as proposed) or if we should extend the
> API to be a broader "share a tab" API, where we achieve the "this tab only"
> use case through a constraint.
> I'm thinking about the fact that in Google Meet screen sharing, there is a
> "share a tab" button that achieves this effect, which is not possible to
> achieve with the spec-compliant getDisplayMedia. And if a new API will have
> benefits relating to tab sharing, then perhaps we want to get those
> benefits both in the case of sharing "this tab" and "other tabs". Just a
> thought.
>
> In any case, I support an API like this.
>
> On Mon, Oct 5, 2020 at 10:21 AM Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>> Since we're capturing a top level browsing context (HTML spec never uses
>> the word "tab" except in explanatory text), perhaps
>> GetCurrentBrowsingContextMedia is reasonable?
>>
>> But since HTML spec uses the term "browsing context" for both iframes and
>> tabs, that points out that we need to consider how this new function
>> behaves with nested browsing contexts (aka iframes).
>>
>> My immediate reaction would be to say "no" until we've got a) a need and
>> b) some solid thinking about it.
>>
>>
>> On 10/4/20 12:58 PM, Dan Jenkins wrote:
>>
>> Isn't it just the current tab - there is no selecting done by the user -
>> a better name would likely be getCurrentViewportMedia or something along
>> those lines
>>
>> On Sun, 4 Oct 2020, 02:44 Silvia Pfeiffer, <silviapfeiffer1@gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>