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

Re: Why does screen sharing require a browser extension?

From: Justin Uberti <juberti@google.com>
Date: Wed, 27 Nov 2013 11:11:56 -0800
Message-ID: <CAOJ7v-0rGqYnVTvKJWpThaw8i1nDADORbwgbDjQ_SHkn1Q-2XA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Lorenzo Miniero <lorenzo@meetecho.com>, cowwoc <cowwoc@bbs.darktech.org>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
As stated before, we have made our choice for how we are going to make this
functionality available to applications.

If you think there are issues with the overall Chrome Apps model, this is
not the appropriate forum; you can discuss any concerns at
https://groups.google.com/a/chromium.org/forum/#!forum/chromium-extensions.


On Wed, Nov 27, 2013 at 10:38 AM, Roman Shpount <roman@telurix.com> wrote:

>
> On Wed, Nov 27, 2013 at 12:59 PM, Martin Thomson <martin.thomson@gmail.com
> > 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 believe a well designed user consent is required for screen sharing.
> Anything else is circumventable.
>
> If JSONP is supported anywhere on the domain that has a screen sharing
> plug-in enabled, an attacker should be able to load an entire JavaScript
> app in the context of that domain. This application can start screen
> capture and send media to the attacker's server. Since extension publisher
> can update the web site at any time and introduce ways to run such
> exploits, web browser manufacturers will need to monitor all the web
> content published on all the sites that are allowed in screen sharing
> plug-ins. Since this screen sharing attack can be used against any web site
> (and unlikely to be used against the plug-in publisher), it is unlikely
> plug-in publisher will have any incentives to monitor their site for such
> attack vectors.
>
> So, unless I am missing something, a Foo conferencing company publishes
> screen sharing plug-in which is authorized for *.foo.com domain only. It
> also provides an API used for integration of conferencing functionality via
> api.foo.com. This API is commonly used to embed conferencing
> functionality within other web sites and is JSONP enabled. This means other
> web sites also get the ability to run screen sharing plugin authorized for
> *.foo.com domain.
> _____________
> Roman Shpount
>
>
>
Received on Wednesday, 27 November 2013 19:12:47 UTC

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