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

[Harald Alvestrand <[e-mail]>]

On 03/07/2014 11:23 AM, Martin Thomson wrote:
> I agree with the conclusion, however:
>
> On 7 March 2014 10:19, Tim Panton <[e-mail]> 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.