Re: getThisTabMedia

I do think we need to explore ways to make screen sharing web surfaces that
include iframe or address bars more secure somehow. At the same time, I
think this is an argument against any screen sharing API - including
getDisplayMedia - and not one specifically against
getCurrentBrowsingContextMedia. And I wonder if it can be dealt with in
parallel for both APIs, rather than as a blocker to sharing the current
tab. If the iframe security concern can be mitigated, then I would imagine
it gets mitigated the same way whether you used getDisplayMedia or
getCurrentBrowsingContextMedia to obtain the tab sharing. In the meantime,
the user flow now has to rely on the web site explaining to the user to
pick their tab. And also in the meantime, we now run at risk of sharing
other web surfaces (other windows, other tabs) because the user picked
"entire window" instead of "just the relevant tab".

You can argue that directing the user towards the same tab is dangerous
because that same tab could launch an iframe attack to include a website
that does not protect itself against inclusion in iframes. And you would be
right. For *malicious websites*. But in this case, "share entire screen" is
not a whole lot better as a mitigation strategy.

You can also argue that having people share their entire screen on a daily
basis using an API that increases the risk of them sharing their entire
screen instead of just a single tab, is the more dangerous option. Because
this can lead to accidental leaks even while using *non-malicious websites*!
Example: someone shares their screen because they're doing a presentation
but they have a banking website open on a different window that they
accidentally focus while sharing their screen. There are no malicious
websites involved, but sensitive information is leaked to every participant.

If you include not just malicious websites in your calculation, but use
cases of non-malicious websites as well, multiplied by popularity and what
people use screen sharing for, I think there may be a net positive in
having a "share current tab" API.

That said, tab sharing needs to be made more secure if possible (regardless
of API).

On Thu, Oct 8, 2020 at 9:03 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 08/10/2020 22:49, Jan-Ivar Bruaroey wrote:
>
> On 10/8/20 3:56 PM, Sergio Garcia Murillo wrote:
>
> On 08/10/2020 21:36, Jan-Ivar Bruaroey wrote:
>
>
>  2. Is the goal performance? E.g. is recording a web conference call using
> canvas.captureStream prohibitive?
>
> canvas.captureStream is not a viable option at all, the idea is to be able
> to capture all the richness of a css+js UI interface, not to have to re
> implement all of it manually (or via webgl).
>
> So the use case is recording a web conference call? This sounds appealing
> until I consider the limitations. The user would have to:
>
>
>
> My use case is not conference recording, but implementing a OBS studio on
> a web page.
>
>
> I already see requests in the thread for rendering in other resolutions,
> which makes me wonder about the approach.
>
>
> In my use case, and extending the captureStream to an Iframe content, I
> could display the iframe/dom element content with a zoom property of 25%
> while still capturing the stream at full resolution.
>
>
> I agree with the IFRAME argument, we should prevent this for capturing
> contents from outside the domain (and isolated streams).
>
> Yes, though again I don't know if it can be done safely. E.g. what would
> happen if I do
>
>     video.src = "foo.mp4"; await wait(5000); video.src =
> "https://vulnerable-site.com/bar.mp4"
> <https://vulnerable-site.com/bar.mp4>?
>
> what about fetch("https://vulnerable-site.com/bar.mp4"
> <https://vulnerable-site.com/bar.mp4>)? I don't understand the issue here.
>
>
> IMHO, I would prefer to extend to the media capture from DOM elements to
> the window or document elements (following the same domain security
> policies, of course).
>
> That's interesting, and might bring in DOM folks that perhaps would be
> able to talk to the security ramifications of exposing DOM rendering in
> this way (fingerprinting, personal data exposure through CSS exploits etc).
>
> That seems wise.
>
> Best regards
>
> Sergio
>
>
>
>