Re: [rtcweb] Let's define the purpose of WebRTC

Roman Shpount <> Tue, 15 November 2011 01:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBF6A21F8F3B for <>; Mon, 14 Nov 2011 17:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.903
X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ArwR7lhGkhb4 for <>; Mon, 14 Nov 2011 17:02:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 119F321F8F31 for <>; Mon, 14 Nov 2011 17:02:25 -0800 (PST)
Received: by ywt34 with SMTP id 34so5525447ywt.31 for <>; Mon, 14 Nov 2011 17:02:24 -0800 (PST)
Received: by with SMTP id q9mr6948483anh.52.1321318944466; Mon, 14 Nov 2011 17:02:24 -0800 (PST)
Received: from ( []) by with ESMTPS id l18sm37784139anb.22.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Nov 2011 17:02:24 -0800 (PST)
Received: by ywt34 with SMTP id 34so5525396ywt.31 for <>; Mon, 14 Nov 2011 17:02:21 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id m2mr53850784pbf.120.1321318940930; Mon, 14 Nov 2011 17:02:20 -0800 (PST)
Received: by with HTTP; Mon, 14 Nov 2011 17:02:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 14 Nov 2011 20:02:20 -0500
Message-ID: <>
From: Roman Shpount <>
To: Matthew Kaufman <>
Content-Type: multipart/alternative; boundary=bcaec5215d371bf4e304b1bb8a46
Cc: "<>" <>
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
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, 15 Nov 2011 01:02:26 -0000

On Mon, Nov 14, 2011 at 7:42 PM, Matthew Kaufman

> 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:

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. 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. 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.

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. 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.
Roman Shpount