Re: [rtcweb] Proposed text - remote recording use case

"Olle E. Johansson" <oej@edvina.net> Mon, 12 September 2011 08:37 UTC

Return-Path: <oej@edvina.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 39FF921F85F1 for <rtcweb@ietfa.amsl.com>; Mon, 12 Sep 2011 01:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.337
X-Spam-Level:
X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 OyV7SxzkrnGt for <rtcweb@ietfa.amsl.com>; Mon, 12 Sep 2011 01:37:40 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id A06B821F84D6 for <rtcweb@ietf.org>; Mon, 12 Sep 2011 01:37:40 -0700 (PDT)
Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 36D4D754BCE4; Mon, 12 Sep 2011 08:39:40 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="us-ascii"
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <4E6DC40F.3080504@skype.net>
Date: Mon, 12 Sep 2011 10:39:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A42B0F39-B7CC-4596-96ED-84FD81F449AF@edvina.net>
References: <A444A0F8084434499206E78C106220CA0B04921B16@MCHP058A.global-ad.net> <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <4E6DC40F.3080504@skype.net>
To: Matthew Kaufman <matthew.kaufman@skype.net>
X-Mailer: Apple Mail (2.1244.3)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Proposed text - remote recording use case
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: Mon, 12 Sep 2011 08:37:41 -0000

12 sep 2011 kl. 10:34 skrev Matthew Kaufman:

> On 9/11/11 10:29 PM, Ravindran Parthasarathi wrote:
>> John,
>> 
>> Please let me know whether the updated text works for you:
>> 
>> New requirements:
>> Fyy1: The browser MUST be able to send in real-time to an another
>> browser/session recording server(SRS) that are being transmitted to and
>> received from remote browser.
>> 
>> Ayy1: The web application MUST be able to ask the browser to transmit in
>> real-time to another browser/session recording server(SRS) that are
>> being transmitted to and received from remote browser.
> 
> I still maintain that adding these requirements opens a huge can of security and resource utilization worms.
> 
> I really think these need to be addressed early before we make this one of the mandatory-to-support cases.

Agree. It will be really hard to include this in the rtcweb architecture as a mandatory-to-support case. 

In the cases where "someone else", i.e. not the browser user, wants to control recording, I assume there will always be a media handling server or gateway where recording can happen anyway. Allowing a third-party to initiate duplication of media streams in the browser has huge security impacts.

/O