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

Harald Alvestrand <harald@alvestrand.no> Fri, 07 March 2014 10:57 UTC

Return-Path: <harald@alvestrand.no>
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 CE7391A01FA for <rtcweb@ietfa.amsl.com>; Fri, 7 Mar 2014 02:57:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 2-1aTUE1m9v4 for <rtcweb@ietfa.amsl.com>; Fri, 7 Mar 2014 02:57:25 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 29AAD1A0170 for <rtcweb@ietf.org>; Fri, 7 Mar 2014 02:57:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9D0657C3218 for <rtcweb@ietf.org>; Fri, 7 Mar 2014 11:57:20 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRpEHrG+0Cr2 for <rtcweb@ietf.org>; Fri, 7 Mar 2014 11:57:19 +0100 (CET)
Received: from [IPv6:2001:67c:370:176:dc71:4cbb:f962:3326] (unknown [IPv6:2001:67c:370:176:dc71:4cbb:f962:3326]) by mork.alvestrand.no (Postfix) with ESMTPSA id B35527C3216 for <rtcweb@ietf.org>; Fri, 7 Mar 2014 11:57:19 +0100 (CET)
Message-ID: <5319A60F.4080803@alvestrand.no>
Date: Fri, 07 Mar 2014 11:57:19 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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>
In-Reply-To: <CABkgnnXPtT-xMZY1AvkL1eeR5e2kXh0UFBbvZO+pMWXBNseqmg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zyDxdHP21Z1GNSfgxehsEmB98Mk
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: Fri, 07 Mar 2014 10:57:30 -0000

On 03/07/2014 11:23 AM, Martin Thomson wrote:
> I agree with the conclusion, however:
>
> On 7 March 2014 10:19, Tim Panton <tim@phonefromhere.com> wrote:
>> Many of the use cases I see use these APIs to do things like add titlebars, mix audio streams play audio prompts etc,
> The stuff you cite can be achieved without having to of webgl or
> webaudio.  But I agree with the principle: there are cases where
> isolation is inconvenient.

I'd put this a bit more strongly:

Every single non-trivial application that uses WebRTC today is going to
fail if isolation is turned on by default.

Some of the things that will fail:

- Content-sensitive video overlays ("funny hats")
- Color enhancements that attempt to "fix" videos that are "too dark" /
"too light" and so on
- Bluescreening / background replacement
- Volume measurement via WebAudio
- "Voice effects" (also applied via WebAudio)
- Retransmission ("mesh conferencing")
- Any type of recording

All of these are being done by Javascript if they are done at all today.

If data channels are included in the isolate-by-default zone too, of
course every application that uses data channels will fail too - at the
moment there is *nothing* you can do with a data channel that doesn't
expose the data to the Javascript.

I don't think we've thought through the threat model here (well, Martin
may have, but I don't think we have a joint understanding of it), or
what the things are that we won't be able to do without inevitably
exposing our streams to the kinds of manipulation described here.

The threat model I heard at the meeting was that the sender wants a
guarantee from the receiver's browser that it will keep the streams
confidential against Javascript running in the receiver. It gains no
security against compromised receivers, or receivers that participate in
the RTCWEB protocol dialog but aren't Javascript-executing browsers - in
that case, the promise is simply irrelevant.

The promise might  be relevant for some use cases - in particular, the
use case of interactive videoconferencing where the users trust each
other, but not their Javascript, and where they're willing to give up
funny hats, recording and the other things listed above.

I think that's a very specialized use case.

-- 
Surveillance is pervasive. Go Dark.