It’s security.
As I prepare for another workshop that I am giving next week about WebRTC screen sharing, I decided to refresh another set of my slides – something I do for every workshop.
This time, I took a look at the ones I present on the permissions mechanism built into WebRTC in Chrome. It now looks something like this:
- Local files can’t access anything – that’s so you won’t get bit by viruses and scams sent over email as files
- HTTP requires permission each time to access the camera and the microphone
- HTTPS requires permission only once – the difference between the two may be security, but it also relates to Google’s current foray at HTTPS Everywhere
- And screencasting? That is only enabled through a Chrome extension
Why that Chrome extension for screencasting?
Because giving access to the screen is far more dangerous than letting someone see you pick your nose. And it doesn’t light green on your webcam when it does either. Oh – and that same code that enabled screen casting? It also controls what’s on that screen since it is running in the browser.
If you want the gory details, then check out this research paper from Carnegie Mellon University (pdf). The title? All Your Screens are Belong to Us:
Attacks Exploiting the HTML5 Screen Sharing API
How does an extension helps us then? By forcing these to live inside Chrome extensions, Google are becoming the gatekeeper. Extensions for Chrome can only be delivered through the Chrome Web Store. This allows Google to maintain some form of governance, along with the ability to throw away extensions that are considered malware if they see fit. It might not catch everything before it gets into the store, but once found – it gets eradicated.
WebRTC offers security when screencasting
Consider this another layer of security that WebRTC offers, along with the fact that the code of the extension itself is wide open.
Now ask yourselves – would you prefer downloading and running a collaboration service that has access to anything and everything on your machine at all times coming from a no-name startup (or a company with questionable origins) – or would you rather just use something with far less exposure and the same functionality? One that will even get disabled if it doesn’t play by the rules.
And people still argue with me when I say that WebRTC is the most secure VoIP technology.
The talky screensharing extension (and it’s MIT-licensed cousin https://github.com/HenrikJoreteg/getScreenMedia/tree/master/extension-sample) is just 50 lines of javascript (and ten of those shouldn’t be there even) so it is very easy to review that they don’t do anything evil.
Thanks tsahi for this good post. It touches one of the subject I think is underestimated by many and that I keep mentioning in my talks about Desktop browser’s webRTC plugins: Security.
I think there are a few things that could be added though to touch on this.
1. Chrome’way (extension) has been seen by many as an overkill. First because it requires to install something (however smooth this installation can be made), second because each single website that want to enable webrtc screensharing needs to have it’s own extension, which only differ in the origin URL the extension allows. This swamp the extension store, and the browsers with multiples extensions that basically do the same thing.
For the technically oriented, all streams are handled by a stream broker in chrome, and getusermedia is just a Media Stream Request manager. The extension just enables requests of a certain type to be processed and to return a stream id. That’s it. Tab capture is possible in chrome, but not through that mechanism ( it is possible through the videoCapture API which is used by other components, but does not inherit the DesktopCapturer class from libwebRTC which would make it webRTC compliant, yet).
2. Interestingly, when implementing screensharing in FF33 this month, the firefox team took another approach. Just like they do for plugins, they are prompting for authorization of some origins, and keep them in a user-approved whitelist. It allows to have pre filled sites (mozilla.github.io) without getting to much pushback, while having hangout using screensharing in chrome without the need of extension is perceived as unfair by some. It allows for the one extra security step beyond normal getusermedia, while not needing any additional installation. (see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1049087). I think this alternative should be mentioned in your documents.
3. As we are preparing for the screensharing extension of webRTC 1.0 to be discussed at w3c TPAC end of october, we are also implementing screensharing in the temasys plugin, with of course the same level of security, and test against both firefox and chrome. The good news here is that a screensharing spec should be available very soon given all the feedback. How it should be made available to users is still being discussed, and it is not sure that the extension way is the way that is going to be in the spec eventually.
One can watch this github repository for pre-working draft document modifications (https://github.com/fluffy/w3c-screen-share). The umbrella/meta bug for in-progress screensharing implementation in firefox is here: (https://bugzilla.mozilla.org/show_bug.cgi?id=923225)
> the firefox team took another approach
That is a temporary measure. Similar to the chrome://flags approach, but less insecure.