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

Re: Why does screen sharing require a browser extension?

From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 25 Nov 2013 15:39:28 -0500
Message-ID: <CABcZeBPJSThgU1f+R3UOkCdjy=RBgkLjQYyNs2oXWKE1Ak02pg@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Mon, Nov 25, 2013 at 3:05 PM, cowwoc <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> 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 Monday, 25 November 2013 20:40:36 UTC

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