W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

Re: Why does screen sharing require a browser extension?

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Mon, 25 Nov 2013 15:09:27 -0500
Message-ID: <5293AE77.1000208@bbs.darktech.org>
To: public-webrtc@w3.org
On 25/11/2013 2:46 PM, Harald Alvestrand wrote:
> From draft-ietf-rtcweb-security-05.txt:
> 4.1.1.  Threats from Screen Sharing
>    In addition to camera and microphone access, there has been demand
>    for screen and/or application sharing functionality. Unfortunately,
>    the security implications of this functionality are much harder for
>    users to intuitively analyze than for camera and microphone access.
>    (See
> http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html
>    for a full analysis.)
>    The most obvious threats are simply those of "oversharing". I.e.,
>    the user may believe they are sharing a window when in fact they are
>    sharing an application, or may forget they are sharing their whole
>    screen, icons, notifications, and all.  This is already an issue with
>    existing screen sharing technologies and is made somewhat worse if a
>    partially trusted site is responsible for asking for the resource to
>    be shared rather than having the user propose it.

should help with oversharing, especially with a pulsing border and a 
tooltip to explain what it means.

>    A less obvious threat involves the impact of screen sharing on the
>    Web security model.  A key part of the Same Origin Policy is that
>    HTML or JS from site A can reference content from site B and cause
>    the browser to load it, but (unless explicitly permitted) cannot see
>    the result.  However, if a web application from a site is screen
>    sharing the browser, then this violates that invariant, with serious
>    security consequences.  For example, an attacker site might request
>    screen sharing and then briefly open up a new Window to the user's
>    bank or Gmail account, using screen sharing to read the resulting
>    displayed content.  A more sophisticated attack would be open up a
>    source view window to a site and use the screen sharing result to
>    view anti cross-site request forgery tokens.

I don't understand how/why screen sharing allows one to violate the Same 
Origin Policy. If I access http://www.google.com/, and it begins 
screen-capturing, and tries opening http://www.bank.com/, won't the act 
of opening http://www.bank.com/ check the Same Origin Policy? Meaning, 
if bank.com doesn't want to allow Cross Origin requests, then google.com 
won't be able to open it nor capture its contents.


>    These threats suggest that screen/application sharing might need a
>    higher level of user consent than access to the camera or microphone.
> I think it would be good to formulate suggestions for changes here in 
> a way that suggest changes to this text, if changes are warranted.
> On 11/25/2013 05:56 PM, cowwoc wrote:
>> Hi,
>> In the WebRTC World conference Justin Uberti mentioned that Chrome 
>> (and Firefox too?) will be moving screen sharing out of Javascript, 
>> requiring developers to publish a browser extension per application 
>> that wishes to screen-share. The logic behind it was that malicious 
>> app could be banned from the app store.
>> One thing I didn't understand (and was not explained) is why screen 
>> sharing is substantially more security-sensitive than webcam sharing? 
>> I get the fact that someone could use screen sharing to snoop on my 
>> banking activity, but how is this any more security sensitive than 
>> knowing what I look like and where I live? If the security dialog is 
>> good enough for webcam sharing, why is it not good enough for screen 
>> sharing?
>> And finally, couldn't you simply require the use of SSL for this 
>> feature and then ban malicious applications based on their 
>> certificate? Requiring the download of an extension is almost like 
>> requiring a browser plugin for WebRTC. I'd like to avoid it if at all 
>> possible.
>> Thanks,
>> Gili
Received on Monday, 25 November 2013 20:10:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:52 UTC