Re: getThisTabMedia

Unfortunately, this is a bit of a security nightmare, because the risks 
are so poorly understood.

    "Share foo.com with foo.com? Why even ask?"

Most people assume anything displayed by a site can be read by the site, 
but this is not true, because HTML.

Capturing rendered HTML would allow a site to circumvent the same origin 
policy, a core security pillar of the web. A malicious site could 
deep-link vulnerable¹ sites across the web to render them in iframes 
with the end user's session info *for the vulnerable site*, to steal 
their personal information (browsing as them effectively). Cross-origin 
media could also be recorded, which is not normally possible. None of 
this is obvious to an end user.

The reason getDisplayMedia forbids sites from narrowing down the user's 
set of choices for sharing is *specifically* to avoid idly sharing 
web-surfaces that MAY be under the influence of the site making the 
request. This proposal would seem to enable exactly that.

Chrome is violating the spec by not highlighting these risks in 
getDisplayMedia. Firefox warns when choosing web sources.

For more on this see 
https://blog.mozilla.org/webrtc/share-browser-windows-entire-screen-sites-trust/

USE CASES

A site should already have all the information it needs to compose video 
(using captureStream) and (web) audio from anything available to it in 
the standard web security model.

I'd like more clarity on which use cases would require this 
functionality, and what the goals are:

  1. Is the goal specifically to gain access to information outside the 
same origin?

  2. Is the goal performance? E.g. is recording a web conference call 
using canvas.captureStream prohibitive?

If we can crystallize use cases, then there might be value in exploring 
a new API if we can somehow constrict the feature solely to same origin 
content (reject on cross-origin content). I'm not sure that's entirely 
possible though, since DOM is so flexible.

Co-browsing is out of scope 
https://github.com/w3c/mediacapture-screen-share/blob/gh-pages/explainer.md#user-content-non-goals

---
1) Sites can protect themselves against inclusion in iframes, hopefully 
most big sites do, but this becomes a weakest link problem.

.: Jan-Ivar :.

On 10/2/20 10:35 AM, Elad Alon 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.png
> _Potential dialog-box for getThisTabMedia:_
> 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