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

Harald Alvestrand <harald@alvestrand.no> Sun, 19 July 2015 07:21 UTC

Return-Path: <harald@alvestrand.no>
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 CAC431A044D for <rtcweb@ietfa.amsl.com>; Sun, 19 Jul 2015 00:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Pt0EMTGMur9C for <rtcweb@ietfa.amsl.com>; Sun, 19 Jul 2015 00:21:19 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2F1A070E for <rtcweb@ietf.org>; Sun, 19 Jul 2015 00:21:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 888A87C0BD7 for <rtcweb@ietf.org>; Sun, 19 Jul 2015 09:21:18 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S886kUWtwikc for <rtcweb@ietf.org>; Sun, 19 Jul 2015 09:21:17 +0200 (CEST)
Received: from [IPv6:2001:67c:370:176:e190:20fd:9b5e:945d] (unknown [IPv6:2001:67c:370:176:e190:20fd:9b5e:945d]) by mork.alvestrand.no (Postfix) with ESMTPSA id 276227C06F8 for <rtcweb@ietf.org>; Sun, 19 Jul 2015 09:21:17 +0200 (CEST)
Message-ID: <55AB4FEC.7050805@alvestrand.no>
Date: Sun, 19 Jul 2015 09:21:16 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+65OspMD_PVjk0BXh7t4LtjmFDcDatoeNjFQOO_OVtC-Br+OA@mail.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> <CAD5OKxt-DZCGFECv2UYH8g0fD6EAk39cdpWD-CsN_ED6L4hfKg@mail.gmail.com> <CALiegf=zM54gNjgj65VYV5H3tS-iV5Kg0PrBeF7svYRYZ-JLPw@mail.gmail.com> <55AABE28.8070105@jive.com> <913383AAA69FF945B8F946018B75898A47894E34@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A47894E34@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/s-eAkrZvXzDLgSLMeplPKLEqJUk>
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: Sun, 19 Jul 2015 07:21:21 -0000

On 07/19/2015 08:06 AM, Tirumaleswar Reddy (tireddy) wrote:
>> Being multihomed means multiple interfaces with a default route. There's no
>> > "going against the local policy" in this case when sending packets on any
>> > interface.
>> > 
>> > The point is that in this case, all three interfaces can potentially yield different
>> > server-reflexive candidates, which is why they must be gathered separately. As
>> > for relayed candidates, they also need to be gathered separately because some
>> > interfaces may be faster for talking to the TURN server and it is useful to
>> > compare the candidates gathered on all 3 interfaces. Also nothing guarantees
>> > that you're allowed to reach the server server on any interface that has a
>> > default route, so you need to try them all.
> This will change in the future with multiple provisioning domains (PVD) defined in MIF WG, new socket API will be provided to allow applications to learn about each PVD and use them separately, and as discussed in https://tools.ietf.org/html/rfc7556#section-6.3 application may not override hard set selected by the user.
Rule #53 of the IETF: Things will change in the future, including
deployment of just-completed iETF standards, but we don't know when and how.

Solutions we engineer MUST work in the current Internet.

+1 to Simon - the way systems are designed, implemented and deployed
*now*, there may be multiple interfaces with multiple default addresses,
and there's nothing intrinsically illegal, immoral or fattening about an
application accessing them.

(I have personal opinions about the APIs we use to access those
interfaces, only some of which are suitable for repeating in polite
company, but that is a completely different topic.)

-- 
Surveillance is pervasive. Go Dark.