Re: getThisTabMedia

I think you are missing a significant trick here.

This API surface belongs in the Service Worker. 

The service worker should be able to return a media stream to any of the pages it is serving, which represents
a region of any page it is serving.

The user just has to agree.

The advantage here is that it solves both Dan and Silvia's usecases, and enforces same-origin in a natural way.
What's more the stream can survive user navigation - which your current proposal can't.

T.

> On 2 Oct 2020, at 15:35, 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.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