Our team is always receiving interesting calls from customers and potential customers, who want to know if their web or mobile communications or collaboration application can be implemented using WebRTC technologies.
Sometimes those calls lead to some insights in industry trends (which I’ve documented previously here), and other times they highlight misunderstandings about what capabilities WebRTC gives us.
The following 3 misconceptions have come up in several recent conversations I’ve had. The fact that these are recurring questions doesn’t reflect negatively on the people who called me, but more on those of us in the WebRTC industry and how we message things. Sometimes our excitement about the truly revolutionary aspects of WebRTC based communication lead us to not mention the “fine print” and make WebRTC sound more magical than it actually is.
Without further ado, check out these things that WebRTC cannot do for you.
1) WebRTC is not completely plugin free
WebRTC is still an evolving standard (And as Tsahi recently pointed out, maybe we shouldn’t even care if WebRTC is ever an official standard or not). Often you will hear people say “WebRTC allows for video chat without plugins!”
That’s true, but only in browsers that implement WebRTC. The Chrome, Firefox, and Opera browsers all implement WebRTC on desktops and on iOS devices. In those settings, you do not need a plugin to use the camera and microphone of someone’s device (Although you do still need their permission! The browser will ask users to confirm that your website can use their camera or microphone).
In settings where WebRTC is not implemented natively, then WebRTC will obviously not work without some sort of plugin or additional work. This means the Safari and Internet Explorer browsers mainly. The newer Microsoft Edge browser implements ORTC and will eventually support WebRTC interfaces too.
Also, any iOS implementation requires extra work. On an iOS phone or tablet, WebRTC will not work in the browser (even in the Chrome, Firefox and Opera browsers on those devices, because Apple still requires that those browsers build on top of Apple’s WebKit browser foundation, which currently doesn’t support WebRTC).
Until WebRTC is available in WebKit browsers and iOS (which may happen in the next year if the rumors are true), you have to build a native application in order to hold WebRTC calls on an iOS device. This means using any of the SDK’s developed for WebRTC on iOS, such as OpenTok’s SDKs.
2) WebRTC Screensharing is not possible everywhere
There are three important things to know about sharing your screen in a WebRTC app.
(1) Screen sharing only works in Chrome and Firefox
(2) Even in Chrome and Firefox, screensharing requires that you implement your own browser plugin, which users must install in their browser, before they can share their screen. Screensharing can only be done via the plugin. This is for security reasons, as Amir Zmora details in this post on the New Dialtone blog.
(3) Once you share your screen through a plugin, the feed from your desktop is treated just like any other video stream. You can put it into a video HTML tag just like someone’s camera feed, and it’s a one way display of the screen being shared.
Screensharing is also an exception to the “no plugins” sales pitch about WebRTC apps. For screensharing you always need a browser plugin.
The good thing is that the plugin is only necessary for the person sharing their screen, not those viewing the screen. So if you are doing a webinar tool for example, only the presenter needs to install the browser plugin, not all the people viewing the webinar.
Also, those browser plugins can be installed “inline”, which basically means you prompt the user to install your plug at the moment they need it. There is no need for users to go searching in the Chrome store for your specific plug to install it.
3) WebRTC cannot allow remote control of your desktop
Finally, the most interesting request I’ve had a couple of times recently is “can I control a desktop app on someone else’s computer via WebRTC screensharing?”
The short answer: No.
The longer answer: Nooooooooo.
The less sarcastic and even longer answer: As I mentioned above, once someone is sharing their screen via a browser plugin, the result is a video stream passed over the RTCPeerConnection, just like any other video stream. You could use it to replace the presenter’s video feed, or as an additional video stream shared with all other participants.
Just like your camera’s video feed, the screensharing video feed is one-way. You share a real time video feed of what is shown on your monitor, but there is not a way to interact with the source of that video feed.
We can imagine a couple of use cases where someone might want to control someone else’s desktop.
One scenario is to allow for remote use of desktop applications, rather than port those old desktop applications into a more modern cloud based architecture. The solution to this use case is not WebRTC: it’s finally doing that port of an old desktop app to a modern cloud based web application. Just do it.
The second scenario for allowing remote control of someone’s desktop is because you are a horrible person and are trying to hack their computer. This is probably why WebRTC didn’t implement this into the standard, they are not horrible hackers like you are.
The third scenario is less sarcastic, sorry about that – I guess I’m in a combative mood today. In this final scenario, you probably want to allow someone to remotely control your desktop so they can help you debug a technical problem, or collaborate on document, to control a remote server, or maybe pair-program.
In this scenario, WebRTC doesn’t offer anything for you. You need to use a VPN tool and remote into the computer, try an existing tool like TeamViewer, or build a custom desktop application that people will have to download in order to let you control their desktop.
WebRTC, even with it’s DataChannel, cannot let you control someone’s desktop for the same reason that Javascript commands can’t be used to manipulate anything outside the current browser window. Browsers are designed to operate in a sandbox, where any code on the web page cannot manipulate anything outside the browser window. Otherwise there would be a major security hole in all browsers and any crappy hacker could start using Javascript to search your desktop for credit card numbers. We don’t want that!
WebRTC is not a panacea
Explaining all this fine print took me the better part of 60 lines of text. That’s a pain in the butt to discuss with every potential customer who calls us, but it’s necessary many times to make sure that people understand what WebRTC can do: Help you build amazing communciation and collaboration tools that were not possible in the web just a few years ago.
No, WebRTC is not a cure all for every challenge you face. And no, it’s not really “plugin free” in all situations, no matter what sales copy you read on someone’s website.
Nonetheless, WebRTC does give us the ability to build some pretty innovative and disruptive applications in telehealth, online education, corporate collaboration, social media, broadcast events, and more. I shouldn’t need to sound like a snake-oil salesman in order to convince you of that!
