RE: Why does screen sharing require a browser extension?

It was proposed in this thread to have a consent box displayed every time an application wants to make screen sharing, where this consent box would force the user to select what will be shared (whole screen, one application, etc …) without possibility to simply accept.

After reading the whole thread, I don’t understand what the Chrome Apps model solves that would not be solved by this proposition. Is it possible to have a summary of the main arguments?

Stephane.

De : Justin Uberti [mailto:juberti@google.com]
Envoyé : mercredi 27 novembre 2013 20:12
À : Roman Shpount
Cc : Martin Thomson; Lorenzo Miniero; cowwoc; Silvia Pfeiffer; public-webrtc@w3.org
Objet : Re: Why does screen sharing require a browser extension?

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<mailto:roman@telurix.com>> wrote:

On Wed, Nov 27, 2013 at 12:59 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On 27 November 2013 09:39, Roman Shpount <roman@telurix.com<mailto: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<http://foo.com> domain only. It also provides an API used for integration of conferencing functionality via api.foo.com<http://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<http://foo.com> domain.
_____________
Roman Shpount