Re: [rtcweb] Preserving stream isolation when traversing the network
Randell Jesup <randell-ietf@jesup.org> Sat, 08 March 2014 01:44 UTC
Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5771A0332 for <rtcweb@ietfa.amsl.com>; Fri, 7 Mar 2014 17:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lYlYCLpCJ49 for <rtcweb@ietfa.amsl.com>; Fri, 7 Mar 2014 17:44:09 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 94CA41A0328 for <rtcweb@ietf.org>; Fri, 7 Mar 2014 17:44:09 -0800 (PST)
Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4549 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1WM6J2-0004e0-Kk for rtcweb@ietf.org; Fri, 07 Mar 2014 19:44:04 -0600
Message-ID: <531A7588.2010703@jesup.org>
Date: Fri, 07 Mar 2014 20:42:32 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABkgnnVZpOJU=2ip88jF=sa2a7K=jBhZA0zkovPo_vvTBwA-GQ@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A4844FABBEDF@TK5EX14MBXC296.redmond.corp.microsoft.com> <CABkgnnUrCcDS4Ty+t2gAzXUXyZPuQeqK6nqG5b-egrBwYHr9BA@mail.gmail.com> <DB348EDA-A588-47B2-8FA5-988026831DAB@phonefromhere.com> <CABkgnnXPtT-xMZY1AvkL1eeR5e2kXh0UFBbvZO+pMWXBNseqmg@mail.gmail.com> <5319A60F.4080803@alvestrand.no> <CABkgnnVzMyTLChQjteXKtszWeV3H8-z7S1AW9nrkL3EvMQybgw@mail.gmail.com> <5319AA78.4010808@alvestrand.no>
In-Reply-To: <5319AA78.4010808@alvestrand.no>
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 - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/132OK2O3-PWupicfb5KTRX9-Vr0
Subject: Re: [rtcweb] Preserving stream isolation when traversing the network
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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 <harald@alvestrand.no> 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
- Re: [rtcweb] Preserving stream isolation when tra… Martin Thomson
- [rtcweb] Preserving stream isolation when travers… Martin Thomson
- Re: [rtcweb] Preserving stream isolation when tra… Jim Barnett
- Re: [rtcweb] Preserving stream isolation when tra… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Preserving stream isolation when tra… Martin Thomson
- Re: [rtcweb] Preserving stream isolation when tra… Martin Thomson
- Re: [rtcweb] Preserving stream isolation when tra… Tim Panton
- Re: [rtcweb] Preserving stream isolation when tra… Tim Panton
- Re: [rtcweb] Preserving stream isolation when tra… Martin Thomson
- Re: [rtcweb] Preserving stream isolation when tra… Martin Thomson
- Re: [rtcweb] Preserving stream isolation when tra… Jim Spring
- Re: [rtcweb] Preserving stream isolation when tra… Harald Alvestrand
- Re: [rtcweb] Preserving stream isolation when tra… Martin Thomson
- Re: [rtcweb] Preserving stream isolation when tra… Harald Alvestrand
- Re: [rtcweb] Preserving stream isolation when tra… Randell Jesup