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: Wed, 27 Nov 2013 13:32:24 -0500
Message-ID: <52963AB8.10602@bbs.darktech.org>
To: Martin Thomson <martin.thomson@gmail.com>, Roman Shpount <roman@telurix.com>
CC: Justin Uberti <juberti@google.com>, Lorenzo Miniero <lorenzo@meetecho.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 27/11/2013 12:59 PM, Martin Thomson wrote:
> On 27 November 2013 09:39, Roman Shpount <roman@telurix.com> wrote:
>> So, all we need is one web site that distributes this extension and allows
>> cross site scripting (by using JSONP for instance) and this entire security
>> model is out of the window. To be honest, I do not see how installing
>> extension is any better then having an option in the browser menu that
>> enables screen sharing access.
> That site would have to allow other sites to access the data.  We're
> talking about making MediaStreamTracks transferrable between contexts
> using postMessage, which would absolutely allow this restriction to be
> bypassed.
>
> The same way that you could get a permanent grant for gUM on audio and
> video and then hand it out willy-nilly to others.
>
> That sort of behaviour is exactly the sort of behaviour that Justin
> talks about when he refers to the ability to remotely disable
> extensions.  It's why that feature exists.

I stand by my original assertion that you don't need to use browser 
extensions for blacklisting. There are alternatives:

 1. Blacklisting by extension (developers explicitly submit their app,
    users explicitly install the app)
      * Neutral
          * Ability to blacklist by app.
      * Pro
          * User grants explicit consent for installing the app.
      * Con
         1. Drop in traction: users are unlikely to install plugins.
          * Not portable: Proprietary mechanism that varies by browser
            for both the end-user and developer.
 2. Blacklist by domain or author (developers explicitly submit their
    domain name and author certificate, instead of the app itself)
      * Neutral
          * Ability to blacklist by domain name or author.
      * Pro
          * Portable for end-users: only developers would need to deal
            with the different kinds of app stores.
          * Increased traction: regardless of which browser you are
            using, you would use the website directly without installing
            any plugins.
      * Con
          * Lacks explicit user consent for installing (although they
            still consent per use)

I agree that blacklisting by domain/author is a weaker mechanism than 
blacklisting by extension, simply because the underlying app can change 
over time, but I believe that the cost/benefit of extensions is wrong.

This is in line with "ask for forgiveness not permission". Blacklisting 
by extension yields a big stick, seemingly assuming that most app 
submissions will be malicious. Blacklisting by author/domain assumes the 
opposite, but still provides us with a mechanism for banning apps. 
Google bots already have the ability to scan websites for malicious 
content. You can simply extend them to ban domain/authors the second 
malicious apps are detected on their domain. This is nothing new.

Gili
Received on Wednesday, 27 November 2013 18:33:40 UTC

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