WebRTC may be a great technology, but by giving remote web servers access to cameras and speakers it poses a real security risk.
WebRTC is a great technology. It enables web developers to make use of the camera and microphone of the laptop (or device) and even handle media processing in real time. You can do cool tricks with it: video processing on the server side to deal with face recognition, object detection, etc.
But it brings with it another aspect: it is the Trojan horse of the browser – a spy in every device.
You do get that nice Allow/Deny buttons on Chrome when WebRTC tries to access the camera, but that’s only from one of the recent alpha releases of it. and even then, I think this is the first time that native browser technology gets such strength and allowing server side web applications to spy on its users.
Need convincing?
See this nice video of a demo – it uses the camera to decide how light or dark the room is and adjusts the web page’s background accordingly:
I don’t know about you, but this one got me spooked and thinking about this technology.
The things to think about here:
- Browser developers should take some extra care with this tech. I think I mentioned something about developers and security the other day…
- Application developers should give me a damn good reason to let them access my local camera – especially now when developing video calling apps is becoming a commodity
- It is only time until rogue web apps will start analyzing web cam data through browsers
You raise a super important point and it is something taken very seriously by browser vendors.
If you take a look at Chrome’s implementation of WebRTC, you will notice that the user needs to:
1) Allow / Deny access for a web page needing device access
2) A notification bubble showing the user that this access has started
3) A system tray notification in your OS that clearly shows which pages are currently accessing getUserMedia()
I think that this is a great start, it reduces surprises and provides better awareness than most plugins / flash / native apps have ever provided.
Of course, as we go forward, new ideas to improve this will come up and we expect to iterate quickly.
The implementation of these features is open sourced on chromium.org and we invite all to review the code with us to ensure the safest, most stable implementation of WebRTC our there.
/Serge Lachapelle Product Manager for Chrome’s WebRTC implementation.
Serge,
It is good to see the improvements in security over time – the new Allow/Deny thingy is relatively new in the Chrome releases and it was a nice addition.
This is the first time browsers can natively “spy” on their users, and I am sure we will see websites exploiting it.
What happens when you switch tabs? minimize the browser? Have the camera accessed for hours at a time?
These are questions that are not easy to answer – but I am sure that you and your team will find solutions for them 🙂
Tsahi
You raise a super important point and it is something taken very seriously by browser vendors.
If you take a look at Chrome’s implementation of WebRTC, you will notice that the user needs to:
1) Allow / Deny access for a web page needing device access
2) A notification bubble showing the user that this access has started
3) A system tray notification in your OS that clearly shows which pages are currently accessing getUserMedia()
I think that this is a great start, it reduces surprises and provides better awareness than most plugins / flash / native apps have ever provided.
Of course, as we go forward, new ideas to improve this will come up and we expect to iterate quickly.
The implementation of these features is open sourced on chromium.org and we invite all to review the code with us to ensure the safest, most stable implementation of WebRTC our there.
/Serge Lachapelle Product Manager for Chrome’s WebRTC implementation.