It isn’t about the technology in use, but rather the development process.
WebRTC is the most secure VoIP solution out there. From here on, we can debate why having a browser access a camera is worse than giving that same capability to Skype or any other software that gets installed. Or we can think about what makes WebRTC better.
The development process
I had my share of planning, developing and maintaining VoIP related code. Everywhere that this is done, there’s a rhythm of how development is conducted:
- You start by implementing the service. You make sure to do everything “in the clear” – it is a lot easier to debug. Hell, people once told me that SIP beats H.323 because you can see the messages in the network without needing to decode them first
- Once you have your service – you launch it
- And then in the next version, you might add security in. As an optional feature of course. And that, only if the hardware guys won’t tell you it can be squeezed into the current processor because it is already overloaded – they didn’t take into account i the first version that in the next they will need to encrypt everything
That’s life in the VoIP world. Security is an afterthought of the service and the experience.
With WebRTC? See if you can run it without encryption on the media. Or try rolling out a service on HTTP instead of HTTPS (the product manager or the CEO will be down on your case the moment they understand that Chrome is asking for camera access each and every time – something that can be “fixed” just by shifting from HTTP to HTTPS).
With WebRTC? Security isn’t just ingrained in the implementation, but it is built in a way that pushes developers to take it seriously.
The security threat process
So we found a VoIP security vulnerability in a service or a product. How long will it take us to fix it?
Which PBX version is used in your company? Is it the latest one with all security patches? Was it even upgraded/patched in the past year?
How many versions/upgrades went live this past year for your PBX? None? One?
In May 2013, Google Chrome was in version 27. A year later, and we are at version 35. That’s 8 versions in a year.
If a security vulnerability is found in a browser, it gets fixed and deployed a lot faster than anything else out there.
And for every product, there are security patches that need to be made – no such thing as a product/service that can’t be hacked. The question becomes how fast can you patch it up. With Chrome it is as fast as it gets.
Why is this important?
- There are several posts lately that look closely at WebRTC’s security. This is a good thing. They say nothing bad about WebRTC, and assuming these issues post a real threat – they will get fixed at the speed of Chrome
- We are moving to a fast pacing world. People are already contemplating the security headaches we are going to have with Internet of Things related devices. WebRTC provides a great paradigm to how security needs to be handled from a process perspective
- Government surveillance is now out in the open. With the lookout for privacy, WebRTC is positioned well as what should be the protocol of choice for secure communications
- We need to think beyond the code and the technical details – these will get sorted out. Looking at the processes that take place above the software – the processes used by developers, testers, DevOps and IT engineers – this is where threats get mitigated in the long run
This raises a question I’ve had about webrtc:
I am interested in this technology as a way of bringing video conferencing to schools in a way that protects student privacy from 3rd party corporations. However, schools themselves need to be able to supervise students online and investigate misdeeds. Let’s say one student uses webrtc to send hate speech to another– what record would there be of this session and who would have it?
Does the enhanced privacy of webrtc peer to peer connections mean that it’s harder for a school or work IT department to oversee how users are connecting to one another? Is it possible to collect data or metadata from connections?
Thanks,
Ted
Ted,
I’d say you can use WebRTC for such a use case, and you can add the required moderation with access only to whom you want access for it.
You will need to build it on your own, with or without an API platform for it.
For services not provided by the university (Skype or any WebRTC-based services you are not controlling), you won’t have any kind of access or moderation capabilities.
As with other solutions, meta data can be collected, but not much of it.