Why WebRTC Screen Sharing Requires More Than User Consent

Web based screen capture comes along with security risks

Performing screen sharing requires the capability of screen capture. When screen sharing is done within an installed application (e.g. video conferencing client) it is assumed that the user trusts the application and thus has the required privileges to perform screen capture. When screen sharing is performed in the scope of a website security considerations are different and require more attention.

The WebRTC standard is addressing this issue and implementations in the browsers differ,

On March 30^th, the WebRTCStandards.info team had a  live Q&A session on this topic. Recording and slides are available.

This post gives some heads up for the session.

Collaboration vs. screen sharing

Presentation and document sharing are common in webinars and video conferencing systems; it is made possible through screen capture and screen sharing features. There is a fundamental difference between screen sharing and collaboration. The best example for collaboration is collective work of a few people on a Google document when each person sees edits being made by the other user as they happen, in real-time.

Screen sharing is different as there is one user who is sharing the content and other users view it but can’t modify it.

In collaboration all users participating in the collaborative work are sharing between themselves the document. There can be one user who is the owner and others who have view/edit rights but there are 2 important security limitations inherit in collaboration:

• Users see only the specific document being worked on
• Since users are collaborating on a document it is assumed they all have access rights (view/edit) to this specific document, they all have rights to view any confidential information included in the document

There are other use cases where user gives control over his computer to another user. These are typically limited to the scope of the enterprise (e.g. IT support) or as part of a service provided by a company to its users.

In both cases, it is expected that the enterprise monitors actions of it’s employees as it may be held liable for any misuse of this powerful capability by one of it’s employees.

The different modes of screen sharing

Screen sharing can be permissive and include the whole screen, an application or just one screen of an application. The more permissive it is, the higher the security risks are.

Security threats in WebRTC screen sharing

Generally speaking, users expect the browser to protect them from security threats of websites they visit and that each website will be isolated, similar to the sandbox concept.

To achieve this, browsers implement the Same Origin Policy (SOP), which in essence means that HTML and Scripts of site A can’t have access to other sites’ content. Browsers allow for mash-ups and fetching of content from other websites. Examples:

• Site A fetching a script from site B and running it
• An iframe in site A runs HTML or Scripts from site B
• Display content from other sites (e.g. images, videos)

What’s common to all of these examples is that site A may display content from other sites or run in an isolated frame code from site B but sites A and B can’t access or alter content of the other site.

When screen sharing is implemented inside the browser and the browser or computer screen are shared, site A may cause the browser to open a new tab and access site B, for example, gmail. Assuming login will be automatic on user’s personal computer, site A will now be able to capture the image of the user’s email inbox. The content of site B needs to be presented for a very short period of time; just enough for the code of site A performing the screen capture to capture the image of site B.

Other simpler risks are common even in cases where a user presents his screen in a meeting room or conference.

An IM message he didn’t want others to see pops us, a notification or a document with confidential information mistakenly presented.

All these apply for screen sharing.

Given the risks associated with screen capture and screen sharing in web environments there was a decision to have more strict requirements for WebRTC screen sharing compared to the simple consent required for mic and camera getUserMedia.

In our Q&A on March 30^th we will further review this topic and the different implementation requirements for Chrome and FireFox.

Register for free

As an appetizer I’ll just mention that Chrome requires installing an extension while FireFox requires a website to be listed on a white list in order to perform WebRTC screen capture and screen sharing.