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

Matthew Kaufman <matthew.kaufman@skype.net> Thu, 25 August 2011 21:17 UTC

Return-Path: <matthew.kaufman@skype.net>
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 803A421F8B9E for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 14:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 Gn7C7TIrETDr for <rtcweb@ietfa.amsl.com>; Thu, 25 Aug 2011 14:17:33 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6384E21F86BE for <rtcweb@ietf.org>; Thu, 25 Aug 2011 14:17:33 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 5DC2B1712; Thu, 25 Aug 2011 23:18:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=YTj8um/6Ex1SxO pa1xwc+AGc5Hc=; b=Wp4YpQerF5APY+0zq/gRTodWyJm4WLd2wOYuhRj2saXW3c ifv5jO3unmbnDaf8gez8YAOC53c2PL47kVO9RASSfKm0M7yN4Hl6rBa0uu7TvEv6 UCtbik70NLvBACd7KH5MMMdPGPSfSgrL++Ymod0uf0ZxMomG+FMn5r6jn3pQw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=KPukASLe+LHTiPQs/hX15d gdIh1hXwfVyAHB6iicVXq04w2qkiwAYq/v3AO585cVqmVvHv7xDRzyah6eKlz00x 9+RccEUaGzKxYlyuI/y/Swa8HxYcsTZqSEExFLdg7l5cKU8WaJjJUGdVebMzab9I Pwaln4tP0iJMQDueygsPo=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 5B2797F6; Thu, 25 Aug 2011 23:18:46 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 37C7E3507FB8; Thu, 25 Aug 2011 23:18:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYBM8GnJqKTA; Thu, 25 Aug 2011 23:18:45 +0200 (CEST)
Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 7045A3507FA9; Thu, 25 Aug 2011 23:18:44 +0200 (CEST)
Message-ID: <4E56BC1A.8070803@skype.net>
Date: Thu, 25 Aug 2011 14:18:18 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
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> <4E568FA7.9060805@gmail.com> <2E239D6FCD033C4BAF15F386A979BF51064370@sonusinmail02.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51064370@sonusinmail02.sonusnet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 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
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: Thu, 25 Aug 2011 21:17:34 -0000

On 8/25/2011 11:29 AM, Ravindran Parthasarathi wrote:
>
>> On 08/25/2011 10:14 AM, Matthew Kaufman wrote:
>>> On 8/25/2011 5:51 AM, Elwell, John wrote:
>>>> New requirements:
>>>> Fyy1: The browser MUST be able to send in real-time to a third party
>>>> media that are being transmitted to and received from remote
>>>> participants.
>>> This is a bad idea.
>>>
> [Partha] Please provide good idea if you have any.
>

Remove the part of the requirement that a browser be able to send to a 
third party media that is being received from anywhere but the 
microphone and camera.

>>>> Ayy1: The web application MUST be able to ask the browser to
> transmit
>>>> in real-time to a third party media that are being transmitted to
>>> Yes. It should be possible for the browser to send two copies of the
>>> same media to two different places, possibly even with different
>>> encoders.
>>>
>>>>    and received from remote participants
>>> 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 path by which a user's media may be sent, possibly
> without
>>> the same security constraints, without their knowledge. Sure, a B2BUA
>>> can do this as well, but it makes doing the wrong thing easier.
> [Partha] In case your concern is "security consideration", let us work
> for it to solve the security issues. Please specific the list of
> security concerns related to this.

The primary security concern is that it allows for untrusted endpoints 
(browsers) to be trivially manipulated into sending data they receive 
onward. This is worse than manipulating my local browser, because I can 
at least observe the operation of my local browser (how much traffic it 
sends, what connections are brought up, etc.).

>>> The bigger issue is that this essentially allows you to use a browser
>>> as a media relay.
> [Partha] why it is issue?

I already enumerated this in my previous email. For some examples:

1. Browser in a high-upload-bandwidth environment (like a corporation or 
university) will be used to relay media for many other participants who 
do not have sufficient bandwidth, transferring the cost from the service 
provider to users in those environments.

2. Browser in an expensive-upload-bandwidth environment (metered 
billing) may relay media without its knowledge, increasing the bandwidth 
bill.

3. Mobile browser may relay media without its knowledge, decreasing 
battery life, possibly reaching provider bandwidth caps or charges for 
metered bandwidth.



>> Or, ... picture in picture capability.
>>
>>
>>
>>> This will be objected to in corporate (and some education)
>>> environments where there are sound reasons for disallowing user
>>> applications to take advantage of a high-bandwidth connection to
> relay
>>> media for third parties.
> [Partha] It is just a policy mechanism within the particular corporate
> or education environment. Of course, any real-time application will
> undergo the same policy constraints. For example, I know of couple of
> corporate which does not permit Skype audio application to execute
> within the corporate because it consumes lot of bandwidth. IMO, the
> bandwidth consumption should not be stopping factor for adding the
> requirement.

Do you really want certain web browsers banned from the same 
environments because of the same concerns?

Getting ubiquitous deployment will require complying with norms about 
what a browser does and doesn't do. Right now one of the things it 
*doesn't* do is relay media unexpectedly.

> It also may result in unexpected resource
>>> consumption on mobile platforms, where the user is paying in
> bandwidth
>>> charges and battery life to relay media for a third party. And unless
>>> implemented carefully, it can lead to relaying that is very
> unexpected
>>> (a banner ad that doesn't ask for permission to use your camera and
>>> microphone but does relay media for a third party while running).
> [Partha] Same banner ad may send stream from your camera and microphone
> when you are not ask for it as it is malicious script.

Disagree. These will cause your camera and microphone to be accessed, 
which will cause a permission dialog to appear. ALSO, there is no 
financial benefit to causing your own media to be sent when you're not 
on a call (even if it was possible) but a huge financial benefit to use 
nodes with excess bandwidth as relays.

>   I agree that you
> concern is related to security in browser but your concern is not
> related to recording requirement. Please clarify in case I'm missing
> something.

It is related to being able to command a browser to send media *that it 
is receiving* to another place. I have no problem with a call from A to 
B being recording by having A send a copy of its media to C and B send a 
copy of its media to C. But recording should not be accomplished by 
having B send a copy of its media *and what it receives from A* to C.

Matthew Kaufman