Re: getThisTabMedia

I.e. there's a tradeoff in reducing user choices (=bad) that leads to
sharing less web surfaces overall (=good).

On Fri, Oct 9, 2020 at 7:57 AM Henrik Boström <hbos@google.com> wrote:

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