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

[Matthew Kaufman <[e-mail]>]

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