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
- Re: [rtcweb] Data transfer Iñaki Baz Castillo
- Re: [rtcweb] Data transfer Magnus Westerlund
- Re: [rtcweb] Data transfer Magnus Westerlund
- [rtcweb] Data transfer Olle E. Johansson
- Re: [rtcweb] Data transfer Saúl Ibarra Corretgé
- Re: [rtcweb] Data transfer Iñaki Baz Castillo
- Re: [rtcweb] Data transfer Magnus Westerlund
- Re: [rtcweb] Data transfer Iñaki Baz Castillo
- Re: [rtcweb] Data transfer Magnus Westerlund
- Re: [rtcweb] Data transfer Randell Jesup
- Re: [rtcweb] Data transfer Timothy B. Terriberry
- Re: [rtcweb] Data transfer Hadriel Kaplan
- Re: [rtcweb] Data transfer Harald Alvestrand
- Re: [rtcweb] Data transfer Randell Jesup
- Re: [rtcweb] Data transfer Randell Jesup