Re: [rtcweb] Please require user consent for data channels

Jonathan Lennox <jonathan@vidyo.com> Mon, 20 July 2015 14:34 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4BE1A891C for <rtcweb@ietfa.amsl.com>; Mon, 20 Jul 2015 07:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDI7sDHXMWbI for <rtcweb@ietfa.amsl.com>; Mon, 20 Jul 2015 07:34:21 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383361A88F2 for <rtcweb@ietf.org>; Mon, 20 Jul 2015 07:34:21 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6KEVMBQ020549; Mon, 20 Jul 2015 10:34:20 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1vndj4aphf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 10:34:20 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 09:34:19 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] Please require user consent for data channels
Thread-Index: AQHQwvidATEJsjYDbE6MWOsdwYypdJ3kwDCA
Date: Mon, 20 Jul 2015 14:34:18 +0000
Message-ID: <A7E395E3-7C4D-4C2E-BC67-7F3619FF30A5@vidyo.com>
References: <CA+65OspMD_PVjk0BXh7t4LtjmFDcDatoeNjFQOO_OVtC-Br+OA@mail.gmail.com> <55A95364.2070806@gmail.com> <CAOJ7v-3t9BQabR2e4EHs4G0Sec4sU9DFC2aiSXXYrat+an+RYg@mail.gmail.com> <55A96DA3.1040907@gmail.com> <CAOJ7v-1ui7349NzK6NZNRHPbnHWZajctk4cDgMKqRZSv47EYdA@mail.gmail.com> <55A9860D.8030903@gmail.com> <CAOJ7v-3LGd32rnpFVW_U0s3+iVaJXsL4vt_YAo=cyp6YyOArdw@mail.gmail.com> <CALiegfmiS18Jux-kCgOhTKKiyGtMertj6xCegpFrox5NOf9EJg@mail.gmail.com> <CABkgnnW0Tmjqz823vKiF84_u6HasBJC7ERMYCO2HL_NPj5saTA@mail.gmail.com> <CALiegfkpbLy1QXxr-RRF0oOpVv1sWsFeab=vvC4iT4DnPtjKQw@mail.gmail.com> <CABkgnnVWcuhX2NjZgx87L+Uo6df6rEBWW73cxbaX3mu_VfHmCA@mail.gmail.com> <CALiegfkQWAn-jMrjhcDPA3rtowOPVk-S8z3c-jvjpNmjtf=3hA@mail.gmail.com> <CABkgnnWERM4oxozNCSvRf1o0Wm-d9Bjw=9B+xh_NJ+h6GfBJ6Q@mail.gmail.com> <7F818FAC-5559-4074-B1FC-EB9516A98FB7@phonefromhere.com> <13F9D9AE-7B6B-40DE-BDD7-DDED28382EAB@phonefromhere.com> <55ACF718.3010000@jive.com> <55ACFEFE.3030108@jive.com> <CAD5OKxuwVcHsij8fDbvcTqhh-Fq=XatHSqkizF_b592Pj2RymA@mail.gmail.com>
In-Reply-To: <CAD5OKxuwVcHsij8fDbvcTqhh-Fq=XatHSqkizF_b592Pj2RymA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.179.79]
Content-Type: multipart/alternative; boundary="_000_A7E395E37C4D4C2EBC677F3619FF30A5vidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_03:2015-07-20,2015-07-19,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200236
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/ab1AWM8i6Y0iy5t2BEznfQed0no>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Please require user consent for data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 20 Jul 2015 14:34:22 -0000

On Jul 20, 2015, at 4:16 PM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:

Just to be completely clear, we are talking about the metric parameter in the route. If I set a lower metric on the route to some destination (or if OS sets a lower metric on the route to some destination), I expect this route to be used. On some operating systems, this can be overwritten by explicitly binding to a particular IP address (interface). This breaks things and is somewhat unexpected to the system administrator. This is also something that only happens in case of ICE. No other browser based protocol would send data over a route with higher metric.

https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension

Apple has announced that their HTTP client implementation will do (something like) this in iOS 9, to solve the “Parking lot WiFi” problem.