Re: [rtcweb] Data transfer

Randell Jesup <randell-ietf@jesup.org> Wed, 21 September 2011 15:47 UTC

Return-Path: <randell-ietf@jesup.org>
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 1EFA021F8B03 for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 08:47:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
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 GHwaM49wlIN4 for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 08:47:30 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A53BF21F8B01 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 08:47:30 -0700 (PDT)
Received: from [165.123.243.248] (helo=[10.10.8.117]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R6P3f-0003H7-Cn for rtcweb@ietf.org; Wed, 21 Sep 2011 10:49:59 -0500
Message-ID: <4E7A07A8.4040407@jesup.org>
Date: Wed, 21 Sep 2011 08:50:00 -0700
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net>
In-Reply-To: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Data transfer
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: Wed, 21 Sep 2011 15:47:31 -0000

[ Old response that was sitting on my laptop in drafts...  Feel free to 
ignore]

On 9/15/2011 11:32 PM, Olle E. Johansson wrote:
> A comment on the list made me go back and re-read the charter. One 
> thing I had missed is the data transfer part of rtcweb.
>
> "The goal is to enable innovation on
>    top of a set of basic components.  One core component is to enable
>    real-time media like audio and video, a second is to enable data
>    transfer directly between clients."
> Most of the discussions on the list has been about the media. What are 
> the ideas for data transfer? Applications?

See the Use Case document: some obvious ones are games, 
remote-assistance, web conference with screen sharing or whiteboards, 
file transfer while talking, etc.  Unreliable data channels will be 
included, and while there isn't express consensus yet I very much want 
(and think we'll have) reliable data channels, probably based on 
TCP-over-UDP (over DTLS).

> To me, this seems like an interesting feature. If it's a plain data 
> transfer session, a bidirectional session, it's a way to open a 
> session from Javascript to any server, acting as an rtcweb client, 
> which is different from the current sandbox model. I could have missed 
> this discussion, but if not, I think this is an interesting topic to 
> bring up.

It is a way to open channels to another machine, though in response to a 
user request to do so (which is the domain of the security arena 
here).   Note that the audio and video channels are "data" channels as 
well, though perhaps the JS would be kept from direct access to the 
sources, and thus limit them as channels for exporting data from JS.

Note that if we allow webrtc clients to *send* "early" data OR early 
media in response to an OFFER, it is a potential information leak and 
security risk to evaluate.  For example, if the JS app is gathering 
typing data from an information compromise (real case, won't go into 
details), it could feed it out in realtime using "early data" in 
response to an OFFER that's never communicated to the user.  Now, this 
may not be a valid concern since I think there are plenty of other ways 
for an malevolent app to export data once it has it - just trying to 
make sure we've considered the leak and decided it's safe, IF we want to 
support sending early media/data.

-- 
Randell Jesup
randell-ietf@jesup.org