Re: [rtcweb] Notes on security for browser-based screen/application sharing

[Randell Jesup <[e-mail]>]

On 3/22/2013 1:10 PM, Martin Thomson wrote:
> The modern web reality is that any one page consists of content from
> many different sources, so restricting to one source is impractical.
> From an implementation perspective, it might be possible to restrict
> to untainted content (the content that the page origin can access),
> but that would probably result in something that is virtually useless.
>   Just like that interesting (redacted) document that contains
> (redacted).

Correct, and likely be be highly annoying and highly confusing to users.

It really does come down to a trust (or trust and verify) model.  Do you 
trust the JS application?  Can you verify the JS application is the one 
you think it is?  Is there any way to whitelist or blacklist 
applications (from the browser maker or by the user)?   If you're going 
to install/trust/whatever an app, is there an equivalent to 
virus/spyware scanning?

You might be able to (in screen/app sharing) lock out the ability to 
redirect the MediaStream to anywhere but a specific PeerConnection, and 
have chrome that tells you "this is being shared with a connection to 
<identity>" using the identity stuff already proposed, and in other ways 
leverage the "secure call" stuff ekr proposed in Boston.  However, 
there's the converse side at reception - you have to protect it there as 
well - no grabbing a copy from a <video> element, no looping it out to 
another peerconnection (without user consent), no recording (without 
user consent), no other way to access the content of the decoded stream.

Armoring a screenshare against leaks to the application will be tough, 
but it might (just) be possible.  Layering both mechanisms (trust and 
armoring) might be better than relying on just one.

I wonder if mechanisms like out-of-band passcodes (similar to what 
Remote Assistance uses IIRC) that one or both users must enter into the 
chrome might help.

Ah, such easy problems....

-- 
Randell Jesup
[e-mail]