W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

Screen sharing and application control

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 25 Nov 2013 13:41:31 -0800
Message-ID: <CABkgnnWxiDrxAtjabjYqUWx71=4QR5qfF82PDZOBKsXwpfTd5A@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
The main attack vector for screen sharing is devastating and hard to
explain to users.  That makes screen sharing a very dangerous feature
to enable without some degree of protection.

Other than things that are more-or-less obvious to a user, the main
threat that screen sharing poses is one where the site uses its
ability to control what is being displayed to load content that it
shouldn't be able to see.

The browser sandbox currently has protections against this.  Load a
cross domain image into a canvas or img tag and you can't sample its
pixels.  Load a cross domain iframe and you can't interact with it
(except for postMessage, which has other protections inbuilt).

The real problem comes from the combination of sampling and control;
the control of interest being the ability to load or navigate to
content[1].  Providing either capability on its own seems relatively
harmless, but combining them is a problem.

We already have limits on control.  X-Frame-Options [2] (and
Frame-Options) limit the ability of a site to frame-in content.  This
prevents banks and other high-value targets from having their
sensitive content framed in interesting ways.

We also have ways of explicitly loosening constraints on sampling.
CORS [3] provides sites with the ability to allow cross domain access
to content.

*** Proposal

In the spirit of these mechanisms, I'm going to propose that cross
domain content be required to give consent to be sampled in screen
sharing.  This consent can be granted through the use of a specific
Frame-Options tag.  I think that these can be added in <meta
http-equiv=""/> in case of trouble getting to HTTP.  Unless this
consent is granted by the content, only black pixels are rendered to
the screen capture where the cross-domain content is rendered.

Obviously, pages displayed in a completely different browser could be
subject to some forms of indirect display as long as other
applications on the machine are being shared.  I'm going to assume
that that is unavoidable.

In the same way, I considered having a default of allow for content
that wasn't directly controllable by the application. However, that
would allow for a trivial workaround.  www.attacker.com could load up
foo.attacker.com, send it a postMessage and have it load up the victim
iframe.

It is conceivable that this particular problem could be worked around,
but given that it is basically impossible to proscribe inter-frame
communication, it didn't seem like there was any real option.
Basically, I can't see a way to having consent on by default that
isn't also equivalent to having no protection at all.  The only
consent-on-by-default situation is for the same domain; places where
introspection/sampling is already possible.

tl;dr, I think that it is crucial that content is at least given the
option of saying that it doesn't want to be screen captured...even if
the screen sharing UX is sufficiently convoluted that we are pretty
sure that the user knows what they are consenting to (at the
superficial level).

--Martin

[1] Speaking of control, I hope that we never, ever, ever provide a
site with the ability to control keyboard or mouse input.
[2] http://tools.ietf.org/html/rfc7034
[3] http://www.w3.org/TR/cors/
Received on Monday, 25 November 2013 21:42:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC