[rtcweb] Call Security (was Re: Let's define the purpose of WebRTC)

[Matthew Kaufman <[e-mail]>]

On 11/15/11 9:02 AM, Roman Shpount wrote:
>
> On Mon, Nov 14, 2011 at 7:42 PM, Matthew Kaufman 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Do you want *your* browser to be able to switch to plain RTP for
>     the call you're making from a place with an unsecured wi-fi
>     network (as essentially all are at this point, given the ease of
>     cracking the typical schemes used for wireless security these days) ?
>
>     I don't. Even though I do agree that there might be external
>     reasons why service providers might want the browser to have that
>     ability.
>
>
> I guess you are missing the point on two accounts:

Perhaps. They're unrelated, so I'll answer separately.
>
> First of call, in most of the cases I (as well as possibly most of the 
> people) do not care. If I am sitting on the public WiFi in a coffee 
> shop, I do not care, because there are hundreds of people around who 
> already hear what I am saying.
But they're not able to record what you're saying from a close-up 
microphone. Nor can they record you from a car sitting outside the 
coffee shop. Nor can they record what the far end is saying. Nor can 
they replace what you're saying with alternative audio.

All of which *are* possible when plain RTP is sent over public WiFi.

> Almost all traditional phone conversations provided no privacy (just 
> ask your friendly phone technician which a handset in the basement), 
> and most of people did not care.

Just because phone tapping is relatively easy doesn't mean we shouldn't 
be improving the state of the art here.

> Cell phones are not as private as you would think (I know of examples 
> when entire countries turned the encryption off for a few months) and 
> users did not care. Encryption is good, but not as important as you 
> are making it to be.

To you.

>
> Second, it is an application developers decision if he wants to 
> provide secure communications. If he does not intend to (all 
> conversations are recorded and posted on the web as a voice blog for 
> example), there is no point of forcing this encryption.

Maybe. Even if the conversations are recorded and posted, there might be 
cases where you don't want alternative audio being substituted. (For 
instance.)

> No matter what we do on the browser side, the app will never be 
> secure, if it is not intended to be so. In this case all this 
> encryption is a wasted effort. It is not a web browser or a user 
> decision if communications with a particular app should be secure. 
> User should be able to see that the certain application takes no 
> effort in securing the communications and decide if they would use 
> this application based on this. The simplest and probably best 
> understood model by web users is, if an application is delivered over 
> HTTPS from a known provider, it should be secure. If it is delivered 
> over HTTP, it provides no guarantees over its security and should be 
> used this at your own risk.

You really don't want to ever provide access to your camera and 
microphone to an application delivered over HTTP, because once it is 
delivered over HTTP you don't know that the application hasn't been 
replaced with something that sends your camera and microphone to 
somewhere other than what you had intended. And you *definitely* don't 
want to press the "remember my choice" checkbox for applications 
delivered over HTTP.

In short, I would strongly suggest that applications delivered over HTTP 
*never* be able to access your camera and microphone. (Noting that in 
most cultures, knowing what a user is looking at or typing isn't nearly 
as sensitive as listening in or seeing what the user happens to be 
wearing (or not wearing)).

Matthew Kaufman