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: Tue, 26 Nov 2013 03:09:33 -0500
Message-ID: <5294573D.4000603@bbs.darktech.org>
To: Eric Rescorla <ekr@rtfm.com>
CC: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>

You bring up some very good points, but I'm going to respond to Justin's 
post because it contains similar elements with more detail.


On 25/11/2013 3:39 PM, Eric Rescorla wrote:
> On Mon, Nov 25, 2013 at 3:05 PM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>     On 25/11/2013 3:02 PM, Martin Thomson wrote:
>         On 25 November 2013 11:44, cowwoc <cowwoc@bbs.darktech.org
>         <mailto:cowwoc@bbs.darktech.org>> wrote:
>             The only way I can see this happening is for secure
>             websites that do not
>             require user interaction (meaning, you checked
>             "automatically log me in from
>             this computer"). So yes, in such a case I definitely see a
>             security risk but
>             that brings up the question: why not just target the
>             intersection of screen
>             capturing, iframes and cross-site requests? Screen
>             capturing should not be
>             allowed to capture hidden elements, or the contents of
>             cross-site requests.
> Since showing a whole site, one of the components of which is cross-site
> objects is one of the major uses for screen sharing, that's
> going to make it significantly less useful.
>             Moving this into an extension doesn't really solve the
>             problem.
>         That is incorrect.  Confidential information isn't just
>         restricted to
>         stuff that is shown when you are logged in.
>     Please provide an example
> SiteKey.
> More importantly, I don't really understand what you mean by "do not 
> require
> user interaction". I'm currently logged into GMail for instance and 
> opening
> a new GMail link wouldn't require a new user interaction.
> -Ekr
>         And, this presupposes
>         that you don't have concurrent uses of sites where you can be
>         screen
>         sharing in one and in a private/sensitive session in another.
>     As I mentioned in a separate thread, you can make this obvious by
>     flashing the border of the area being captured. This is similar to
>     webcams lighting up when they're on. There is no way a user would
>     miss that visual queue. Take a look at
>     http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html
>                 How exactly were you going to identify an application
>                 as malicious?
>                 After they steal someone's life savings?  Keep in mind
>                 that it's only
>                 the matter of milliseconds to stand up a new site with
>                 a new
>                 certificate.
>             This contradicts Justin's argument as I understood it. He
>             stated that by
>             moving the code from JS into a browser extension Google
>             could ban malicious
>             apps as they are found. I don't see the difference between
>             enforcing bans by
>             way of extensions or by way of having developer asking the
>             app store to
>             approve their application (point to an external address +
>             SSL certificate)
>             and then if the application is found to be malicious
>             simply ban all apps
>             associated with the SSL certificate. This way Google still
>             gets to review
>             apps, ban the ones that are malicious, and users don't
>             need to go through
>             the hassle of installing a plugin.
>         I might disagree with Justin (might) about the level of protection
>         that is afforded the user by the "install" process.  That is true.
>         TLS doesn't help you here.
>     TLS alone would not, but TLS with Chrome App Store would. I'm
>     saying that when a user hits a website that uses screen capturing,
>     Chrome should check whether its TLS certificate has been approved
>     in Chrome App store. If not, it should deny access. This gives you
>     all the power of App Store (approval process, banning, etc)
>     without the user needing to download an explicit plugin.
>     Gili
Received on Tuesday, 26 November 2013 08:10:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC