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

Re: Screen sharing and application control

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Tue, 26 Nov 2013 02:52:53 -0500
Message-ID: <52945355.9060503@bbs.darktech.org>
To: public-webrtc@w3.org
+1. Good idea.

Another approach which is easier to implement but probably a lot less 
interesting is limiting ourselves to read-only screen sharing. In other 
words, instead of Alice and Bob being able to control each others' 
browsers remotely, a local user would be able to grant a remote user a 
read-only screen share. The remote user could view what is going on, but 
not direct remote actions.

I like your idea a lot better, assuming others are willing to accept it :)


On 25/11/2013 4:41 PM, Martin Thomson wrote:
> 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 Tuesday, 26 November 2013 07:53:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:52 UTC