Re: [rtcweb] Proposed text for local recording use case

Paul Kyzivat <> Tue, 23 August 2011 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6117A21F8B5F for <>; Tue, 23 Aug 2011 07:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_47=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J3Gzgq0rH4vU for <>; Tue, 23 Aug 2011 07:02:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8020821F8B3E for <>; Tue, 23 Aug 2011 07:02:54 -0700 (PDT)
Received: from ([]) by with comcast id Ppxo1h0051ei1Bg57q42H0; Tue, 23 Aug 2011 14:04:02 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id Pq3p1h00X0tdiYw3kq3tT3; Tue, 23 Aug 2011 14:03:54 +0000
Message-ID: <>
Date: Tue, 23 Aug 2011 10:03:42 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Elwell, John" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [rtcweb] Proposed text for local recording use case
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Aug 2011 14:02:55 -0000

On 8/23/11 3:50 AM, Elwell, John wrote:
>> -----Original Message-----
>> From:
>> [] On Behalf Of Paul Kyzivat
>> Sent: 22 August 2011 16:00
>> To:
>> Subject: Re: [rtcweb] Proposed text for local recording use case
>> This is a good start. But I'd like to dig a little deeper into the
>> intent here.
>> The below says the *user* wishes to record, and the *browser* must be
>> able to do it. But is that the only case of interest?
>> ISTM that in a number of cases it will be the web application
>> that wants
>> the recording, even if there is an obligation to inform the
>> user that it
>> is happening. And the behavior of the application may be changed
>> substantially if the recording cannot be made.
>> (Consider a web app provided by a brokerage to its clients.)
>> OTOH, maybe some of these cases are out of scope because the
>> user+browser can't be sufficiently trusted, so that its
>> necessary to do
>> the recording from some secure server.
> [JRE] I think there is a significant difference between local recording and remote recording. If there is a policy, say in a call centre, to record calls, the recording device is most likely going to be central, not local to the user's device. So I think for local recording it is largely up to the user whether to record or not. But yes, it could be that the application at least suggests recording.

I agree there is a significant difference between local and remote 

But in the RTCWEB context there are a number of alternatives for local 
recording. Specifically, how is the decision made to record locally?

- the user could have configured the browser to unconditionally
   record every media stream, without regard to what the JavaScript
   has to say about it. This might be an important policy choice if
   you don't trust what the web sites do

- the JS downloaded from a web server may come with instructions
   to make a local recording.

- the JS downloaded from a web server may contain code that checks
   local policy in the browser and/or queries the user, to decide
   whether to make a local recording

In the latter two of the above the decision to record or not rests with 
the web server. In the first case it does not. The first case also 
requires a different sort of implementation in the browser - it must be 
hooked into the stream processing machinery at a lower level.

I think its necessary to decide whether the first case needs to be 
supported. Its tricky, because recording everything is probably 
excessive, yet I'm not sure I'm ready to trust that all the web servers 
I want to use will do the right thing.

Is there a middle ground?


> John
> John Elwell
> Tel: +44 1908 817801 (office and mobile)
> Email:
> Siemens Enterprise Communications Limited.
> Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
> Registered No: 5903714, England.
> Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.