Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client

"Robert O'Callahan" <robert@ocallahan.org> Fri, 26 August 2011 05:12 UTC

Return-Path: <rocallahan@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABE821F8AA9 for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 22:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3b3pHH5Fk6K for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 22:11:59 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5693F21F8A64 for <rtcweb@ietf.org>; Thu, 25 Aug 2011 22:11:59 -0700 (PDT)
Received: by ywe9 with SMTP id 9so2849959ywe.31 for <rtcweb@ietf.org>; Thu, 25 Aug 2011 22:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RBMum9csxG2M0Mln/TaZZcJp9hou1d49YGCYWorAcJ0=; b=DMrXUz8fziPCF9OB6RMorTRaDQLrNiaYf1XkumKiz5oAt2v081pSbh8fm6eZk18wte zDAbbY6jDqvqVLQyfO+bNdlCUI5/s0WD3v8bCzIjzdkagEoRpKitxkIqrCNdhVQk4p/r y4pbJ3DLe0Ow4Ov1PSHyL5TulJOyJwBm4Vrqw=
MIME-Version: 1.0
Received: by 10.231.41.17 with SMTP id m17mr1372042ibe.29.1314335594304; Thu, 25 Aug 2011 22:13:14 -0700 (PDT)
Sender: rocallahan@gmail.com
Received: by 10.231.169.198 with HTTP; Thu, 25 Aug 2011 22:13:14 -0700 (PDT)
In-Reply-To: <4E56BC71.101@skype.net>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E54AB9B.9090600@jesup.org> <A444A0F8084434499206E78C106220CA0B00FDB534@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31018BF6DF6@MCHP058A.global-ad.net> <4E554BCE.2040403@alum.mit.edu> <4E56399E.2020902@alvestrand.no> <A444A0F8084434499206E78C106220CA0B011C8D3B@MCHP058A.global-ad.net> <4E5682DD.5020204@skype.net> <4E569983.8060409@mozilla.com> <4E56BC71.101@skype.net>
Date: Fri, 26 Aug 2011 17:13:14 +1200
X-Google-Sender-Auth: i8ptUtPB8njq8OFoAtTKaWG5Pz0
Message-ID: <CAOp6jLZf1R2nTCBvpk8j+xjF1NpL=KUdPnxjnxjrxWP6xd6gsw@mail.gmail.com>
From: "Robert O'Callahan" <robert@ocallahan.org>
To: Matthew Kaufman <matthew.kaufman@skype.net>
Content-Type: multipart/alternative; boundary=0015176f085e36d36a04ab619a16
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@ocallahan.org
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, 26 Aug 2011 05:25:02 -0000

On Fri, Aug 26, 2011 at 9:19 AM, Matthew Kaufman
<matthew.kaufman@skype.net>wrote;wrote:

> On 8/25/2011 11:50 AM, Timothy B. Terriberry wrote:
>
>> Matthew Kaufman wrote:
>>
>>> But this is a bad idea. Providing APIs that let a browser send audio
>>> that is being received from the other end to a third party open several
>>> different cans of worms simultaneously. One is that there's now another
>>>
>>
>> The currently proposed MediaStream Processing API (
>> http://hg.mozilla.org/users/**rocallahan_mozilla.com/specs/**
>> raw-file/tip/StreamProcessing/**StreamProcessing.html<http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html>)
>> essentially allows exactly this (including mixing). It doesn't make any
>> distinction about whether the source of a MediaStream is a local camera, a
>> <video> tag, or a remote stream from a PeerConnection object. So if you want
>> to prevent this kind of thing, you need to have an active method of doing
>> so, because by default the API will allow it.
>>
>
> I think you need to seriously consider the security implications here. Any
> media that originates from somewhere other than a local camera that has
> given permission or a local microphone that has given permission needs to be
> marked as not sendable elsewhere.


We could do that on top of the above API, e.g. by having a PeerConnection
examine the stream graph to determine whether a MediaStream comes directly
from a local sensor.

However, such a restriction would prevent many useful applications and does
not solve the security problems that arise from a malicious Web app setting
up a connection between you and the PSTN. If that can happen, you're in all
kinds of trouble whether the app can control the contents of your outgoing
stream or not.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]