Re: [rtcweb] Preserving stream isolation when traversing the network

Randell Jesup <> Sat, 08 March 2014 01:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC5771A0332 for <>; Fri, 7 Mar 2014 17:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2lYlYCLpCJ49 for <>; Fri, 7 Mar 2014 17:44:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 94CA41A0328 for <>; Fri, 7 Mar 2014 17:44:09 -0800 (PST)
Received: from ([]:4549 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1WM6J2-0004e0-Kk for; Fri, 07 Mar 2014 19:44:04 -0600
Message-ID: <>
Date: Fri, 07 Mar 2014 20:42:32 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Subject: Re: [rtcweb] Preserving stream isolation when traversing the network
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Mar 2014 01:44:12 -0000

On 3/7/2014 6:16 AM, Harald Alvestrand wrote:
> On 03/07/2014 12:04 PM, Martin Thomson wrote:
>> On 7 March 2014 10:57, Harald Alvestrand <> wrote:
>>> I think that's a very specialized use case.
>> While I agree with much of the rest of your argument, casting this as
>> specialized does our future users a disservice, I think.
>> I appreciate that some companies consider their "value-add" to be so
>> compelling that isolation is something they would not consider.  That
>> doesn't mean that everyone will.
> There may be people in both camps. Probably will be.
> I don't think that "companies' value-add" matters in this situation.
> What matters is whether JS access to the media is necessary to achieve
> the applications' purpose.

Right.  The example given by Cullen in previous conversations was that 
if someone is using a service provided by Large Company to have internal 
discussions, they want some assurance that Large Company (serving the JS 
code to them for both ends of the conference) doesn't have access to the 
media streams.

I presented an early look at this issue and the use of origins in the W3 
part of the Feb 2012 IETF/W3 interim in MV.

The more general case is a service that wants to provide people with 
secure calls can use isolated streams (modulo the ability of the 
participants to verify through browser UI that they're being used), or 
conversely the ability to tell the browser not to let the JS application 
(*or* the application at the other side!) access the mediastreams.  
(Note that some uses might break, or (if the app was written knowing the 
user can do this) would disable features. That's fine)

This is solely to protect against the JS.  It does not protect against 
other attacks or the far-end user themselves (who could always have a 
camera/mic pointed at the screen).  Even if you trust the application 
provider, in some cases they may have been hacked, or they may have been 
coerced into spying on you (how *would* that happen....)

The ability to do this is important to some people, for the same sort of 
reasons why someone I worked with building videophones kept a post-it 
note over the camera of the videophone on her desk; she didn't feel safe 
without it.

> We've seen virtual drum kits that you play by waving your hands in front
> of a camera. That application simply can't be made without JS access to
> media; it's inherent in what the function is.
> That's my point - there are many such applications.

Sure.  I don't think anyone is seriously proposing making isolated 
streams the default (or aren't anymore).

Randell Jesup -- rjesup a t mozilla d o t com