W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: What is missing for building "real" services?

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 10 Jan 2014 21:55:42 -0500
Message-ID: <52D0B2AE.9000906@bbs.darktech.org>
To: public-webrtc@w3.org
On 10/01/2014 8:54 PM, Randell Jesup wrote:
> On 1/9/2014 8:03 PM, cowwoc wrote:
>> On 09/01/2014 6:28 PM, Randell Jesup wrote:
>>> On 1/9/2014 12:39 AM, cowwoc wrote:
>>>> Okay, so here is my second attempt at this:
>>>> We should be able to share any part of the display that the 
>>>> application does not control. Meaning, the webapp might allow users 
>>>> to share the contents of Excel so long as it has no control over 
>>>> what gets displayed by Excel. Similarly, it should be allowed to 
>>>> share any browser tab so long as it plays within its own host/origin.
>>>> Assuming that co-browsing is a non-goal for now, is the above 
>>>> (read-only screen sharing) safe from a security point of view?
>>> There are security issues even for read-only sharing.
>>> If the application can control an iframe in the shared tab/window, 
>>> it could flick up images of private data it normally couldn't access 
>>> (even via writing to a canvas) due to cross-origin restrictions. 
>>> Data such as bank accounts, private user pages, etc.
>> As I mentioned in a follow-up post, we would not allow cross-origin 
>> requests. Any application that enables screen sharing would not be 
>> allowed to issue any requests outside of its origin.
> Sorry, that's not the problem - it's not that the webrtc app would 
> send the request, it's that the page being shared would have on it a 
> hidden iframe that would get triggered to flip up the info. That's for 
> tab/browser-window sharing; if the shared window was a native app 
> window, one assumes that wouldn't be the problem - but sharing a 
> browser window/tab is a primary usecase.  If you block that, you can 
> support some usecases relatively safely, but users will be 
> understandably annoyed/pissed/confused.
 1. It's a start (there are use-cases that don't need any more than this).
 2. If one Chrome tab tries to screen-share another Chrome tab, then
    Chrome should ensure that the Origin of that other tab is the same
    as the application doing the sharing. Where this gets tricky is
    Chrome wanting to screen-share Firefox or vice-versa.

I think it is reasonable limitation to prevent one browser from 
screen-sharing another browser (why would you need to?). The only 
problem is: how would you detect whether a native application is (or 
embeds) a browser? :)

Received on Saturday, 11 January 2014 02:56:12 UTC

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