From nobody Tue Feb 6 23:18:00 2018 Return-Path: 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 6D619126CB6 for ; Tue, 6 Feb 2018 23:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 H4xP3d6lQ_v4 for ; Tue, 6 Feb 2018 23:17:57 -0800 (PST) Received: from smtp105.ord1c.emailsrvr.com (smtp105.ord1c.emailsrvr.com [108.166.43.105]) (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 6A925126CC7 for ; Tue, 6 Feb 2018 23:17:57 -0800 (PST) Received: from smtp14.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 27396C017B; Wed, 7 Feb 2018 02:17:54 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp14.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C3FB4C0177; Wed, 7 Feb 2018 02:17:52 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from syd-vpn-client-247-193.cisco.com ([UNAVAILABLE]. [64.104.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 07 Feb 2018 02:17:54 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Wed, 7 Feb 2018 15:17:49 +0800 Cc: Harald Alvestrand , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <08848AA4-1B73-41E0-B816-DFD940264775@iii.ca> References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com> <76f85272-32dc-5282-bd4f-6adbded028bf@alvestrand.no> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] [dispatch] Identity? (Re: Datachannel Hackathon at IETF 101 ?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 07 Feb 2018 07:17:59 -0000 I did an IdP too and would be interested to help on this.=20 > On Jan 31, 2018, at 4:03 PM, Martin Thomson = wrote: >=20 > (-dispatch) >=20 > I'll be at the hackathon and am willing to assist. I have an identity > provider, but it is garbage. It would be nice to see something a > little more fully thought out. >=20 > On Wed, Jan 31, 2018 at 6:50 PM, Harald Alvestrand = wrote: >> On 01/31/2018 12:37 AM, Nils Ohlmeier wrote: >>=20 >> Yes I would love to test it against the Firefox Identity = implementation. >>=20 >> Were you thinking about adding it to JS code of an open source = bridge/SFU, >> or standing up an identity service, or both? >>=20 >>=20 >> Whatever can be shown to work. The point would be to show by = demonstration >> that it's (relatively) easy to provide and use identity service and = that >> Firefox browsers can use it with different backends / services. >>=20 >> (I don't see any chance to get identity into Chrome by London - if we = can >> build a convincing story in London, the next IETF might be more = hopeful.) >>=20 >>=20 >>=20 >> Best >> Nils >>=20 >> On Jan 30, 2018, at 05:59, Harald Alvestrand = wrote: >>=20 >> Speaking of features that have received little love from deployment = .... >> would anyone be interested in hacking on the identity API? >>=20 >> It seems to have received little love from implementors so far, but >> there's been strong pushback against removing it too. We need either = it >> or something like it to satisfy the security requirements we set out = to >> satisfy. >>=20 >> Harald >>=20 >>=20 >> On 01/24/2018 12:28 PM, T H Panton wrote: >>=20 >> There has been talk over on the w3c list about the scarcity and >> unsuitability of free-standing WebRTC datachannel implementations. >>=20 >> I wonder if this is a suitable target for the IETF 101 hackathon? >>=20 >> The challenge would be to throw up one or 2 free standing datachannel >> implementations based on existing open >> source with APIs that might suit authors of networked games or SFUs. >>=20 >> Comments? Thoughts? >>=20 >> T. >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> -- >> Surveillance is pervasive. Go Dark. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >>=20 >> -- >> Surveillance is pervasive. Go Dark. >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Feb 11 01:00:57 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F835120454; Sun, 11 Feb 2018 01:00:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151833965150.17077.13014329219354900316@ietfa.amsl.com> Date: Sun, 11 Feb 2018 01:00:51 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 11 Feb 2018 09:00:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC IP Address Handling Requirements Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-05.txt Pages : 10 Date : 2018-02-11 Abstract: This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 11 11:24:01 2018 Return-Path: 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 6F931126C22 for ; Sun, 11 Feb 2018 11:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 efKj6nq8vQEm for ; Sun, 11 Feb 2018 11:23:58 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6D91200F1 for ; Sun, 11 Feb 2018 11:23:57 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 47so8249849uau.9 for ; Sun, 11 Feb 2018 11:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rVCWdkc44FGOygqHFhLnc0EWm8n58UCEsi8Eopm3RVg=; b=NQGPVS0u0vRNRE8juvAyjZ9z8Yq2hxV7zup3qJ8VIxk4syLLLKfPaL6RG3Gpap49cN JDVGyGPmpq1XypzgtfWS9sWTE0Jdt/wdqymbyoSweREych/6lyejoOO539Ta/3bP1UJy dhUvot9eia5CTgxe5G7wx/yQUPTyavD0Yj1EzPbjVfYAt5ff4kEObZ69brT7tAysqPhT 7xkPGAyzL4iVsC936dPPz6bNmOXjd+L3AdWnxaWdz5he+/nDAk78AM7Opkdoi5kl21tb JRKUKg8A0URSJ1yRHDloKb0CRukGVsrVLimC7b1bHlk2KzOyQBqFfrIqZ2dt0Cnc7KNE vdbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rVCWdkc44FGOygqHFhLnc0EWm8n58UCEsi8Eopm3RVg=; b=G6ZcwVw7Ttob1/dsdqP5AcUNHUFKtXzTi8XzkaFuKL+EM58/Iw4B74cENUPBePlShe YPYxHDZb2w9gaZ4eli5qBAC9YdaGVhMcDrdN2lZ7LfgTAEEV22AZUXQUxO7FsieQVZWc +9LnB6c2/wynXC8gnZCHplkfmRsNJS2pNabFhx3Wor7/ob0ec4dPpYvHYqoH3eaG6KhM WXeMT5WMpIm4LhyoXpw+CuqHb1bRz+hSV+Ibo0eFFkN2H/dBI+2gm72Zb2mX+Rft9uZt T9qpOj74qhzObE+eKqSc9atWjPHoz/396dwr/ttc72LpuLbKHtbEn9eRtJz/Xh2WfLeQ gvLQ== X-Gm-Message-State: APf1xPDZDaKAcGoUWosUMRHB5jG6Z3GH6t9EUygjRPOtGKCKzRJ/ES18 /3G7KMndj1YSwHUZiVf3pXvrZF7hn6wcuILBa6XBiQ== X-Google-Smtp-Source: AH8x225/rFbx2kRz2H7vg3Zdll/ZTb23707U5lZHTptFUDOt4DvjXaQafqb0bs1YfOmoiLM1AiAzK8eJ72EULIY8Kco= X-Received: by 10.176.18.99 with SMTP id s35mr9343884uac.62.1518377033257; Sun, 11 Feb 2018 11:23:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.161.142 with HTTP; Sun, 11 Feb 2018 11:23:32 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Sun, 11 Feb 2018 11:23:32 -0800 Message-ID: To: Martin Thomson Cc: "rtcweb@ietf.org" , Bernard Aboba Content-Type: multipart/alternative; boundary="f403045ed840b4523a0564f4b321" Archived-At: Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 11 Feb 2018 19:24:00 -0000 --f403045ed840b4523a0564f4b321 Content-Type: text/plain; charset="UTF-8" OK, I updated the doc as discussed in this thread. PTAL at https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 and see if the changes look reasonable. On Thu, Dec 14, 2017 at 1:32 PM, Martin Thomson wrote: > Since I was asked... > > 1. I think that this might benefit from a mention of the case. You > are taking the effort to address the VPN case, but if someone has a > public address, this might be a surprise. > > 2. No specific text necessary here I think. Forcing a proxy should do > for this case. It's true that Tor browser doesn't necessarily disable > JS and WebRTC, but the forced proxy mode is a reasonable strategy for > that case. > > 3. I agree with you. > > On Thu, Jul 20, 2017 at 1:45 AM, Justin Uberti wrote: > > Since there will be no WG meeting this week, here are the open issues for > > the document. Feedback on these issues is the only thing standing between > > this document and WGLC. > > > > 1. https://github.com/juberti/draughts/issues/59 > > > > In the problem statement, should the paragraph on VPNs mention IP address > > discovery? > > > > Currently, the problem statement says the following: > > > > 1. If the client is behind a Network Address Translator (NAT), the > > > > client's private IP addresses, typically [RFC1918] addresses, can > > > > be learned. > > > > 2. If the client tries to hide its physical location through a > > > > Virtual Private Network (VPN), and the VPN and local OS support > > > > routing over multiple interfaces (i.e., a "split-tunnel" VPN), > > > > WebRTC will discover the public address for the VPN as well as > > > > the ISP public address that the VPN runs over. > > > > However, Bernard mentioned that even without split-tunnel support, the > ICE > > implementation allows discovery of the VPN private address. I think this > is > > covered by the first paragraph, but perhaps this should be spelled out > > further. Thoughts? > > > > 2. https://github.com/juberti/draughts/issues/60. > > > > Should supporting WebRTC over Tor be an explicit goal of this document > (and > > mentioned in the goals section)? > > > > This scenario is possible via Mode 4, e.g. force-proxy mode, but it may > be > > out of scope for this document. Bernard mentioned that it may be out of > > scope as Tor distros can disable Javascript, making WebRTC useless, but > upon > > investigation I found that the default Tor bundle does enable Javascript, > > and so this is worth considering. Thoughts? > > > > 3. https://github.com/juberti/draughts/issues/61 > > > > Should the document discuss implementation details as it relates to > > suggested default behavior? > > > > The document currently says the following: > > > > 1. By default, WebRTC should follow normal IP routing rules, to the > > > > extent that this is easy to determine (i.e., not considering > > > > proxies). This can be accomplished by binding local sockets to > > > > the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which > > > > allows the OS to route WebRTC traffic the same way as it would > > > > HTTP traffic, and allows only the 'typical' public addresses to > > > > be discovered. > > > > However, Bernard thinks that this text may be making some assumptions, > > specifically about whether a strong or weak host model is used. My > thinking > > was that spelling out the general implementation approach helps readers > grok > > exactly what this section is getting at, but open to other opinions here. > > > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > --f403045ed840b4523a0564f4b321 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I updated the doc as discussed in this thread. PTAL at= =C2=A0https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 and se= e if the changes look reasonable.

On Thu, Dec 14, 2017 at 1:32 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Since I was asked...

1. I think that this might benefit from a mention of the case.=C2=A0 You are taking the effort to address the VPN case, but if someone has a
public address, this might be a surprise.

2. No specific text necessary here I think.=C2=A0 Forcing a proxy should do=
for this case.=C2=A0 It's true that Tor browser doesn't necessarily= disable
JS and WebRTC, but the forced proxy mode is a reasonable strategy for
that case.

3. I agree with you.

On Thu, Jul 20, 2017 at 1:45 AM, Justin Uberti <juberti@google.com> wrote:
> Since there will be no WG meeting this week, here are the open issues = for
> the document. Feedback on these issues is the only thing standing betw= een
> this document and WGLC.
>
> 1. https://github.com/juberti/draughts/issues= /59
>
> In the problem statement, should the paragraph on VPNs mention IP addr= ess
> discovery?
>
> Currently, the problem statement says the following:
>
>=C2=A0 =C2=A0 1.=C2=A0 If the client is behind a Network Address Transl= ator (NAT), the
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 client's private IP addresses, typicall= y [RFC1918] addresses, can
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 be learned.
>
>=C2=A0 =C2=A0 2.=C2=A0 If the client tries to hide its physical locatio= n through a
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Virtual Private Network (VPN), and the VPN = and local OS support
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 routing over multiple interfaces (i.e., a &= quot;split-tunnel" VPN),
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 WebRTC will discover the public address for= the VPN as well as
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the ISP public address that the VPN runs ov= er.
>
> However, Bernard mentioned that even without split-tunnel support, the= ICE
> implementation allows discovery of the VPN private address. I think th= is is
> covered by the first paragraph, but perhaps this should be spelled out=
> further. Thoughts?
>
> 2. https://github.com/juberti/draughts/issues= /60.
>
> Should supporting WebRTC over Tor be an explicit goal of this document= (and
> mentioned in the goals section)?
>
> This scenario is possible via Mode 4, e.g. force-proxy mode, but it ma= y be
> out of scope for this document. Bernard mentioned that it may be out o= f
> scope as Tor distros can disable Javascript, making WebRTC useless, bu= t upon
> investigation I found that the default Tor bundle does enable Javascri= pt,
> and so this is worth considering. Thoughts?
>
> 3. https://github.com/juberti/draughts/issues= /61
>
> Should the document discuss implementation details as it relates to > suggested default behavior?
>
> The document currently says the following:
>
>=C2=A0 =C2=A0 =C2=A01.=C2=A0 By default, WebRTC should follow normal IP= routing rules, to the
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 extent that this is easy to determine (i.e.= , not considering
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxies).=C2=A0 This can be accomplished by= binding local sockets to
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the wildcard addresses (0.0.0.0 for IPv4, := : for IPv6), which
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 allows the OS to route WebRTC traffic the s= ame way as it would
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTP traffic, and allows only the 'typi= cal' public addresses to
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 be discovered.
>
> However, Bernard thinks that this text may be making some assumptions,=
> specifically about whether a strong or weak host model is used. My thi= nking
> was that spelling out the general implementation approach helps reader= s grok
> exactly what this section is getting at, but open to other opinions he= re.
>
>
>
>
> __________________= _____________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--f403045ed840b4523a0564f4b321-- From nobody Sun Feb 11 11:25:18 2018 Return-Path: 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 43675126DEE for ; Sun, 11 Feb 2018 11:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 nbcpvloFiaSZ for ; Sun, 11 Feb 2018 11:25:15 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864481200F1 for ; Sun, 11 Feb 2018 11:25:15 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id e125so7703068vkh.13 for ; Sun, 11 Feb 2018 11:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W1Sk/sAP2BToO2stvYgnZsf1l3gVgS0iDm6Noe/b/q4=; b=gEBPT0iCyj7/zxmNcuHEsD6bz1mZlwvX1LGOHC1wFh+sUYfIJ5Qk2gxkDy933JYeiI UoMNM9uXu1g8ieDw0CpI8uvIKpdl/FavVIPLLCScXpS4YLByRBbbVT3FVjWVQX7ZpwhA 6QlZLM/IsrXb5DYby95LVynSKt1Og3ej4WOqOW9CZ021nTtiC0raFwg+LY7o72ZEWuuB GbrpgjQXCMlh9Axo4eRl+Cs/1bGKZH5rUp/tp00xtD7atiR1g24eslZoWkAoED6PC6yV SzCuQTk+nU5uVND9F0SEiP3UYTXUdtk9Z/3eiIM9NkjcGS1zXI/xizFDwfZfjyk6MnI9 PLfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W1Sk/sAP2BToO2stvYgnZsf1l3gVgS0iDm6Noe/b/q4=; b=P8+aEGhdmPdzV6TZaei+tGkyfHDI26ixch1UpZrd9iqQKH+kzvQXygNu/7IQSqg1FH Ca+d8IVKTLaGOyIZZfgSFFulm54xTtuCh6uQlBcv3AwOu2/XdLa+Ga2SKzCFFXOLxmrZ XVpFnqQN6fYVdY3p/W2KIR+S9y4AALBdgUS/CG9jnRrSLhNazf4H3P4yrkiKRjuMHuT6 wI6CnlMExpKL9cz7haHL5UVUXCrVcbs2uGCsK3m6sHVdK2G56vpvK7ffbf1lNZFPdk6K lnwgqU41CmfawnmXwOSUt4co3DlhGzZMCllY6yCYlM7U7PbJLdQ9jSEjPANkcPjfE/Mb cKJg== X-Gm-Message-State: APf1xPBRfJohdB197v23fU0JvkwFyrqeewfbf7hJYHonw82MDIYvKwWX oQtj+BnJd6XYeBv9rIPLHG4Z8K9aPERCiP1EU27IzK2mO4E= X-Google-Smtp-Source: AH8x224y4yM2hh7i1D62CVLfPzWf/o9nvGt800zWL9jGKOdZAzDd+kYHIjnZF5DkzRtqRKGmSta9uTG6QCVclR6j6v8= X-Received: by 10.31.161.20 with SMTP id k20mr8705285vke.82.1518377114025; Sun, 11 Feb 2018 11:25:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.161.142 with HTTP; Sun, 11 Feb 2018 11:24:53 -0800 (PST) In-Reply-To: References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <8AACCCBE-CB5D-420C-8B31-C3144D9634F0@iii.ca> From: Justin Uberti Date: Sun, 11 Feb 2018 11:24:53 -0800 Message-ID: To: James Pearce Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="001a1143f97a84f75a0564f4b8ad" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 11 Feb 2018 19:25:17 -0000 --001a1143f97a84f75a0564f4b8ad Content-Type: text/plain; charset="UTF-8" This has been rolled into the most recent version of the document, https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05#section-6. On Fri, Nov 10, 2017 at 7:36 AM, James Pearce wrote: > Hi All, > > Apologies for resurrecting this topic from August. Has anything been > decided regarding this? Has it been rolled into other changes, or is it > still being considered? > > Many thanks, > > James > > On 1 September 2017 at 14:57, Cullen Jennings wrote: > >> >> > On Aug 23, 2017, at 3:06 PM, James Pearce wrote: >> > >> > >> > The obvious solution seems to be to change the behaviour of mode 2. >> Rather than using the default route in all cases, we should use the route >> that was used to fetch the origin. This seems to resolve both the usability >> and privacy concerns without reducing existing security. >> >> I agree this is a significant problem and your proposal does seems like a >> better solution that the current text. We should get people to think about >> the implications of that change. >> >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1143f97a84f75a0564f4b8ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Nov 10, 2017 at 7:36 AM, James Pearce = <james@jamesan= djo.com> wrote:
Hi All,=C2=A0

Apologies for resurrecting this topi= c from August. Has anything been decided regarding this? Has it been rolled= into other changes, or is it still being considered?

<= div>Many thanks,

James

On 1 September 2017 at 14:57, Cullen Jennings <= fluffy@iii.ca> wrote:

> On Aug 23, 2017, at 3:06 PM, James Pearce <james@jamesandjo.com> wrote:
>
>
> The obvious solution seems to be to change the behaviour of mode 2. Ra= ther than using the default route in all cases, we should use the route tha= t was used to fetch the origin. This seems to resolve both the usability an= d privacy concerns without reducing existing security.

I agree this is a significant problem and your proposal does seems l= ike a better solution that the current text. We should get people to think = about the implications of that change.




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a1143f97a84f75a0564f4b8ad-- From nobody Sun Feb 11 14:59:36 2018 Return-Path: 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 4875A1270AE for ; Sun, 11 Feb 2018 14:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4KiCYc1OH42C for ; Sun, 11 Feb 2018 14:59:33 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E301267BB for ; Sun, 11 Feb 2018 14:59:32 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id m20so12437608otf.3 for ; Sun, 11 Feb 2018 14:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oBOMzkEEtzzIuCInqumqjPeJEA45dhsDV/SvfFBwWLo=; b=s67R6MHN5MfwAtWC2iQMylqw0H9rZgbczFlPQDhW4Pg0a4AN9h7C9YeYQftUYg1/m2 0RaiJ4D0MIqX/Zn3tfWjMfqM7jJt4SfLdwpfeLgDEF6WxhTF0BTNJiy3o505WvVp9kPn iinfjby+mWvBmYSkr06RnqoL1aqWnvIjeaoQhDSSIxe2St3CHfHzjHCmTU002Clktfvo kIEGWUUDJS7m60noLArd3XEwL3FUHqHyMG8DBxCMdKoxOnkijapbrLedxxq5zo4LlGz9 qpTneLUUi5wJFmiIf+ZznvmVLGSLrcn8LGLx7ct6shCoGWGGkajeSgnhP/l0/GrDL2IE mWYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oBOMzkEEtzzIuCInqumqjPeJEA45dhsDV/SvfFBwWLo=; b=n4ftpodST4tr7GSsTnuF2CUGqpVCvg1ywGbISP5hNJUN2gPmB6bQx52jjBuSiK7RAR u8bcCe4vyQgqItpENI7qaXTfCmQxMj7FDyHLBw75okWhh7VCqSNG9q0vMEVyaiONy193 RRGMKq0qKRMFW71n8ithQKaE8QIpM3iVdBOdObzhqMpI2lhcpJjLFgsTx7G/5I+fGzsU LtFkD89Ol9XFFxU+rXyMaSsdUCJpenLpKXmhX26f7l6OBF2h72g+JqgS0VLuFySK2LHe XvOgcOHXshYjUzhLtWdGlpyFJLrUs8/ylR/PV/u/8C8bcowa1IHuQqZ0KghetPqFXByx uS+g== X-Gm-Message-State: APf1xPBqJH8W38gm+BeHgJi3iW9WjdFPwVaHRmBx+Oz/CJAV6AccLURm VAu9Sew5ezNI6WG7OvFKOphI6ZIoKvGaXTcFlow= X-Google-Smtp-Source: AH8x2241EO/bcmYCy3ZSEjRlO5v4GpPN17FjuaTKUwliFi3o3F4ddogJ0H0DiGQdX+ZSz6VlGXVf3injlT10LABDmn0= X-Received: by 10.157.46.206 with SMTP id w72mr7862834ota.16.1518389971857; Sun, 11 Feb 2018 14:59:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Sun, 11 Feb 2018 14:59:31 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 12 Feb 2018 09:59:31 +1100 Message-ID: To: Justin Uberti Cc: "rtcweb@ietf.org" , Bernard Aboba Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 11 Feb 2018 22:59:35 -0000 Lots more changes there than I expected, most good. When talking about mode 1, you say: "significanly limites the network information exposed to arbitrary web pages." Aside from the typos there, I think that this is incorrect. You are talking about mode 1, which creates maximum exposure. I think that what limits information is the requirement for explicit permission, but that isn't how the sentence is constructed. With the addition of "The recommended defaults are as follows:" that same text is potentially more misleading. It suggests that mode 1 is the first choice, which isn't the intent at all. I would revert that addition. The newly added Section 6 seems exclusively about implementation of the route towards an origin. I think that this goal could be more explicit (changing the header might help). I also think that it could be constructed more rationally: 1. Goal: The intent is to determine the source address that would be added to packets that are sent toward the origin. Start by assuming that UDP and TCP get the same routing. 2. Process: Bind a UDP socket to the null address (0.0.0.0 or ::) and tell the socket to connect to the IP we have previously determined for the origin. Generally this results in the socket being assigned a local address based on the host routing table without sending any packets. The socket can then be queried to determine the local address. 3. Details: Hosts that use a proxy can use the IP address they would use for connecting to that proxy. For a file:// origin, pick a route toward an arbitrary IP address. "If the client is behind a proxy and cannot resolve the IPs via DNS, the IPv4/v6 addresses of the proxy can be used instead." (Nit: "IP addresses") I think that this suggests a different default for clients that use proxies... Nits: p2p needs acronym expansion, OS probably too On Mon, Feb 12, 2018 at 6:23 AM, Justin Uberti wrote: > OK, I updated the doc as discussed in this thread. PTAL at > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 and see if the > changes look reasonable. > > On Thu, Dec 14, 2017 at 1:32 PM, Martin Thomson > wrote: >> >> Since I was asked... >> >> 1. I think that this might benefit from a mention of the case. You >> are taking the effort to address the VPN case, but if someone has a >> public address, this might be a surprise. >> >> 2. No specific text necessary here I think. Forcing a proxy should do >> for this case. It's true that Tor browser doesn't necessarily disable >> JS and WebRTC, but the forced proxy mode is a reasonable strategy for >> that case. >> >> 3. I agree with you. >> >> On Thu, Jul 20, 2017 at 1:45 AM, Justin Uberti wrote: >> > Since there will be no WG meeting this week, here are the open issues >> > for >> > the document. Feedback on these issues is the only thing standing >> > between >> > this document and WGLC. >> > >> > 1. https://github.com/juberti/draughts/issues/59 >> > >> > In the problem statement, should the paragraph on VPNs mention IP >> > address >> > discovery? >> > >> > Currently, the problem statement says the following: >> > >> > 1. If the client is behind a Network Address Translator (NAT), the >> > >> > client's private IP addresses, typically [RFC1918] addresses, can >> > >> > be learned. >> > >> > 2. If the client tries to hide its physical location through a >> > >> > Virtual Private Network (VPN), and the VPN and local OS support >> > >> > routing over multiple interfaces (i.e., a "split-tunnel" VPN), >> > >> > WebRTC will discover the public address for the VPN as well as >> > >> > the ISP public address that the VPN runs over. >> > >> > However, Bernard mentioned that even without split-tunnel support, the >> > ICE >> > implementation allows discovery of the VPN private address. I think this >> > is >> > covered by the first paragraph, but perhaps this should be spelled out >> > further. Thoughts? >> > >> > 2. https://github.com/juberti/draughts/issues/60. >> > >> > Should supporting WebRTC over Tor be an explicit goal of this document >> > (and >> > mentioned in the goals section)? >> > >> > This scenario is possible via Mode 4, e.g. force-proxy mode, but it may >> > be >> > out of scope for this document. Bernard mentioned that it may be out of >> > scope as Tor distros can disable Javascript, making WebRTC useless, but >> > upon >> > investigation I found that the default Tor bundle does enable >> > Javascript, >> > and so this is worth considering. Thoughts? >> > >> > 3. https://github.com/juberti/draughts/issues/61 >> > >> > Should the document discuss implementation details as it relates to >> > suggested default behavior? >> > >> > The document currently says the following: >> > >> > 1. By default, WebRTC should follow normal IP routing rules, to the >> > >> > extent that this is easy to determine (i.e., not considering >> > >> > proxies). This can be accomplished by binding local sockets to >> > >> > the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which >> > >> > allows the OS to route WebRTC traffic the same way as it would >> > >> > HTTP traffic, and allows only the 'typical' public addresses to >> > >> > be discovered. >> > >> > However, Bernard thinks that this text may be making some assumptions, >> > specifically about whether a strong or weak host model is used. My >> > thinking >> > was that spelling out the general implementation approach helps readers >> > grok >> > exactly what this section is getting at, but open to other opinions >> > here. >> > >> > >> > >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > > > From nobody Sun Feb 11 15:24:13 2018 Return-Path: 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 03237126C3D for ; Sun, 11 Feb 2018 15:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 bCsXo4vgeBmL for ; Sun, 11 Feb 2018 15:24:10 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A0F1267BB for ; Sun, 11 Feb 2018 15:24:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0EF9FBE39 for ; Sun, 11 Feb 2018 23:24:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuU6zjypEXsO for ; Sun, 11 Feb 2018 23:24:06 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 57B52BDF9 for ; Sun, 11 Feb 2018 23:24:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518391446; bh=bc0XapcliYAN79xqWF/dwOS6Vvb73p/uRK/hpySQdb4=; h=Subject:References:To:From:Date:In-Reply-To:From; b=BOy4ICZOCNviREUGxSZcRic2ctbmcNP1xOGNSLFtWQYkjMNph9mROf8/ifuQzalI5 AECEIUsfJGpizAE7DCEr01mOnjqhU9MD5FXwYPVM5b4mSnDnbFFOQ7fvbP70BjrX8O OZWy7HXKvmPUspgUBA7O2wAhRZSXl0fNtHhwN5DA= References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> To: rtcweb@ietf.org From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Sun, 11 Feb 2018 23:24:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151833965150.17077.13014329219354900316@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9OdsJv1UEB15O0MyLwHDBeMGjE7vHHWN8" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 11 Feb 2018 23:24:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9OdsJv1UEB15O0MyLwHDBeMGjE7vHHWN8 Content-Type: multipart/mixed; boundary="aAuZzU3vMR0gP6IrE8L97rOrHGfVeNjGv"; protected-headers="v1" From: Stephen Farrell To: rtcweb@ietf.org Message-ID: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> In-Reply-To: <151833965150.17077.13014329219354900316@ietfa.amsl.com> --aAuZzU3vMR0gP6IrE8L97rOrHGfVeNjGv Content-Type: multipart/mixed; boundary="------------1E91ED4DD251AFDF868549E5" Content-Language: en-GB This is a multi-part message in MIME format. --------------1E91ED4DD251AFDF868549E5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I forget if this was explicitly discussed before. Apologies if it was. I consider the following text ridiculous: "Mode 1 MUST only be used when user consent has been provided;" The reason is that it is not possible for all WebRTC users to ever provide real consent to something dealing with which IP addresses are used in ICE. So assuming consent is just BS, as people cannot provide consent to something they do not understand. (And that won't be explained by their systems or s/w.) For me, that means that this draft will appear pretty much as a fig leaf, intended by us technologists to allow us to pretend we're doing the right thing, when we're not. I think that's not really that useful. Is it really too late to try fix the concept of consent that's (ab)used in WebRTC? Even if so, I don't see any reason to make it worse, via this draft, and especially via the quoted text above, so I'd argue that we ought get rid of that concept from this draft. FWIW, I reckon, if implementers liked it, that there is a better answer here which is to provide an interface (API and/or UI) that allows selected interfaces to be omitted from ICE. S. On 11/02/18 09:00, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Real-Time Communication in WEB-browser= s WG of the IETF. >=20 > Title : WebRTC IP Address Handling Requirements > Authors : Justin Uberti > Guo-wei Shieh > Filename : draft-ietf-rtcweb-ip-handling-05.txt > Pages : 10 > Date : 2018-02-11 >=20 > Abstract: > This document provides information and requirements for how IP > addresses should be handled by WebRTC implementations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------1E91ED4DD251AFDF868549E5 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------1E91ED4DD251AFDF868549E5-- --aAuZzU3vMR0gP6IrE8L97rOrHGfVeNjGv-- --9OdsJv1UEB15O0MyLwHDBeMGjE7vHHWN8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJagNCVAAoJEFqy+vF7FyvqXRQQAKBb4rXbkdYZjhZitGY4OTeb HDLd6KY2pLz8gTXH92gd9GQqMu1pxwUGU6aRj9NhkFKQmG9DVvodWHsQEa5AhB5D 9q940KiLV6oMMnb3WCDhsvMlQVnqcCnvcg6NHtPEE/enpw7+VsR2zkjQ7DP7HzqI 5LEpLxM73eP7Hy/VMdnWcAl5PBvTm6JYWjZBfGbfwQx8wgJfRh+9/ofrCTRXHvgi Hg0z5TiPsxmjWWjCZz9pCPkuuA/Md4/zEPA6J0BsKLveFLBCAP2phMP61i0L5nvq xLRhcU5HSPBGpWUeLmcqOC2Oiqgg8hzOXzDvmadnvPkQBTUMiZwKkowexujpRdyM zq9D0tXj097u6RiB9K5aSs/4a9KBKx6SQZCmOhhCNZGQA1T8YSAW3IFPjDX/wFiU 09akLzRbb2LRIVfwRQlF7tJPUpEbYiKlnvOCFz5OK++5x6L/ZHA4OZWN6R3qt8xN Xbge10h8QlVbJcNoC2BTJ0BmcwWH9YHHbsULgNNHiUD9KwCrKcB0suKe3LR9olk0 ckNJ7qcwerIVP3oKfP4BzIMyoMEHT2MYK7dnzN1BlA00oXVVuAK+weFfUdSa6051 CGkTNDaULsumnb53Zgow0T9tqt9Lt3BovJ/nGAEO8d//cpmzseSwpUjw8yIPZXbw oWqTqpLDBykX49K2C7ac =wQg5 -----END PGP SIGNATURE----- --9OdsJv1UEB15O0MyLwHDBeMGjE7vHHWN8-- From nobody Sun Feb 11 17:13:11 2018 Return-Path: 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 132501242F7 for ; Sun, 11 Feb 2018 17:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no 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 nQ4GZpdYrZC6 for ; Sun, 11 Feb 2018 17:13:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2986212025C for ; Sun, 11 Feb 2018 17:13:08 -0800 (PST) Received: from [IPv6:2607:fb90:2767:7303:ec21:bc97:5dc7:413a] (mfb0536d0.tmodns.net [208.54.5.251]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w1C1Cwg0051575 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 11 Feb 2018 19:12:59 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mfb0536d0.tmodns.net [208.54.5.251] claimed to be [IPv6:2607:fb90:2767:7303:ec21:bc97:5dc7:413a] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Adam Roach Mime-Version: 1.0 (1.0) Date: Sun, 11 Feb 2018 18:08:32 -0700 Message-Id: <8E3729B4-AFE1-448E-97A2-3AABEBE14242@nostrum.com> References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> Cc: rtcweb@ietf.org In-Reply-To: To: Stephen Farrell X-Mailer: iPhone Mail (15D60) Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 12 Feb 2018 01:13:10 -0000 > On Feb 11, 2018, at 16:24, Stephen Farrell wro= te: >=20 > Is it really too late to try fix the concept of consent that's > (ab)used in WebRTC? What is your concrete proposal? /a= From nobody Sun Feb 11 17:29:08 2018 Return-Path: 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 EC7FA1242F7 for ; Sun, 11 Feb 2018 17:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 lFr7YXWPz-7U for ; Sun, 11 Feb 2018 17:29:03 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B673A12025C for ; Sun, 11 Feb 2018 17:29:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94EE3BE47; Mon, 12 Feb 2018 01:29:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaFlY3x87gX3; Mon, 12 Feb 2018 01:29:00 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3AA36BE2F; Mon, 12 Feb 2018 01:29:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518398940; bh=gqfDSt+zcur25StNtmEfJILmnnr/Z+gHWY2d8DyMzN4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YR5kZbbArGPxFP9nmi/KtDiFQSxKy5GXfkk31jnmn43zzO4F1ZrXuROiTTX1I/ToY +Tjk+Rl8pn9F3FejOsfQ71QuDDF6+pyvufPxJMo4a/Hdms3DLdLfEYeAa/phXmsCag NUcuHTM7cyDK+P1uDl0we9W+c44Uu3jS2BpbBgzI= To: Adam Roach Cc: rtcweb@ietf.org References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <8E3729B4-AFE1-448E-97A2-3AABEBE14242@nostrum.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <52741543-b68b-97ba-17f2-a790ea5dfe32@cs.tcd.ie> Date: Mon, 12 Feb 2018 01:28:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8E3729B4-AFE1-448E-97A2-3AABEBE14242@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d5Jkeu9cfreDmEXsLjGTgMH92YZ8hhq0v" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 12 Feb 2018 01:29:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d5Jkeu9cfreDmEXsLjGTgMH92YZ8hhq0v Content-Type: multipart/mixed; boundary="mYxWM5T9JvSfX5X62ZjPjYg9jQlDyNUdm"; protected-headers="v1" From: Stephen Farrell To: Adam Roach Cc: rtcweb@ietf.org Message-ID: <52741543-b68b-97ba-17f2-a790ea5dfe32@cs.tcd.ie> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <8E3729B4-AFE1-448E-97A2-3AABEBE14242@nostrum.com> In-Reply-To: <8E3729B4-AFE1-448E-97A2-3AABEBE14242@nostrum.com> --mYxWM5T9JvSfX5X62ZjPjYg9jQlDyNUdm Content-Type: multipart/mixed; boundary="------------ED5E5A08EB281C69F142DAE0" Content-Language: en-GB This is a multi-part message in MIME format. --------------ED5E5A08EB281C69F142DAE0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 12/02/18 01:08, Adam Roach wrote: >=20 >=20 >> On Feb 11, 2018, at 16:24, Stephen Farrell = wrote: >> >> Is it really too late to try fix the concept of consent that's >> (ab)used in WebRTC? >=20 > What is your concrete proposal? Remove all mention of "consent." I'm not that fussed as to how that's done - were it done, I'd be happy that IETF processes would lead to a better outcome than today's. But to try be concrete: How about we re-cast any related issues in terms of specific actions authorised, or not, by those who can understand the relevant issues. Often that'd be developers of the relevant implementations, who ought be encouraged/required to provide users with meaningful decision points - to which the answer "no, I don't like your default" ought not be very uncommon. (For tricky issues like this.) In cases where the technology absolutely requires a user decision, then IMO the onus is on us (us being the union of the relevant sets of implementers) to enable that to be an informed decision. Bringing that back to WebRTC/ICE, I think the better thing to do is to define an API (in IETF or W3C, I don't care) that allows combinations of applications (like VPN clients) and people, to say which interfaces ought be visible to ICE at what points in time. That way, IETF specs don't need to talk about mythical "consent" - such issues become apparent to end-users via configuration or e.g. VPN-client UIs. That said, I'm not wedded to any particular manner in which we succeed in removing the nonsense that consent is actually in play here. S. >=20 > /a >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------ED5E5A08EB281C69F142DAE0 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------ED5E5A08EB281C69F142DAE0-- --mYxWM5T9JvSfX5X62ZjPjYg9jQlDyNUdm-- --d5Jkeu9cfreDmEXsLjGTgMH92YZ8hhq0v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJagO3bAAoJEFqy+vF7FyvqOy0P/1uyqaNaHSz2D0IfIOexdocu Y0C6J6jbEkEdlKEm6/sH0KK04OzmrRxNXu2Uh+geH7wIzvXahXa5uaYfFjkq6GRN mM+3fTBwCSwm1Ppx6u1rv8pMnPTJqC2OzoKsn29M5vXHPPVhjSp1lw6zCXIH4LdM QUWpugmNF5AMsgwH+/9ouGaktfbInBmY+9e1K2iWS8HKgfd8UrG92H66XgGZ1tN8 i+F6vA00MMZgJY5dP0uVI2QEYFte2ZC9rJCB/8LLLGNxolc64CA34UCcCGe6n3Bs JKxjs1praOjF4Fo4VxMYOwtNggu49fo/z98VQn9Ds1qxIapbgWMb7Xx6JfEuSUG+ RbTpMig4r/ofZ1KeQksd17Uj032A4YPtAdAdgcxCCarm1G8y0dWKcsZhgGSukgDg QB0er2h3jIuFk4xQe+SadqyzsM6yTjOyMNbO9rbT2Zfv1XMcTni8dZ7W9mEd9+hH FVgoV54oMdJXii3QATO5w/hxfNppwBVQ3bWR6l9Fv9CmQRQh9kUK2DMljtc305FC f/XV+zViim8+9wC9uAyAeleXZ5ooTSia9eeoKqdPM00n5W7bIhU0xCxODI8WaIwN RC+RjBVclpgc88Ex6lOdJgk3XWpOtmXx3u2ujB/0jxA7N1sGn83dH40EiyZRVPYX vmwUDbegDQ1SsNx/m9jP =wUSz -----END PGP SIGNATURE----- --d5Jkeu9cfreDmEXsLjGTgMH92YZ8hhq0v-- From nobody Mon Feb 12 01:26:38 2018 Return-Path: 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 3DDEF1241F5 for ; Mon, 12 Feb 2018 01:26:36 -0800 (PST) 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 autolearn_force=no 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 u8LZrEPro9pO for ; Mon, 12 Feb 2018 01:26:28 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66061120047 for ; Mon, 12 Feb 2018 01:26:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EB5737C3965; Mon, 12 Feb 2018 10:26:26 +0100 (CET) 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 WtGnARDkZkFE; Mon, 12 Feb 2018 10:26:25 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id A971F7C3565; Mon, 12 Feb 2018 10:26:25 +0100 (CET) To: Stephen Farrell , rtcweb@ietf.org References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> From: Harald Alvestrand Message-ID: <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> Date: Mon, 12 Feb 2018 10:26:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4nJoyJTGL3HTRWQ9ONTp72IPtOxdXt9Zx" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 12 Feb 2018 09:26:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4nJoyJTGL3HTRWQ9ONTp72IPtOxdXt9Zx Content-Type: multipart/mixed; boundary="0RsmhtvjjZfAv48EiV897VF62fuyie8pp"; protected-headers="v1" From: Harald Alvestrand To: Stephen Farrell , rtcweb@ietf.org Message-ID: <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> In-Reply-To: --0RsmhtvjjZfAv48EiV897VF62fuyie8pp Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Den 12. feb. 2018 00:24, skrev Stephen Farrell: >=20 > I forget if this was explicitly discussed before. Apologies if > it was. >=20 > I consider the following text ridiculous: >=20 > "Mode 1 MUST only be used when user consent has > been provided;" >=20 > The reason is that it is not possible for all WebRTC users to > ever provide real consent to something dealing with which IP > addresses are used in ICE. So assuming consent is just BS, as > people cannot provide consent to something they do not understand. > (And that won't be explained by their systems or s/w.) >=20 > For me, that means that this draft will appear pretty much as a > fig leaf, intended by us technologists to allow us to pretend > we're doing the right thing, when we're not. I think that's not > really that useful. >=20 > Is it really too late to try fix the concept of consent that's > (ab)used in WebRTC? I'm sorry, but I don't agree with you on this point. The decision to go for these modes was based on the theory that if the user has already consented to the near-perfect tracking abilities that are implicit in offering a video stream (tracking camera defects, for instance), and all the information that can be gleaned from a live audio stream, then the idea of protecting the user against tracking by restricting access to his IP addresses became of so little value that it was moot and was worth trading away for better performance of the functions the user asked for. Explanations about what the IP address is for and how it is used doesn't matter in this argument. The point is that the user has already agreed to a degree of invasion of privacy that a) is perfectly understandable, and b) is of significantly more significance than what's being discussed here. Unfortunately the way in which documents depend on each other, and the degree to which it's desirable to have each area of concern be described on its own, make it hard to state this in the document as explicitly as I do when discussing it. This thread re-raises an issue that has been hashed over many times, and I believe the current draft represents the (rough) consensus of the WG on this matter. >=20 > Even if so, I don't see any reason to make it worse, via this > draft, and especially via the quoted text above, so I'd argue > that we ought get rid of that concept from this draft. >=20 > FWIW, I reckon, if implementers liked it, that there is a > better answer here which is to provide an interface (API and/or > UI) that allows selected interfaces to be omitted from ICE. We have that API offered in Javascript already. It's called "skipping the candidates". But JS API surface helps the JS provider defend against other attackers; it has no benefit when the JS provider *is* the attacker= =2E Non-JS-visible APIs discussed have included the ability to specify "corporate" TURN servers in browser configs and requiring that these be used. These are typically out of scope for standards; I haven't seen anything published on whether or not those have been implemented. >=20 > S. >=20 > On 11/02/18 09:00, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Real-Time Communication in WEB-browse= rs WG of the IETF. >> >> Title : WebRTC IP Address Handling Requirements >> Authors : Justin Uberti >> Guo-wei Shieh >> Filename : draft-ietf-rtcweb-ip-handling-05.txt >> Pages : 10 >> Date : 2018-02-11 >> >> Abstract: >> This document provides information and requirements for how IP >> addresses should be handled by WebRTC implementations. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 >> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-05= >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-05 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --0RsmhtvjjZfAv48EiV897VF62fuyie8pp-- --4nJoyJTGL3HTRWQ9ONTp72IPtOxdXt9Zx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJagV2/AAoJEGsBVt6Jonw0HfcP+gOucT1ac9lwB2mT48PgnzXt yTiqGg3iecqd45SpbfJ7wUOqlPQ9QrZrV0vj2bMzMnVAbZageJ00kHMjEelYbzDa 8sRMEB5F3hmzB/HdE7zHqhGDrslDsKcR5c2gHW6qve/YDCZSzBOIP0wYlhoN8Sww kne/WHkIy5dMzvJeuL8M7MZBYYI5iggfIabtg3iSPV+ce00esPfOgt1dpxM5rGS4 /D0yc9JW1VfW34SN3s7PGgGNu3Nrp88wH0n/OVzNpcW0a5R1OcRLZdLS/9suMO92 FlBNnIfI5IatL4nSQOEbji3F2yRBju222LLa04j3M7HBytXNMNCAN1J6mJzk/5jI 7UHVTkXyMx5MyVTSlA2dkOLWHJp0ynyPU6ZIZueMcp+wahP/FSp1lFRmuRU+M9ZO a4YE8trfjnHrfFSs71yCxAkMZcsbwG/pyQI1YSzQghbNTf1hhOp2/vp4gOntVVk2 lJDuUoFI/SbZX4qG9/537igB8/lHtZueb7ySEU1ARrjyky00j31DPVmEtEXSKgW0 KfohuG11fvEwWdY87JUOJ0jyqeyVX608JgDF/CTqh1PM7s075QuhVeSI9NmayO6r 1fbRa+05gqfN5AKBdn6XXlpfezAJLJ2qd/wLumhxzIvybf8UywupCyUn5ursnmgt dBuLyf/LXHh8q0vm2otE =LPbc -----END PGP SIGNATURE----- --4nJoyJTGL3HTRWQ9ONTp72IPtOxdXt9Zx-- From nobody Mon Feb 12 03:12:34 2018 Return-Path: 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 42536127601 for ; Mon, 12 Feb 2018 03:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 5kIy5FbpupXa for ; Mon, 12 Feb 2018 03:12:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3371275FD for ; Mon, 12 Feb 2018 03:12:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5821FBE49; Mon, 12 Feb 2018 11:12:27 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YMHSBtrgN98; Mon, 12 Feb 2018 11:12:27 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16D3EBDCC; Mon, 12 Feb 2018 11:12:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518433947; bh=/a+2DSEW1eCY7JEyAJT98MxjPvVUxmvDqsJEGOxSPCg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=uZzy565j3kJjrDttfsqFJdwlsMtNJSwQ1OvYPVf/QRzDIP6LW9Tz4doqOgawwDteP nIUM713HFb9aYyVTyiWXWa4niNr3OhoyzETM3xfF43h+/q8Ki1nZLbcDbJLBcu1fpZ cMpSJ1tJubAKoWgb5QYTBY8eo7YN2a7IBabK/3hE= To: Harald Alvestrand , rtcweb@ietf.org References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <5acebff2-364c-45f2-c92a-992ba88f47ef@cs.tcd.ie> Date: Mon, 12 Feb 2018 11:12:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xAJKKkcSUH95KGQKvjx5q5M2nyqRTOKd5" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 12 Feb 2018 11:12:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xAJKKkcSUH95KGQKvjx5q5M2nyqRTOKd5 Content-Type: multipart/mixed; boundary="CBXYCvBokQ5jtg00Ext2CxvMBjJQXfg2M"; protected-headers="v1" From: Stephen Farrell To: Harald Alvestrand , rtcweb@ietf.org Message-ID: <5acebff2-364c-45f2-c92a-992ba88f47ef@cs.tcd.ie> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> In-Reply-To: <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> --CBXYCvBokQ5jtg00Ext2CxvMBjJQXfg2M Content-Type: multipart/mixed; boundary="------------970011CF575D6E0C729D8F2B" Content-Language: en-GB This is a multi-part message in MIME format. --------------970011CF575D6E0C729D8F2B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 12/02/18 09:26, Harald Alvestrand wrote: > Den 12. feb. 2018 00:24, skrev Stephen Farrell: >> >> I forget if this was explicitly discussed before. Apologies if >> it was. >> >> I consider the following text ridiculous: >> >> "Mode 1 MUST only be used when user consent has >> been provided;" >> >> The reason is that it is not possible for all WebRTC users to >> ever provide real consent to something dealing with which IP >> addresses are used in ICE. So assuming consent is just BS, as >> people cannot provide consent to something they do not understand. >> (And that won't be explained by their systems or s/w.) >> >> For me, that means that this draft will appear pretty much as a >> fig leaf, intended by us technologists to allow us to pretend >> we're doing the right thing, when we're not. I think that's not >> really that useful. >> >> Is it really too late to try fix the concept of consent that's >> (ab)used in WebRTC? >=20 > I'm sorry, but I don't agree with you on this point. Fair enough. >=20 > The decision to go for these modes was based on the theory that if the > user has already consented to the near-perfect tracking abilities that > are implicit in offering a video stream (tracking camera defects, for > instance), and all the information that can be gleaned from a live audi= o > stream, then the idea of protecting the user against tracking by > restricting access to his IP addresses became of so little value that i= t > was moot and was worth trading away for better performance of the > functions the user asked for. I understand that logic. It does however seem to have caused issues for at least some people who don't agree that the this leakage is moot. I'm not claiming that all such claims are well founded, but I think at least some are. >=20 > Explanations about what the IP address is for and how it is used doesn'= t > matter in this argument. The point is that the user has already agreed > to a degree of invasion of privacy that a) is perfectly understandable,= > and b) is of significantly more significance than what's being discusse= d > here. >=20 > Unfortunately the way in which documents depend on each other, and the > degree to which it's desirable to have each area of concern be describe= d > on its own, make it hard to state this in the document as explicitly as= > I do when discussing it. >=20 > This thread re-raises an issue that has been hashed over many times, an= d > I believe the current draft represents the (rough) consensus of the WG > on this matter. I'm willing to accept that I'm in the rough in terms of how the WG is using the term "consent." Nonetheless, if the term can be avoided here, then I still think that'd be an improvement. >=20 >> >> Even if so, I don't see any reason to make it worse, via this >> draft, and especially via the quoted text above, so I'd argue >> that we ought get rid of that concept from this draft. >> >> FWIW, I reckon, if implementers liked it, that there is a >> better answer here which is to provide an interface (API and/or >> UI) that allows selected interfaces to be omitted from ICE. >=20 > We have that API offered in Javascript already. It's called "skipping > the candidates". But JS API surface helps the JS provider defend agains= t > other attackers; it has no benefit when the JS provider *is* the attack= er. Right - I wasn't suggesting a JS API but rather one such as you describe below... >=20 > Non-JS-visible APIs discussed have included the ability to specify > "corporate" TURN servers in browser configs and requiring that these be= > used. These are typically out of scope for standards; I haven't seen > anything published on whether or not those have been implemented. Nor have I. I agree that specifying such an API in this draft wouldn't be right. I don't agree that such an interface ought be out of scope for standardisation, but do agree that figuring out where to define one could be tricky. The interface I have in mind for this case would be something that'd allow e.g. an operating system UI to state that "tun0 isn't to be used for ICE until I say otherwise" or that'd allow a VPN client application to call a browser-specific API of some sort to do the same. I guess even a browser command line argument could help some - then the folks who care about this issue could then have a different icon/button/whatever for starting a browser for webrtc-without-tun0 or whatever. What this draft could do however, is get rid of the idea of consent, and define the modes as involving all addresses except those that are omitted due to local policy, e.g. if such an interface exists and has been used. Lastly - the above is only worthwhile if implementers were likely to provide some way to omit addresses/interfaces from ICE - if WebRTC clients just weren't ever going to offer any way to e.g. omit tun0, then there'd be no point in talking about that. If it was something that could be done now or in future, then it'd be good to talk about it here though. And FWIW, I still consider talk of user consent for ICE as ridiculous:-) Cheers, S. >=20 >> >> S. >> >> On 11/02/18 09:00, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>> This draft is a work item of the Real-Time Communication in WEB-brows= ers WG of the IETF. >>> >>> Title : WebRTC IP Address Handling Requirements >>> Authors : Justin Uberti >>> Guo-wei Shieh >>> Filename : draft-ietf-rtcweb-ip-handling-05.txt >>> Pages : 10 >>> Date : 2018-02-11 >>> >>> Abstract: >>> This document provides information and requirements for how IP >>> addresses should be handled by WebRTC implementations. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 >>> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-0= 5 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-05 >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >=20 >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------970011CF575D6E0C729D8F2B Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------970011CF575D6E0C729D8F2B-- --CBXYCvBokQ5jtg00Ext2CxvMBjJQXfg2M-- --xAJKKkcSUH95KGQKvjx5q5M2nyqRTOKd5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJagXaZAAoJEFqy+vF7FyvqpX8P/izcjtcmC7GJ7hVsOzisi4Gb pTSwseOumxovAPLrUDWXxHmXUw9m2Ac6kA1daavr2SlkXNrLuQF6UlQ4dBaNbgd7 CUBjrbvlj7qVfgTy/WJbWEDszU6bVqDSYw6BXPtubyL2WtyhdO3JTONkS6LAjhdG o39li4qT/Kf37Cs+lWYfFUonYAoiKQ2+8PT0YnCpq0QzpKHox8fZMXeUKDAF1z/o 9rfZqvinf8orRkbv9zC29G8/5JgDMfIF34zmerTNS8jX230hm8P+dor5Dr0Z/Hvu A8Tm2AzldV3DSUw0R36HthgNY9GA26yl/HbkaphJ7VOVXr8CkN25F0x8NcUkC6va bIebaot7Nuzw3T8nGygk4QVlaV3JnHAaQQmbv5wqJ3eCT5y1sk9c4h8lDi0opM33 BLp4QR4e1GdGpmi6OQWyZbGnP/BoNK/RlSm8pLyOum8X11+YEaX9uOKRj43N3GDf pB2V2InMmwCxyeV3NTL3LOrIFd3b+elEGILIg0/vEw0fX2giKIdsO+U8Qm67e/N+ I2raGiocozs0aa0mMI8PEM7GMto73MwG/rkXlfZYvDMoMnd5sJ7NL5nmsUyMQ88e ZEh6psqniccFtssd7HLkuB4CdP/WHvXlRQ0XBosdH1gQUXCrdW5Lb+Aqeq1kTJJw 6wEIpfS7v13e8xwoJJrM =SG5i -----END PGP SIGNATURE----- --xAJKKkcSUH95KGQKvjx5q5M2nyqRTOKd5-- From nobody Tue Feb 13 12:46:56 2018 Return-Path: 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 2F12312D943 for ; Tue, 13 Feb 2018 12:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 ZmOhF-1lzGS8 for ; Tue, 13 Feb 2018 12:46:46 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB7B12D88F for ; Tue, 13 Feb 2018 12:46:45 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id p12so12389664uad.0 for ; Tue, 13 Feb 2018 12:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YAege7UO49FaWYoGFKUeghS9gkV/JFFdrW6VACHC+pk=; b=sFYbyxO4xjOBo3DnE1VDUfpfUD3YgC3MlYZalhZJkcppFouoZSQKXOgAY32KGERzYm ijXioFLn4ekyoR3OlvgoPeiGNgvot8x9vVpBAM4bUvAkfzITdN15VJtcjNytMsTwvNkA 5zBUHzNH4AhX5eaxI4F11sk0/LJ7kPrUnyojWP58OyWjpL1DQVx7oCQoV2xusw0EOgim mPRJOXyZqIUhEpWx2CZvITCCGWChdgIH0cM3gljsWgDhJyAgoCL+9A/VqhCrXMbTPjtJ y/UYztlMv3lGTh8BwiEcJOVelc1R9/jn/AKMxEoO6Fkx/GRwAsmGD2lt586xaNhGTfZK kzAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YAege7UO49FaWYoGFKUeghS9gkV/JFFdrW6VACHC+pk=; b=pYmP7XbeCCnd66CrDB1zcoznuJmTkM6ezdinXhH4zhA/EE/4HMzMYn5L1NePHXpLCT kMrhi5MRV9+6LeyRh1HeN1W0JYvGNaJ4e4B/h0TlT46WfKOFBUcHg6H3739V+OwKNnr1 ta3x3rcGDoOnoQOZZA4Fy3NkXX+Rz2pCTGyGn9dWMhEUxP1lH49fJA+Gm8Tbp6hxxqPY mWo0ntISyNlZv/otro7vQwCrxJBVllhGvJVfkrgVGV/QW/uZeVbMQdON5VGFwOESORhT d89Uo9FRfXpjPHOKy9MZxOYSkm/cgdl7xFJh3iRsfNXXy/ND36+RHP2T3MCqPQSCoa+A gisg== X-Gm-Message-State: APf1xPDLMwT1ynMcEkiqd6w87HXzNTbEKQQNagQai3w0341iCiTUvHIX 0xRy0XeIm+o0DhSUC/INfWGfGXuRCvrnulaPoKri6/oiFNU= X-Google-Smtp-Source: AH8x224KwPkzXZ3XSzh6FC17YZR36CaqDzHRUg1EVefxmP/C41d4tf26TE+z3Bd4L97eWjd5PTTaa4FUGm/XGWY6ZVI= X-Received: by 10.159.62.13 with SMTP id o13mr2475315uai.83.1518554803916; Tue, 13 Feb 2018 12:46:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.161.142 with HTTP; Tue, 13 Feb 2018 12:46:23 -0800 (PST) In-Reply-To: <5acebff2-364c-45f2-c92a-992ba88f47ef@cs.tcd.ie> References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> <5acebff2-364c-45f2-c92a-992ba88f47ef@cs.tcd.ie> From: Justin Uberti Date: Tue, 13 Feb 2018 12:46:23 -0800 Message-ID: To: Stephen Farrell Cc: Harald Alvestrand , RTCWeb IETF Content-Type: multipart/alternative; boundary="089e08245728a9c6e805651e1784" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 20:46:55 -0000 --089e08245728a9c6e805651e1784 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 12, 2018 at 3:12 AM, Stephen Farrell wrote: > > Hiya, > > On 12/02/18 09:26, Harald Alvestrand wrote: > > Den 12. feb. 2018 00:24, skrev Stephen Farrell: > >> > >> I forget if this was explicitly discussed before. Apologies if > >> it was. > >> > >> I consider the following text ridiculous: > >> > >> "Mode 1 MUST only be used when user consent has > >> been provided;" > >> > >> The reason is that it is not possible for all WebRTC users to > >> ever provide real consent to something dealing with which IP > >> addresses are used in ICE. So assuming consent is just BS, as > >> people cannot provide consent to something they do not understand. > >> (And that won't be explained by their systems or s/w.) > >> > >> For me, that means that this draft will appear pretty much as a > >> fig leaf, intended by us technologists to allow us to pretend > >> we're doing the right thing, when we're not. I think that's not > >> really that useful. > >> > >> Is it really too late to try fix the concept of consent that's > >> (ab)used in WebRTC? > > > > I'm sorry, but I don't agree with you on this point. > > Fair enough. > > > > > The decision to go for these modes was based on the theory that if the > > user has already consented to the near-perfect tracking abilities that > > are implicit in offering a video stream (tracking camera defects, for > > instance), and all the information that can be gleaned from a live audio > > stream, then the idea of protecting the user against tracking by > > restricting access to his IP addresses became of so little value that it > > was moot and was worth trading away for better performance of the > > functions the user asked for. > > I understand that logic. It does however seem to have caused > issues for at least some people who don't agree that the this > leakage is moot. I'm not claiming that all such claims are > well founded, but I think at least some are. > So this document tries to address two sets of issues: a) leakage in contexts when the user is not intentionally using a WebRTC application b) leakage in contexts when the user is intentionally using a WebRTC application The 'consent' discussion is focused around a), with the result being that the ISP address will not be provided when using a VPN unless the user has consented to use of their camera. The WG went back and forth and came to a rough consensus on this being a reasonable solution to the problem. However, b) is also discussed in the document, and browsers could implement their own local policy, e.g., their own default or perhaps a preference to exclusively use Mode 2, regardless of webcam consent. Such an approach wouldn't provide as much nuance as your suggested per-interface permission list, but there already are examples of this (various browser extensions that set the ip-handling mode), and I think we can all admit that asking OSes to indicate which interfaces are OK to use for ICE would be a long-term project. If it would help, I could rework the section around the recommended defaults to make it clear that users or browsers could choose not to use Mode 1, and/or discuss the defaults and how they relate to a)/b) above. > > > > Explanations about what the IP address is for and how it is used doesn't > > matter in this argument. The point is that the user has already agreed > > to a degree of invasion of privacy that a) is perfectly understandable, > > and b) is of significantly more significance than what's being discussed > > here. > > > > Unfortunately the way in which documents depend on each other, and the > > degree to which it's desirable to have each area of concern be described > > on its own, make it hard to state this in the document as explicitly as > > I do when discussing it. > > > > This thread re-raises an issue that has been hashed over many times, and > > I believe the current draft represents the (rough) consensus of the WG > > on this matter. > > I'm willing to accept that I'm in the rough in terms of how > the WG is using the term "consent." > > Nonetheless, if the term can be avoided here, then I still > think that'd be an improvement. > > > > >> > >> Even if so, I don't see any reason to make it worse, via this > >> draft, and especially via the quoted text above, so I'd argue > >> that we ought get rid of that concept from this draft. > >> > >> FWIW, I reckon, if implementers liked it, that there is a > >> better answer here which is to provide an interface (API and/or > >> UI) that allows selected interfaces to be omitted from ICE. > > > > We have that API offered in Javascript already. It's called "skipping > > the candidates". But JS API surface helps the JS provider defend against > > other attackers; it has no benefit when the JS provider *is* the > attacker. > > Right - I wasn't suggesting a JS API but rather one such as > you describe below... > > > > > Non-JS-visible APIs discussed have included the ability to specify > > "corporate" TURN servers in browser configs and requiring that these be > > used. These are typically out of scope for standards; I haven't seen > > anything published on whether or not those have been implemented. > > Nor have I. I agree that specifying such an API in this draft > wouldn't be right. I don't agree that such an interface ought > be out of scope for standardisation, but do agree that figuring > out where to define one could be tricky. > > The interface I have in mind for this case would be something > that'd allow e.g. an operating system UI to state that "tun0 > isn't to be used for ICE until I say otherwise" or that'd > allow a VPN client application to call a browser-specific API > of some sort to do the same. I guess even a browser command > line argument could help some - then the folks who care about > this issue could then have a different icon/button/whatever > for starting a browser for webrtc-without-tun0 or whatever. > > What this draft could do however, is get rid of the idea of > consent, and define the modes as involving all addresses > except those that are omitted due to local policy, e.g. if > such an interface exists and has been used. > > Lastly - the above is only worthwhile if implementers were > likely to provide some way to omit addresses/interfaces > from ICE - if WebRTC clients just weren't ever going to offer > any way to e.g. omit tun0, then there'd be no point in > talking about that. If it was something that could be done > now or in future, then it'd be good to talk about it here > though. > > And FWIW, I still consider talk of user consent for ICE as > ridiculous:-) > > Cheers, > S. > > > > >> > >> S. > >> > >> On 11/02/18 09:00, internet-drafts@ietf.org wrote: > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>> This draft is a work item of the Real-Time Communication in > WEB-browsers WG of the IETF. > >>> > >>> Title : WebRTC IP Address Handling Requirements > >>> Authors : Justin Uberti > >>> Guo-wei Shieh > >>> Filename : draft-ietf-rtcweb-ip-handling-05.txt > >>> Pages : 10 > >>> Date : 2018-02-11 > >>> > >>> Abstract: > >>> This document provides information and requirements for how IP > >>> addresses should be handled by WebRTC implementations. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > >>> > >>> There are also htmlized versions available at: > >>> https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 > >>> https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-05 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-05 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > submission > >>> until the htmlized version and diff are available at tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >>> > >> > >> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > > > > > -- > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e08245728a9c6e805651e1784 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 12, 2018 at 3:12 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

On 12/02/18 09:26, Harald Alvestrand wrote:
> Den 12. feb. 2018 00:24, skrev Stephen Farrell:
>>
>> I forget if this was explicitly discussed before. Apologies if
>> it was.
>>
>> I consider the following text ridiculous:
>>
>>=C2=A0 =C2=A0 "Mode 1 MUST only be used when user consent has<= br> >>=C2=A0 =C2=A0 =C2=A0been provided;"
>>
>> The reason is that it is not possible for all WebRTC users to
>> ever provide real consent to something dealing with which IP
>> addresses are used in ICE. So assuming consent is just BS, as
>> people cannot provide consent to something they do not understand.=
>> (And that won't be explained by their systems or s/w.)
>>
>> For me, that means that this draft will appear pretty much as a >> fig leaf, intended by us technologists to allow us to pretend
>> we're doing the right thing, when we're not. I think that&= #39;s not
>> really that useful.
>>
>> Is it really too late to try fix the concept of consent that's=
>> (ab)used in WebRTC?
>
> I'm sorry, but I don't agree with you on this point.

Fair enough.

>
> The decision to go for these modes was based on the theory that if the=
> user has already consented to the near-perfect tracking abilities that=
> are implicit in offering a video stream (tracking camera defects, for<= br> > instance), and all the information that can be gleaned from a live aud= io
> stream, then the idea of protecting the user against tracking by
> restricting access to his IP addresses became of so little value that = it
> was moot and was worth trading away for better performance of the
> functions the user asked for.

I understand that logic. It does however seem to have caused
issues for at least some people who don't agree that the this
leakage is moot. I'm not claiming that all such claims are
well founded, but I think at least some are.

So this document tries to address two sets of issues:
a) leakage in contexts when the user is not intentiona= lly using a WebRTC application
b) leakage in contexts = when the user is intentionally using a WebRTC application

The 'consent' discussion is focused around a), with the res= ult being that the ISP address will not be provided when using a VPN unless= the user has consented to use of their camera. The WG went back and forth = and came to a rough consensus on this being a reasonable solution to the pr= oblem.

However, b) is also discussed in the docume= nt, and browsers could implement their own local policy, e.g., their own de= fault or perhaps a preference to exclusively use Mode 2, regardless of webc= am consent.

Such an approach wouldn't provide = as much nuance as your suggested per-interface permission list, but there a= lready are examples of this (various browser extensions that set the ip-han= dling mode), and I think we can all admit that asking OSes to indicate whic= h interfaces are OK to use for ICE would be a long-term project.
=
If it would help, I could rework the section around the reco= mmended defaults to make it clear that users or browsers could choose not t= o use Mode 1, and/or discuss the defaults and how they relate to a)/b) abov= e.


>
> Explanations about what the IP address is for and how it is used doesn= 't
> matter in this argument. The point is that the user has already agreed=
> to a degree of invasion of privacy that a) is perfectly understandable= ,
> and b) is of significantly more significance than what's being dis= cussed
> here.
>
> Unfortunately the way in which documents depend on each other, and the=
> degree to which it's desirable to have each area of concern be des= cribed
> on its own, make it hard to state this in the document as explicitly a= s
> I do when discussing it.
>
> This thread re-raises an issue that has been hashed over many times, a= nd
> I believe the current draft represents the (rough) consensus of the WG=
> on this matter.

I'm willing to accept that I'm in the rough in terms of how<= br> the WG is using the term "consent."

Nonetheless, if the term can be avoided here, then I still
think that'd be an improvement.

>
>>
>> Even if so, I don't see any reason to make it worse, via this<= br> >> draft, and especially via the quoted text above, so I'd argue<= br> >> that we ought get rid of that concept from this draft.
>>
>> FWIW, I reckon, if implementers liked it, that there is a
>> better answer here which is to provide an interface (API and/or >> UI) that allows selected interfaces to be omitted from ICE.
>
> We have that API offered in Javascript already. It's called "= skipping
> the candidates". But JS API surface helps the JS provider defend = against
> other attackers; it has no benefit when the JS provider *is* the attac= ker.

Right - I wasn't suggesting a JS API but rather one such as
you describe below...

>
> Non-JS-visible APIs discussed have included the ability to specify
> "corporate" TURN servers in browser configs and requiring th= at these be
> used. These are typically out of scope for standards; I haven't se= en
> anything published on whether or not those have been implemented.

Nor have I. I agree that specifying such an API in this draft
wouldn't be right. I don't agree that such an interface ought
be out of scope for standardisation, but do agree that figuring
out where to define one could be tricky.

The interface I have in mind for this case would be something
that'd allow e.g. an operating system UI to state that "tun0
isn't to be used for ICE until I say otherwise" or that'd
allow a VPN client application to call a browser-specific API
of some sort to do the same. I guess even a browser command
line argument could help some - then the folks who care about
this issue could then have a different icon/button/whatever
for starting a browser for webrtc-without-tun0 or whatever.

What this draft could do however, is get rid of the idea of
consent, and define the modes as involving all addresses
except those that are omitted due to local policy, e.g. if
such an interface exists and has been used.

Lastly - the above is only worthwhile if implementers were
likely to provide some way to omit addresses/interfaces
from ICE - if WebRTC clients just weren't ever going to offer
any way to e.g. omit tun0, then there'd be no point in
talking about that. If it was something that could be done
now or in future, then it'd be good to talk about it here
though.

And FWIW, I still consider talk of user consent for ICE as
ridiculous:-)

Cheers,
S.

>
>>
>> S.
>>
>> On 11/02/18 09:00, int= ernet-drafts@ietf.org wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts directories.
>>> This draft is a work item of the Real-Time Communication in WE= B-browsers WG of the IETF.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: WebRTC IP Address Handling Requirements
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Justin Uberti
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Guo-wei Shieh
>>>=C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft= -ietf-rtcweb-ip-handling-05.txt
>>>=C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 10
>>>=C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-02-11
>>>
>>> Abstract:
>>>=C2=A0 =C2=A0 This document provides information and requiremen= ts for how IP
>>>=C2=A0 =C2=A0 addresses should be handled by WebRTC implementat= ions.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf= .org/doc/draft-ietf-rtcweb-ip-handling/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html= /draft-ietf-rtcweb-ip-handling-05
>>> https://datatrack= er.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-05
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-05
>>>
>>>
>>> Please note that it may take a couple of minutes from the time= of submission
>>> until the htmlized version and diff are available at tools.ietf.= org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/rtcweb
>>>
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>>
>
>

--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--089e08245728a9c6e805651e1784-- From nobody Tue Feb 13 12:59:53 2018 Return-Path: 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 5ACA51270AB for ; Tue, 13 Feb 2018 12:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 s6tsO8gudHpV for ; Tue, 13 Feb 2018 12:59:50 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD20412426E for ; Tue, 13 Feb 2018 12:59:49 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id a63so11629799vkg.6 for ; Tue, 13 Feb 2018 12:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GOyoWxRszi1Ns0iVuTPs+IffQNW3SCrWOoZ9d1egzRM=; b=Ddo1nHAHSvstqeQ1OYpgWuJPq4jDNjFgP2SqFpt4ri1bwcPQxilUh24z8WPFVB1gQq 1QqMYnQuhl7vMcASctMeX4UkoaDC0J2TjMEuTg7LlwPaRUvpHebe5KNfj4Qga1uIJeIP GHL+AHiGvtbIqMxSdf4abvn7KwmJklo105JAV2bnnf5RBO5WE7PMUhcfgia3BKbQLGoj PwC9ZSQ9FdM9HzL/St13/4Dv1An0Ubjs0JaFJqYVUFSjuu7krUMBkBp3D4UP4Gxgtzpr Wo+8wSpbBwiZmXqfzGvSWhIrHO5zt+TJuFMpk7Xbex6fNYJqBo776Llyh/h+kR4bGeZh Q8IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GOyoWxRszi1Ns0iVuTPs+IffQNW3SCrWOoZ9d1egzRM=; b=LpM6zfIkEpMFZj8CyugacnA5kiI1jDwx3KY+0rkgIGrgmKyZ1heBAyOpi7xV8w/dEB rWx4UOb67+OC+cInRMF0soC6vKsSr4DaVKlhQASk6OsDCNHr0DO4ppyUZeHl3yaxudS4 QBnyQLOo35ISEg7vWto37uzYyfHEfv/Azff0bPa7t57M4LJWbNd0UNgkw/caH6MzaNgi 5YRtr7Z+UcRS79pJqDohXpmIcRH3rdwhfAPJqThDblATRcUzYi15S5pGDAXtu0Dp29Jh 34fXI1OV8+3q421yEJLY7/vHYZjpUKwTvdE2GVMbmC0WuvShu4pEZEt9FWnpUrqOZmf0 xhvw== X-Gm-Message-State: APf1xPDm+6YBcfGaOGSJ1GalaNuEBPdH1QuE4wfFJXACmGHmy0t/cavH 0LQrM24jfN1I4pkGqcZNfGoJZxFTSPV/L6xB5RQcBw== X-Google-Smtp-Source: AH8x2253m0voxT+kL8LAbxrGw1Yjckn9KpeFJFVIsbG6qqTqCVz4WnM7l+6B80M9YH2ytwCMGfNPXFC4BvO+yqqsAXo= X-Received: by 10.31.190.79 with SMTP id o76mr2463613vkf.12.1518555588161; Tue, 13 Feb 2018 12:59:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.161.142 with HTTP; Tue, 13 Feb 2018 12:59:27 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Tue, 13 Feb 2018 12:59:27 -0800 Message-ID: To: Martin Thomson Cc: "rtcweb@ietf.org" , Bernard Aboba Content-Type: multipart/alternative; boundary="001a114383f0681db105651e4637" Archived-At: Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 20:59:52 -0000 --001a114383f0681db105651e4637 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 11, 2018 at 2:59 PM, Martin Thomson wrote: > Lots more changes there than I expected, most good. > > > When talking about mode 1, you say: "significanly limites the network > information exposed to arbitrary web pages." Aside from the typos > there, I think that this is incorrect. You are talking about mode 1, > which creates maximum exposure. I think that what limits information > is the requirement for explicit permission, but that isn't how the > sentence is constructed. > Yes, that was not my best work. I wanted to make clear that this provides benefits for trusted WebRTC applications (the first half of the sentence), but agree the second half is confusing. I plan to strike everything after the comma, typos and all. > > With the addition of "The recommended defaults are as follows:" that > same text is potentially more misleading. It suggests that mode 1 is > the first choice, which isn't the intent at all. I would revert that > addition. > This was intended to be a segue from enumerating the modes to providing recommendations, but I agree it still feels somewhat awkward - will plan to strike if you don't think a segue is needed. > > The newly added Section 6 seems exclusively about implementation of > the route towards an origin. I think that this goal could be more > explicit (changing the header might help). I also think that it could > be constructed more rationally: > > 1. Goal: The intent is to determine the source address that would be > added to packets that are sent toward the origin. Start by assuming > that UDP and TCP get the same routing. > > 2. Process: Bind a UDP socket to the null address (0.0.0.0 or ::) and > tell the socket to connect to the IP we have previously determined for > the origin. Generally this results in the socket being assigned a > local address based on the host routing table without sending any > packets. The socket can then be queried to determine the local > address. > > 3. Details: Hosts that use a proxy can use the IP address they would > use for connecting to that proxy. For a file:// origin, pick a route > toward an arbitrary IP address. > The intent is actually twofold: 1) How to use OS routing - bind to 0.0.0.0/::. 2) How to figure out the proper source address when binding to 0.0.0.0/:: - do the steps you mention. One option could be to simply split the Implementation Guidance into these two sections, where the body of the second section would be as you describe (and then both would have a descriptive section header). > > "If the client is behind a proxy and cannot resolve the IPs via DNS, > the IPv4/v6 addresses of the proxy can be used instead." (Nit: "IP > addresses") I think that this suggests a different default for clients > that use proxies... > Not quite sure what you meant by different default. > > Nits: > > p2p needs acronym expansion, OS probably too > Agree on p2p; a brief perusal of RFCs seems to indicate that OS as an not-explicitly-defined-acronym is OK. > > On Mon, Feb 12, 2018 at 6:23 AM, Justin Uberti wrote: > > OK, I updated the doc as discussed in this thread. PTAL at > > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 and see if > the > > changes look reasonable. > > > > On Thu, Dec 14, 2017 at 1:32 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> > >> Since I was asked... > >> > >> 1. I think that this might benefit from a mention of the case. You > >> are taking the effort to address the VPN case, but if someone has a > >> public address, this might be a surprise. > >> > >> 2. No specific text necessary here I think. Forcing a proxy should do > >> for this case. It's true that Tor browser doesn't necessarily disable > >> JS and WebRTC, but the forced proxy mode is a reasonable strategy for > >> that case. > >> > >> 3. I agree with you. > >> > >> On Thu, Jul 20, 2017 at 1:45 AM, Justin Uberti > wrote: > >> > Since there will be no WG meeting this week, here are the open issues > >> > for > >> > the document. Feedback on these issues is the only thing standing > >> > between > >> > this document and WGLC. > >> > > >> > 1. https://github.com/juberti/draughts/issues/59 > >> > > >> > In the problem statement, should the paragraph on VPNs mention IP > >> > address > >> > discovery? > >> > > >> > Currently, the problem statement says the following: > >> > > >> > 1. If the client is behind a Network Address Translator (NAT), the > >> > > >> > client's private IP addresses, typically [RFC1918] addresses, > can > >> > > >> > be learned. > >> > > >> > 2. If the client tries to hide its physical location through a > >> > > >> > Virtual Private Network (VPN), and the VPN and local OS support > >> > > >> > routing over multiple interfaces (i.e., a "split-tunnel" VPN), > >> > > >> > WebRTC will discover the public address for the VPN as well as > >> > > >> > the ISP public address that the VPN runs over. > >> > > >> > However, Bernard mentioned that even without split-tunnel support, the > >> > ICE > >> > implementation allows discovery of the VPN private address. I think > this > >> > is > >> > covered by the first paragraph, but perhaps this should be spelled out > >> > further. Thoughts? > >> > > >> > 2. https://github.com/juberti/draughts/issues/60. > >> > > >> > Should supporting WebRTC over Tor be an explicit goal of this document > >> > (and > >> > mentioned in the goals section)? > >> > > >> > This scenario is possible via Mode 4, e.g. force-proxy mode, but it > may > >> > be > >> > out of scope for this document. Bernard mentioned that it may be out > of > >> > scope as Tor distros can disable Javascript, making WebRTC useless, > but > >> > upon > >> > investigation I found that the default Tor bundle does enable > >> > Javascript, > >> > and so this is worth considering. Thoughts? > >> > > >> > 3. https://github.com/juberti/draughts/issues/61 > >> > > >> > Should the document discuss implementation details as it relates to > >> > suggested default behavior? > >> > > >> > The document currently says the following: > >> > > >> > 1. By default, WebRTC should follow normal IP routing rules, to > the > >> > > >> > extent that this is easy to determine (i.e., not considering > >> > > >> > proxies). This can be accomplished by binding local sockets to > >> > > >> > the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which > >> > > >> > allows the OS to route WebRTC traffic the same way as it would > >> > > >> > HTTP traffic, and allows only the 'typical' public addresses to > >> > > >> > be discovered. > >> > > >> > However, Bernard thinks that this text may be making some assumptions, > >> > specifically about whether a strong or weak host model is used. My > >> > thinking > >> > was that spelling out the general implementation approach helps > readers > >> > grok > >> > exactly what this section is getting at, but open to other opinions > >> > here. > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > rtcweb mailing list > >> > rtcweb@ietf.org > >> > https://www.ietf.org/mailman/listinfo/rtcweb > >> > > > > > > --001a114383f0681db105651e4637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 11, 2018 at 2:59 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
Lots mor= e changes there than I expected, most good.


When talking about mode 1, you say: "significanly limites the network<= br> information exposed to arbitrary web pages."=C2=A0 =C2=A0Aside from th= e typos
there, I think that this is incorrect.=C2=A0 You are talking about mode 1,<= br> which creates maximum exposure.=C2=A0 I think that what limits information<= br> is the requirement for explicit permission, but that isn't how the
sentence is constructed.

Yes, that was = not my best work. I wanted to make clear that this provides benefits for tr= usted WebRTC applications (the first half of the sentence), but agree the s= econd half is confusing. I plan to strike everything after the comma, typos= and all.

With the addition of "The recommended defaults are as follows:" t= hat
same text is potentially more misleading.=C2=A0 It suggests that mode 1 is<= br> the first choice, which isn't the intent at all.=C2=A0 I would revert t= hat
addition.

This was intended to be a seg= ue from enumerating the modes to providing recommendations, but I agree it = still feels somewhat awkward - will plan to strike if you don't think a= segue is needed.=C2=A0

The newly added Section 6 seems exclusively about implementation of
the route towards an origin.=C2=A0 I think that this goal could be more
explicit (changing the header might help).=C2=A0 I also think that it could=
be constructed more rationally:

1. Goal: The intent is to determine the source address that would be
added to packets that are sent toward the origin.=C2=A0 Start by assuming that UDP and TCP get the same routing.

2. Process: Bind a UDP socket to the null address (0.0.0.0 or ::) and
tell the socket to connect to the IP we have previously determined for
the origin.=C2=A0 Generally this results in the socket being assigned a
local address based on the host routing table without sending any
packets.=C2=A0 The socket can then be queried to determine the local
address.

3. Details: Hosts that use a proxy can use the IP address they would
use for connecting to that proxy.=C2=A0 For a file:// origin, pick a route<= br> toward an arbitrary IP address.

The int= ent is actually twofold:
1) How to use OS routing - bind to 0.0.0.0/::.
2) How to figure out the = proper source address when binding to 0.0.0.0/<= /a>:: - do the steps you mention.


"If the client is behind a proxy and cannot resolve the IPs via DNS, the IPv4/v6 addresses of the proxy can be used instead."=C2=A0 (Nit: &= quot;IP
addresses") I think that this suggests a different default for clients=
that use proxies...


Nits:

p2p needs acronym expansion, OS probably too

Agree on p2p; a brief perusal of RFCs seems to indicate that OS as an= not-explicitly-defined-acronym is OK.

On Mon, Feb 12, 2018 at 6:23 AM, Justin Uberti <juberti@google.com> wrote:
> OK, I updated the doc as discussed in this thread. PTAL at
> https://tools.ietf.org/html/dr= aft-ietf-rtcweb-ip-handling-05 and see if the
> changes look reasonable.
>
> On Thu, Dec 14, 2017 at 1:32 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> Since I was asked...
>>
>> 1. I think that this might benefit from a mention of the case.=C2= =A0 You
>> are taking the effort to address the VPN case, but if someone has = a
>> public address, this might be a surprise.
>>
>> 2. No specific text necessary here I think.=C2=A0 Forcing a proxy = should do
>> for this case.=C2=A0 It's true that Tor browser doesn't ne= cessarily disable
>> JS and WebRTC, but the forced proxy mode is a reasonable strategy = for
>> that case.
>>
>> 3. I agree with you.
>>
>> On Thu, Jul 20, 2017 at 1:45 AM, Justin Uberti <juberti@google.com> wrote:
>> > Since there will be no WG meeting this week, here are the ope= n issues
>> > for
>> > the document. Feedback on these issues is the only thing stan= ding
>> > between
>> > this document and WGLC.
>> >
>> > 1. https://github.com/juberti/draugh= ts/issues/59
>> >
>> > In the problem statement, should the paragraph on VPNs mentio= n IP
>> > address
>> > discovery?
>> >
>> > Currently, the problem statement says the following:
>> >
>> >=C2=A0 =C2=A0 1.=C2=A0 If the client is behind a Network Addre= ss Translator (NAT), the
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 client's private IP addresses,= typically [RFC1918] addresses, can
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 be learned.
>> >
>> >=C2=A0 =C2=A0 2.=C2=A0 If the client tries to hide its physica= l location through a
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Virtual Private Network (VPN), and= the VPN and local OS support
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 routing over multiple interfaces (= i.e., a "split-tunnel" VPN),
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 WebRTC will discover the public ad= dress for the VPN as well as
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the ISP public address that the VP= N runs over.
>> >
>> > However, Bernard mentioned that even without split-tunnel sup= port, the
>> > ICE
>> > implementation allows discovery of the VPN private address. I= think this
>> > is
>> > covered by the first paragraph, but perhaps this should be sp= elled out
>> > further. Thoughts?
>> >
>> > 2. https://github.com/juberti/draugh= ts/issues/60.
>> >
>> > Should supporting WebRTC over Tor be an explicit goal of this= document
>> > (and
>> > mentioned in the goals section)?
>> >
>> > This scenario is possible via Mode 4, e.g. force-proxy mode, = but it may
>> > be
>> > out of scope for this document. Bernard mentioned that it may= be out of
>> > scope as Tor distros can disable Javascript, making WebRTC us= eless, but
>> > upon
>> > investigation I found that the default Tor bundle does enable=
>> > Javascript,
>> > and so this is worth considering. Thoughts?
>> >
>> > 3. https://github.com/juberti/draugh= ts/issues/61
>> >
>> > Should the document discuss implementation details as it rela= tes to
>> > suggested default behavior?
>> >
>> > The document currently says the following:
>> >
>> >=C2=A0 =C2=A0 =C2=A01.=C2=A0 By default, WebRTC should follow = normal IP routing rules, to the
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 extent that this is easy to determ= ine (i.e., not considering
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxies).=C2=A0 This can be accomp= lished by binding local sockets to
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the wildcard addresses (0.0.0.0 fo= r IPv4, :: for IPv6), which
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 allows the OS to route WebRTC traf= fic the same way as it would
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTP traffic, and allows only the = 'typical' public addresses to
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 be discovered.
>> >
>> > However, Bernard thinks that this text may be making some ass= umptions,
>> > specifically about whether a strong or weak host model is use= d. My
>> > thinking
>> > was that spelling out the general implementation approach hel= ps readers
>> > grok
>> > exactly what this section is getting at, but open to other op= inions
>> > here.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinf= o/rtcweb
>> >
>
>

--001a114383f0681db105651e4637-- From nobody Tue Feb 13 15:05:39 2018 Return-Path: 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 8328D12D94D for ; Tue, 13 Feb 2018 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LdDAANkcLW5n for ; Tue, 13 Feb 2018 15:05:35 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6FF12D835 for ; Tue, 13 Feb 2018 15:05:35 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id e64so18787019ote.4 for ; Tue, 13 Feb 2018 15:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yH+TjR0PzuSuFUDTCib/Kvsn7YCFi0vRWYchESS53pY=; b=bK3gAv092v40NeWaHafwlMJY8tD37y2XA5vd0Jc+7V/TZKsiclI0EqAG50VcMezJKU uuoTbGGhpDIw5oEtw5tPZ3qo9uAEQBTMAW0AlOnFK1MYWWp6Hn5mE1WHRHruwS9JdUxX 4JvrRUQTgSkmnXfm4MntFP2+PNukgopW64Hhxuzbmu3DiC25ujst85zqTKUfJ5kqoIBN mL5TP1Q9DuwPjXubslIni39AqRwofaLiyCQskDa1Y1wlQX4pYjhVLw/Ck2r0AQ7yWXB8 9bSoZbnfeC1LTlMAoPGfBT44tWCol7ICPibLyB1EfRj0cYfnjWt1LDx/3fX6bdX6mhW3 rfmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yH+TjR0PzuSuFUDTCib/Kvsn7YCFi0vRWYchESS53pY=; b=DkQ4/i9x/DAaN3KonDiI4hqN9AawgCkBlktqd4/nOhsEr1OINbKVfL6nlipgyhVTXJ 7NNkwP1lpvPUcBEfdTuHTv9yyeWCYQAHW16oYoOe4fxQ9LWhzMENy3F6AgJwBIDjM2fb 7xH2PtJYE/KHbGlc4HevlQL8i7QWZZsntOu+iuW1J9Sorr5oLG7f2eI0ffnUuYfz6YaQ ZzKujMtjTsu7o6lJVkLiiRQAQ1kV60LVVagrbguyGDlSAdBMdrBtKDBe3CkdjBM3lqfL DyfHM8A3F9RGpqEUrtHIMZ6FI8rkmIY84Gj1Dtz++YiI8PKyDMsLYGGEQasuFJen+xDj 6OQg== X-Gm-Message-State: APf1xPAjYQOoWqr0OD6q5Vbg1A9CAs6G1AJEZRpZASftR2dx6HyqNWWa HxGyueJ+8l2DNFNiEsmGLF7oXMb8eVb2qX/e2XI= X-Google-Smtp-Source: AH8x224fGZLUvSXfhBGcSmve1isngo3IEsqttKXfqAXEM4y5gZlgg5p4TgPbqfrQ44EjSg6/qWFPvQ4H1dlkg4bmqAc= X-Received: by 10.157.54.233 with SMTP id s38mr2118559otd.103.1518563134676; Tue, 13 Feb 2018 15:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Tue, 13 Feb 2018 15:05:34 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 14 Feb 2018 10:05:34 +1100 Message-ID: To: Justin Uberti Cc: "rtcweb@ietf.org" , Bernard Aboba Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 23:05:37 -0000 Looks like you have it in hand. On Wed, Feb 14, 2018 at 7:59 AM, Justin Uberti wrote: > The intent is actually twofold: > 1) How to use OS routing - bind to 0.0.0.0/::. > 2) How to figure out the proper source address when binding to 0.0.0.0/:: - > do the steps you mention. Sounds like a reasonable plan. I'll trust you to get the split right however it works out (one section or two). > One option could be to simply split the Implementation Guidance into these > two sections, where the body of the second section would be as you describe > (and then both would have a descriptive section header). >> >> >> "If the client is behind a proxy and cannot resolve the IPs via DNS, >> the IPv4/v6 addresses of the proxy can be used instead." (Nit: "IP >> addresses") I think that this suggests a different default for clients >> that use proxies... > > > Not quite sure what you meant by different default. Mode 2 as default when a proxy is enabled has the unfortunate effect of requiring that the browser probe the default path to the origin. This text seems to say that if you won't do DNS, or if DNS returns an error, then you probe toward the proxy. Maybe these clients shouldn't even bother using that IP address. Of course, that pushes endpoints behind the same proxy onto relays unnecessarily, so it's crappy either way. 'twas an idle thought only. Pay it no mind. I'm sure that we can each come to our own conclusions about this. From nobody Tue Feb 13 16:45:09 2018 Return-Path: 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 70E9E12DA05 for ; Tue, 13 Feb 2018 16:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 aJDHt9vJqvGa for ; Tue, 13 Feb 2018 16:45:06 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D491200B9 for ; Tue, 13 Feb 2018 16:45:05 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id x203so11916999vkx.10 for ; Tue, 13 Feb 2018 16:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9wNdLluaMzH/2sg8AVMXguVCBpMuOC0p86hCNd6gc9o=; b=n1f11Fhe8j3W2WJiaU6StiHeCst4mATUoA7CFcxL0/inicniZwQtBZ5CTgg5+b8EC3 xFVJmUe5JpfrSTvmLaxxONFhkoBMgK3EVQSOuN1XGjz8HWiWHqoduhXeTopA5O+i1MRy LLah6st3CRqC+4oCQ4tYAtNjw7oVF2x5xczB2KMSu5ekDHgCJYM7X/rk0uAkK/nVwvaq NGlcHz/0lL0fWBfl3yn2bK+TAISWNbTtooC27tFy9K7a8SWH228JMU9NOcsC/aOsXCRw 31i2KOOIONAhoOp+D7WHdRqBbTjHHVm/qLPNSLrx8j7vFnwi5Pg+9Rc6GrJts0X0eRVO ZQYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9wNdLluaMzH/2sg8AVMXguVCBpMuOC0p86hCNd6gc9o=; b=nNVakXqu/p8Q5fV+UxeolrXmgV3zWqEReqxjf5bgnMlGXY9wIYNP3IzzFp1AnazPi2 uw+pIPHwdXQ0k4rgOFGLbpbpIx3Vx7woSmLgpRmM41LnDv679OdNFkZRTo+LpPzpXSm2 fD8nrkerSJp1TBiGwIKBQujDyp99VPULbT9UU1T2vb8gcqexwr2Qm3ucXzqRVZcQSx8E bKuqlrtX81rZhKSblVcozESBMwZGx/jFNHjA428FDEtw5oCXgPZZUhCvIxzvUpqDoYo1 V0NPyEMgbMsVvBJsdnKPA/mxiXr6Rl5GtucL6BqogyUdKIbvOiPLzgZQL/1g6RAgvdYk 5rYw== X-Gm-Message-State: APf1xPDx3o1yOUZ1J3UTdyTiRI1spPmieVu/rMZa9YB697CiWqtGSRNz hFrnmQoMEBnUthDvks3MZHWhbS/NC+8E5GSMPEEBsw== X-Google-Smtp-Source: AH8x227Oal2uwMiw4mdXZvtoufgS3QkVEUHnl6SMf+V9WgXF6rBlVxJU1IlMz84TVHlEjJPvaz78of4lO93nUsAQ4Tc= X-Received: by 10.31.190.79 with SMTP id o76mr2994921vkf.12.1518569104174; Tue, 13 Feb 2018 16:45:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.161.142 with HTTP; Tue, 13 Feb 2018 16:44:43 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Tue, 13 Feb 2018 16:44:43 -0800 Message-ID: To: Martin Thomson Cc: "rtcweb@ietf.org" , Bernard Aboba Content-Type: multipart/alternative; boundary="001a114383f00637fc0565216c7b" Archived-At: Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 14 Feb 2018 00:45:08 -0000 --001a114383f00637fc0565216c7b Content-Type: text/plain; charset="UTF-8" On Tue, Feb 13, 2018 at 3:05 PM, Martin Thomson wrote: > Looks like you have it in hand. > > On Wed, Feb 14, 2018 at 7:59 AM, Justin Uberti wrote: > > The intent is actually twofold: > > 1) How to use OS routing - bind to 0.0.0.0/::. > > 2) How to figure out the proper source address when binding to 0.0.0.0/:: > - > > do the steps you mention. > > Sounds like a reasonable plan. I'll trust you to get the split right > however it works out (one section or two). > OK. Will send a PR for your stamp this week. > > > One option could be to simply split the Implementation Guidance into > these > > two sections, where the body of the second section would be as you > describe > > (and then both would have a descriptive section header). > >> > >> > >> "If the client is behind a proxy and cannot resolve the IPs via DNS, > >> the IPv4/v6 addresses of the proxy can be used instead." (Nit: "IP > >> addresses") I think that this suggests a different default for clients > >> that use proxies... > > > > > > Not quite sure what you meant by different default. > > Mode 2 as default when a proxy is enabled has the unfortunate effect > of requiring that the browser probe the default path to the origin. > This text seems to say that if you won't do DNS, or if DNS returns an > error, then you probe toward the proxy. Maybe these clients shouldn't > even bother using that IP address. Of course, that pushes endpoints > behind the same proxy onto relays unnecessarily, so it's crappy either > way. > > 'twas an idle thought only. Pay it no mind. I'm sure that we can > each come to our own conclusions about this. > --001a114383f00637fc0565216c7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 13, 2018 at 3:05 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
Looks li= ke you have it in hand.

On Wed, Feb 14, 2018 at 7:59 AM, Justin Uberti <juberti@google.com> wrote:
> The intent is actually twofold:
> 1) How to use OS routing - bind to 0.0.0.0/::.
> 2) How to figure out the proper source address when binding to 0.0.0.0/:: -<= br> > do the steps you mention.

Sounds like a reasonable plan.=C2=A0 I'll trust you to get the s= plit right
however it works out (one section or two).

<= div>OK. Will send a PR for your stamp this week.

> One option could be to simply split the Implementation Guidance into t= hese
> two sections, where the body of the second section would be as you des= cribe
> (and then both would have a descriptive section header).
>>
>>
>> "If the client is behind a proxy and cannot resolve the IPs v= ia DNS,
>> the IPv4/v6 addresses of the proxy can be used instead."=C2= =A0 (Nit: "IP
>> addresses") I think that this suggests a different default fo= r clients
>> that use proxies...
>
>
> Not quite sure what you meant by different default.

Mode 2 as default when a proxy is enabled has the unfortunate effect=
of requiring that the browser probe the default path to the origin.
This text seems to say that if you won't do DNS, or if DNS returns an error, then you probe toward the proxy.=C2=A0 Maybe these clients shouldn&#= 39;t
even bother using that IP address.=C2=A0 Of course, that pushes endpoints behind the same proxy onto relays unnecessarily, so it's crappy either<= br> way.

'twas an idle thought only.=C2=A0 Pay it no mind.=C2=A0 I'm sure th= at we can
each come to our own conclusions about this.

--001a114383f00637fc0565216c7b-- From nobody Tue Feb 13 19:06:15 2018 Return-Path: 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 D53ED129511 for ; Tue, 13 Feb 2018 19:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 y6qAYgm9H_jr for ; Tue, 13 Feb 2018 19:06:11 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4DC12708C for ; Tue, 13 Feb 2018 19:06:11 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id u6so6108878qtg.13 for ; Tue, 13 Feb 2018 19:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5AJ1tGjf8E1cn6LfUyfcz7fciEDQpJX1p8eK1imCAss=; b=OyYsYnoHi/mc0MTn1NjcLRETXpjc87R4Aqi6/NN7CHSANnIOMwL24X68Wvm2GsFH0g TfaOFSIIOo+i2IfeFTCNb9GX8BOQSEwd+QUU1gUmhCgjBPEG0P9hazaOkEJSfpOjFy6J jCC/JDeArLwr/csj+a4icET9my5je/lx6NjUU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5AJ1tGjf8E1cn6LfUyfcz7fciEDQpJX1p8eK1imCAss=; b=Jns50CTIrGs1ARaSDpTYL92F1mJGDLI/UxJOke9zZ01pH/9xyO7NkllJceGHpPIQFj 0AlC+XZ9GE2yzqrjYbztc1/5vFTwkmyjw5RwOXkSE2fh13k1Sx2uI3j5E4RL0Wn/Ea+e a5dyIZclzDN2/5M57XiFKNEjS/mLqFUx5CX8CwZH5HA5mSkK2nHwjEFd1g13QvmYyEbf A88IxcuWnWcC4n1zaqL+aoY1O0DeUyk/amVSEr5MoTw+8B0YqtJFkfhe2mhRrU+SGmMX Vb+4Ih3isfktDmIRz7RykWK++6mH03LTtzMd7A91saGqbrCnu7yAcwvAPEtu2ydfdbIq SCog== X-Gm-Message-State: APf1xPDxJBMDXM1XR1NrwW5ixkG5MtDPGcv76y977upTyWx7MfmyU4Oj 3QFkUBBq4gkMSmO4j9S++9ufslSrFHE= X-Google-Smtp-Source: AH8x226VAvYjMskj598itdzpn4sU2OFIB6Y3Z1vptDmlW79Bd2NIwpzo+0R29nAVcpYVlmf0fggAlg== X-Received: by 10.237.50.226 with SMTP id z89mr5352175qtd.290.1518577570626; Tue, 13 Feb 2018 19:06:10 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id d74sm7446040qka.68.2018.02.13.19.06.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 19:06:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Tue, 13 Feb 2018 22:06:06 -0500 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> <5acebff2-364c-45f2-c92a-992ba88f47ef@cs.tcd.ie> To: Justin Uberti , Stephen Farrell X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 14 Feb 2018 03:06:14 -0000 > On Feb 13, 2018, at 15:46, Justin Uberti wrote: >=20 >=20 >=20 > On Mon, Feb 12, 2018 at 3:12 AM, Stephen Farrell = wrote: >=20 > Hiya, >=20 > On 12/02/18 09:26, Harald Alvestrand wrote: > > Den 12. feb. 2018 00:24, skrev Stephen Farrell: > >> > >> I forget if this was explicitly discussed before. Apologies if > >> it was. > >> > >> I consider the following text ridiculous: > >> > >> "Mode 1 MUST only be used when user consent has > >> been provided;" > >> > >> The reason is that it is not possible for all WebRTC users to > >> ever provide real consent to something dealing with which IP > >> addresses are used in ICE. So assuming consent is just BS, as > >> people cannot provide consent to something they do not understand. > >> (And that won't be explained by their systems or s/w.) > >> > >> For me, that means that this draft will appear pretty much as a > >> fig leaf, intended by us technologists to allow us to pretend > >> we're doing the right thing, when we're not. I think that's not > >> really that useful. > >> > >> Is it really too late to try fix the concept of consent that's > >> (ab)used in WebRTC? > > > > I'm sorry, but I don't agree with you on this point. >=20 > Fair enough. >=20 > > > > The decision to go for these modes was based on the theory that if = the > > user has already consented to the near-perfect tracking abilities = that > > are implicit in offering a video stream (tracking camera defects, = for > > instance), and all the information that can be gleaned from a live = audio > > stream, then the idea of protecting the user against tracking by > > restricting access to his IP addresses became of so little value = that it > > was moot and was worth trading away for better performance of the > > functions the user asked for. >=20 > I understand that logic. It does however seem to have caused > issues for at least some people who don't agree that the this > leakage is moot. I'm not claiming that all such claims are > well founded, but I think at least some are. >=20 > So this document tries to address two sets of issues: > a) leakage in contexts when the user is not intentionally using a = WebRTC application > b) leakage in contexts when the user is intentionally using a WebRTC = application >=20 > The 'consent' discussion is focused around a), with the result being = that the ISP address will not be provided when using a VPN unless the = user has consented to use of their camera. The WG went back and forth = and came to a rough consensus on this being a reasonable solution to the = problem. >=20 > However, b) is also discussed in the document, and browsers could = implement their own local policy, e.g., their own default or perhaps a = preference to exclusively use Mode 2, regardless of webcam consent. >=20 > Such an approach wouldn't provide as much nuance as your suggested = per-interface permission list, but there already are examples of this = (various browser extensions that set the ip-handling mode), and I think = we can all admit that asking OSes to indicate which interfaces are OK to = use for ICE would be a long-term project. >=20 > If it would help, I could rework the section around the recommended = defaults to make it clear that users or browsers could choose not to use = Mode 1, and/or discuss the defaults and how they relate to a)/b) above. Justin: Since you offered ;) Go ahead and take a stab at it. Everybody: Hoping this won=E2=80=99t be too controversial since it = appeared that we were getting very close to being done with this draft. > > Explanations about what the IP address is for and how it is used = doesn't > > matter in this argument. The point is that the user has already = agreed > > to a degree of invasion of privacy that a) is perfectly = understandable, > > and b) is of significantly more significance than what's being = discussed > > here. > > > > Unfortunately the way in which documents depend on each other, and = the > > degree to which it's desirable to have each area of concern be = described > > on its own, make it hard to state this in the document as explicitly = as > > I do when discussing it. > > > > This thread re-raises an issue that has been hashed over many times, = and > > I believe the current draft represents the (rough) consensus of the = WG > > on this matter. >=20 > I'm willing to accept that I'm in the rough in terms of how > the WG is using the term "consent." >=20 > Nonetheless, if the term can be avoided here, then I still > think that'd be an improvement. Stephen: The only thing I=E2=80=99d add to Harald's point is that this = draft hasn=E2=80=99t yet been through WGLC, but the draft has basically = had the same recommendations since before it was a WG draft (the draft = was adopted about two years ago). Namely, Mode 1 (enumerate all = addresses) is recommended only if the user has done something explicit = else Mode 2 (default route + associated local addresses) is recommended. = While Justin might be reworking the section around the recommended = defaults, I don=E2=80=99t think the recommended defaults are going to = change (unless of course there=E2=80=99s a pretty substantial outcry = that=E2=80=99s going to upset what appeared to be the emerging rough = consensus). spt= From nobody Wed Feb 14 04:59:09 2018 Return-Path: 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 829B1124234 for ; Wed, 14 Feb 2018 04:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 2JVsicE-4vY2 for ; Wed, 14 Feb 2018 04:59:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF93124D37 for ; Wed, 14 Feb 2018 04:58:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 90359BE5D; Wed, 14 Feb 2018 12:58:56 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZtSLGX73TqL; Wed, 14 Feb 2018 12:58:56 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3DF72BDF9; Wed, 14 Feb 2018 12:58:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518613136; bh=+2hRV/zAP9gnmFA14rpatnDOmlGsezSi4v4t0dWkvgY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Dmwz3UGnVKaq71Su4ENVnVZJd7ILSgsjtHPYNPhOxARrTkmjNYZM2VpxeD4pFop7c v/fsjzGvvxaUTWfrTDq6HzVg/erObJuJ39Rh5h8+IEqwOOwd5bjusIWW8Vo6OU9GVT jIehYafwNawKjaFDOuLial/MwSFrFhfQyGK/IV/I= To: Sean Turner , Justin Uberti Cc: RTCWeb IETF References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> <5acebff2-364c-45f2-c92a-992ba88f47ef@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Wed, 14 Feb 2018 12:58:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jEXYqkZNaqh8QEaxNgHp4CT6y8uc26VR7" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 14 Feb 2018 12:59:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jEXYqkZNaqh8QEaxNgHp4CT6y8uc26VR7 Content-Type: multipart/mixed; boundary="edM95YALllexqoKrh85tQ3T9U72TLNYOO"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , Justin Uberti Cc: RTCWeb IETF Message-ID: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> <5acebff2-364c-45f2-c92a-992ba88f47ef@cs.tcd.ie> In-Reply-To: --edM95YALllexqoKrh85tQ3T9U72TLNYOO Content-Type: multipart/mixed; boundary="------------1401A275331B1F5B48F3829B" Content-Language: en-GB This is a multi-part message in MIME format. --------------1401A275331B1F5B48F3829B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 14/02/18 03:06, Sean Turner wrote: > Stephen: The only thing I=E2=80=99d add to Harald's point is that this = draft > hasn=E2=80=99t yet been through WGLC, but the draft has basically had t= he > same recommendations since before it was a WG draft (the draft was > adopted about two years ago). Namely, Mode 1 (enumerate all > addresses) is recommended only if the user has done something > explicit else Mode 2 (default route + associated local addresses) is > recommended. While Justin might be reworking the section around the > recommended defaults, I don=E2=80=99t think the recommended defaults ar= e > going to change (unless of course there=E2=80=99s a pretty substantial = outcry > that=E2=80=99s going to upset what appeared to be the emerging rough > consensus). Sure, I do get that I'm likely in the rough here, so I won't keep on arguing about it, esp if others aren't. I'll just leave it as this: IMO the use of the term consent in the web generally is broken and has been mis-used by web sites in various ways. I'm sad that we're seeming to join in that, even if only a little, and I continue to think that if we could remove the term from this draft, that'd improve the draft. I do agree that the camera/mic "ok, and remember that" is an understandable signal for a person who's involved in making a (set of) call(s) with/via a web site that uses https. I do not agree that anybody will understand that that means that the origin in question can subsequently expose addresses via ICE when no calls are being made (from the user POV), so I do not agree with the WG consensus that leveraging the camera/mic signal is a good choice here. I also do accept that there is a lack of other good choices and I've also already said that I don't think the address exposure is gigantic flaw, but that there are non-crazy people who think it's bad. Cheers, S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------1401A275331B1F5B48F3829B Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------1401A275331B1F5B48F3829B-- --edM95YALllexqoKrh85tQ3T9U72TLNYOO-- --jEXYqkZNaqh8QEaxNgHp4CT6y8uc26VR7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJahDKPAAoJEFqy+vF7FyvqQJQQAK0fUqEDJe2MLiUAEj1Cl8r+ 7b/Kuas1JwHDbutXsiwkJfHOEEPuDobsGKmDVhc27BGTOzExa1csb4bC0FSbf6r1 BI8yRGEWXZynD1n0Q7fg82kE6BPp5F9/QJAzCuPFpCKmSjraJqZv3BZYEyPVYgjb fsSVQd991BQ4Bm0DXl2csGaOdfNNXeZl00MBVDC00x8fbrj9ackE4rgj+DNQI/ED kNq/iAdlHospiXmGrAq3Xsil6unE93LpGoIvym2bgyyPnng1Ye28Ky8Nm6S+ZDJl n/P3LU4UwTYMaGpxPflurw9RGWUC7vqJh8G+oJYHavLpV19VGh6avVabVPER3oCT vj8bCxSEEWPJ8WGFTAWWSF09ZiJ4xDd+EFheA1i8tCqOw5hI/Gc7uIqOroeaalvZ n63JaK3oW1vfVv27h0gJ88NDJhcj19wegHnJ8lvpJm9ywRxzDENjNqx2gp+VVEnv Jixl2gBUDe6ENXhivRZcbo6Xxh6j9PxC1XFrl0gN7oUp3JIdN7geC1S6lfsZAAJE 3PpV2mYT8op3j5YzpkdYb2XK9QRXfUxiaDNTxd115FJfX8c1FDe0Fz7HLMfTFY72 eAaeXy4WT1uq+B2UVC5xkInT9OS4vX/PgOkDrQQvahmWsix7yzMliy45dQvBHj/S Ig/8ag7bjAGSzAyizEga =Gu/a -----END PGP SIGNATURE----- --jEXYqkZNaqh8QEaxNgHp4CT6y8uc26VR7-- From nobody Mon Feb 26 22:54:25 2018 Return-Path: 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 C72A6124BAC for ; Mon, 26 Feb 2018 22:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 D0o7_iPV6xXl for ; Mon, 26 Feb 2018 22:54:20 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A611243F3 for ; Mon, 26 Feb 2018 22:54:20 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id x125so11520256vkc.13 for ; Mon, 26 Feb 2018 22:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2EuAEGq/vesvP2lV3g0gV3BocC7OvURM/gOKQklvc0A=; b=gdXmpFpJlfxlQPdsgkv2J5/wjkcaxepnhlNX7RupOpfKiP8/JVkvC3ZbUqiC0rRF8V KoU6H4u5zNalr/hBQrvH/7Dl0ofUO69ve0Oobp0opDi3neH970pGbnLMsvyUtWlt/ZZb w8+qO8zyBcuaUND8EchRcT1LB+gMVeDehk1t0w8nVOf6oZ9wMr4GFqmtjznSusKqy55A 97phDgBRUwgFEBWPuJBon5eOxJM2ydL8uJxBiqi+ZQyabCmHfxbBv4uFgghjVatc2A0U +CNctyRzswA2dAEcLkDJ0H9R7GiHQBc9pHg3tvD/bYGJAz/CYdpX3gc4x5YG95gMEAkN DvOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2EuAEGq/vesvP2lV3g0gV3BocC7OvURM/gOKQklvc0A=; b=f4pvqpSw7HOXBLz+7CL+lmzNT2/UkLmZ98urz3rU+bDxfcRinBvSkibNVVmoMj25eX k5vhSbgGyeaFsKGknYmXTrrvxf0SAjCRHVjhXJ3qFNFTMhfwLrmswFZPZzENaO6Wl34s OCbOaec+oLTUDB4ltApWRnaWC82kqtx/4rxPglcJ0iBvBC/O9Ou+rzDzcptwGk9f7R30 qvD15Q27UWHzqC/ZchnpPDD8vYjn+neZWO47FXsVOoESpXUEH64Ww02e5Y2Lcth90Xsu u31FpKW0zrLttttPkEJCX0QCAgcsQnooP3UyD3+ZzS41Ffd83hYBAzxs3i3UOAe/01yJ NyCw== X-Gm-Message-State: APf1xPD272LGg0Xbhj1TpZwV/QqsdyUjuvX7okwYxNMnfjJH28YesVKz JLUdDnh9lnG/n6oGG7jH99bMB6eHid/UtdTfh+3muv48g5s= X-Google-Smtp-Source: AG47ELvv3spFM0LQgdh10QoX9AvP0b35Kx6cHLaWRrbHcAEMqJPVCZtapXeJnZ6JxF1i+n2vTODP75iHDcNWipEBMEM= X-Received: by 10.31.208.7 with SMTP id h7mr9926367vkg.71.1519714458683; Mon, 26 Feb 2018 22:54:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Mon, 26 Feb 2018 22:53:58 -0800 (PST) In-Reply-To: References: <151833965150.17077.13014329219354900316@ietfa.amsl.com> <1a280595-e04d-33af-2cfc-454563131481@alvestrand.no> <5acebff2-364c-45f2-c92a-992ba88f47ef@cs.tcd.ie> From: Justin Uberti Date: Mon, 26 Feb 2018 22:53:58 -0800 Message-ID: To: Sean Turner Cc: Stephen Farrell , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a114bcaa079241f05662c1855" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-05.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 06:54:24 -0000 --001a114bcaa079241f05662c1855 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable PTAL at https://github.com/juberti/draughts/pull/96, which tries to explain that implementations may choose different defaults a bit more clearly. On Tue, Feb 13, 2018 at 7:06 PM, Sean Turner wrote: > > > > On Feb 13, 2018, at 15:46, Justin Uberti wrote: > > > > > > > > On Mon, Feb 12, 2018 at 3:12 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > > > > Hiya, > > > > On 12/02/18 09:26, Harald Alvestrand wrote: > > > Den 12. feb. 2018 00:24, skrev Stephen Farrell: > > >> > > >> I forget if this was explicitly discussed before. Apologies if > > >> it was. > > >> > > >> I consider the following text ridiculous: > > >> > > >> "Mode 1 MUST only be used when user consent has > > >> been provided;" > > >> > > >> The reason is that it is not possible for all WebRTC users to > > >> ever provide real consent to something dealing with which IP > > >> addresses are used in ICE. So assuming consent is just BS, as > > >> people cannot provide consent to something they do not understand. > > >> (And that won't be explained by their systems or s/w.) > > >> > > >> For me, that means that this draft will appear pretty much as a > > >> fig leaf, intended by us technologists to allow us to pretend > > >> we're doing the right thing, when we're not. I think that's not > > >> really that useful. > > >> > > >> Is it really too late to try fix the concept of consent that's > > >> (ab)used in WebRTC? > > > > > > I'm sorry, but I don't agree with you on this point. > > > > Fair enough. > > > > > > > > The decision to go for these modes was based on the theory that if th= e > > > user has already consented to the near-perfect tracking abilities tha= t > > > are implicit in offering a video stream (tracking camera defects, for > > > instance), and all the information that can be gleaned from a live > audio > > > stream, then the idea of protecting the user against tracking by > > > restricting access to his IP addresses became of so little value that > it > > > was moot and was worth trading away for better performance of the > > > functions the user asked for. > > > > I understand that logic. It does however seem to have caused > > issues for at least some people who don't agree that the this > > leakage is moot. I'm not claiming that all such claims are > > well founded, but I think at least some are. > > > > So this document tries to address two sets of issues: > > a) leakage in contexts when the user is not intentionally using a WebRT= C > application > > b) leakage in contexts when the user is intentionally using a WebRTC > application > > > > The 'consent' discussion is focused around a), with the result being > that the ISP address will not be provided when using a VPN unless the use= r > has consented to use of their camera. The WG went back and forth and came > to a rough consensus on this being a reasonable solution to the problem. > > > > However, b) is also discussed in the document, and browsers could > implement their own local policy, e.g., their own default or perhaps a > preference to exclusively use Mode 2, regardless of webcam consent. > > > > Such an approach wouldn't provide as much nuance as your suggested > per-interface permission list, but there already are examples of this > (various browser extensions that set the ip-handling mode), and I think w= e > can all admit that asking OSes to indicate which interfaces are OK to use > for ICE would be a long-term project. > > > > If it would help, I could rework the section around the recommended > defaults to make it clear that users or browsers could choose not to use > Mode 1, and/or discuss the defaults and how they relate to a)/b) above. > > Justin: Since you offered ;) Go ahead and take a stab at it. > > Everybody: Hoping this won=E2=80=99t be too controversial since it appear= ed that > we were getting very close to being done with this draft. > > > > Explanations about what the IP address is for and how it is used > doesn't > > > matter in this argument. The point is that the user has already agree= d > > > to a degree of invasion of privacy that a) is perfectly understandabl= e, > > > and b) is of significantly more significance than what's being > discussed > > > here. > > > > > > Unfortunately the way in which documents depend on each other, and th= e > > > degree to which it's desirable to have each area of concern be > described > > > on its own, make it hard to state this in the document as explicitly = as > > > I do when discussing it. > > > > > > This thread re-raises an issue that has been hashed over many times, > and > > > I believe the current draft represents the (rough) consensus of the W= G > > > on this matter. > > > > I'm willing to accept that I'm in the rough in terms of how > > the WG is using the term "consent." > > > > Nonetheless, if the term can be avoided here, then I still > > think that'd be an improvement. > > Stephen: The only thing I=E2=80=99d add to Harald's point is that this dr= aft > hasn=E2=80=99t yet been through WGLC, but the draft has basically had the= same > recommendations since before it was a WG draft (the draft was adopted abo= ut > two years ago). Namely, Mode 1 (enumerate all addresses) is recommended > only if the user has done something explicit else Mode 2 (default route + > associated local addresses) is recommended. While Justin might be > reworking the section around the recommended defaults, I don=E2=80=99t th= ink the > recommended defaults are going to change (unless of course there=E2=80=99= s a pretty > substantial outcry that=E2=80=99s going to upset what appeared to be the = emerging > rough consensus). > > spt --001a114bcaa079241f05662c1855 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PTAL at=C2=A0https://github.com/juberti/draughts/pull/96, which tries to = explain that implementations may choose different defaults a bit more clear= ly.

On Tue, = Feb 13, 2018 at 7:06 PM, Sean Turner <sean@sn3rd.com> wrote:

> On Feb 13, 2018, at 15:46, Justin Uberti <juberti@google.com> wrote:
>
>
>
> On Mon, Feb 12, 2018 at 3:12 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
> Hiya,
>
> On 12/02/18 09:26, Harald Alvestrand wrote:
> > Den 12. feb. 2018 00:24, skrev Stephen Farrell:
> >>
> >> I forget if this was explicitly discussed before. Apologies i= f
> >> it was.
> >>
> >> I consider the following text ridiculous:
> >>
> >>=C2=A0 =C2=A0 "Mode 1 MUST only be used when user consent= has
> >>=C2=A0 =C2=A0 =C2=A0been provided;"
> >>
> >> The reason is that it is not possible for all WebRTC users to=
> >> ever provide real consent to something dealing with which IP<= br> > >> addresses are used in ICE. So assuming consent is just BS, as=
> >> people cannot provide consent to something they do not unders= tand.
> >> (And that won't be explained by their systems or s/w.) > >>
> >> For me, that means that this draft will appear pretty much as= a
> >> fig leaf, intended by us technologists to allow us to pretend=
> >> we're doing the right thing, when we're not. I think = that's not
> >> really that useful.
> >>
> >> Is it really too late to try fix the concept of consent that&= #39;s
> >> (ab)used in WebRTC?
> >
> > I'm sorry, but I don't agree with you on this point.
>
> Fair enough.
>
> >
> > The decision to go for these modes was based on the theory that i= f the
> > user has already consented to the near-perfect tracking abilities= that
> > are implicit in offering a video stream (tracking camera defects,= for
> > instance), and all the information that can be gleaned from a liv= e audio
> > stream, then the idea of protecting the user against tracking by<= br> > > restricting access to his IP addresses became of so little value = that it
> > was moot and was worth trading away for better performance of the=
> > functions the user asked for.
>
> I understand that logic. It does however seem to have caused
> issues for at least some people who don't agree that the this
> leakage is moot. I'm not claiming that all such claims are
> well founded, but I think at least some are.
>
> So this document tries to address two sets of issues:
> a) leakage in contexts when the user is not intentionally using a WebR= TC application
> b) leakage in contexts when the user is intentionally using a WebRTC a= pplication
>
> The 'consent' discussion is focused around a), with the result= being that the ISP address will not be provided when using a VPN unless th= e user has consented to use of their camera. The WG went back and forth and= came to a rough consensus on this being a reasonable solution to the probl= em.
>
> However, b) is also discussed in the document, and browsers could impl= ement their own local policy, e.g., their own default or perhaps a preferen= ce to exclusively use Mode 2, regardless of webcam consent.
>
> Such an approach wouldn't provide as much nuance as your suggested= per-interface permission list, but there already are examples of this (var= ious browser extensions that set the ip-handling mode), and I think we can = all admit that asking OSes to indicate which interfaces are OK to use for I= CE would be a long-term project.
>
> If it would help, I could rework the section around the recommended de= faults to make it clear that users or browsers could choose not to use Mode= 1, and/or discuss the defaults and how they relate to a)/b) above.

Justin: Since you offered ;) Go ahead and take a stab at it.
Everybody: Hoping this won=E2=80=99t be too controversial since it appeared= that we were getting very close to being done with this draft.

> > Explanations about what the IP address is for and how it is used = doesn't
> > matter in this argument. The point is that the user has already a= greed
> > to a degree of invasion of privacy that a) is perfectly understan= dable,
> > and b) is of significantly more significance than what's bein= g discussed
> > here.
> >
> > Unfortunately the way in which documents depend on each other, an= d the
> > degree to which it's desirable to have each area of concern b= e described
> > on its own, make it hard to state this in the document as explici= tly as
> > I do when discussing it.
> >
> > This thread re-raises an issue that has been hashed over many tim= es, and
> > I believe the current draft represents the (rough) consensus of t= he WG
> > on this matter.
>
> I'm willing to accept that I'm in the rough in terms of how > the WG is using the term "consent."
>
> Nonetheless, if the term can be avoided here, then I still
> think that'd be an improvement.

Stephen: The only thing I=E2=80=99d add to Harald's point is tha= t this draft hasn=E2=80=99t yet been through WGLC, but the draft has basica= lly had the same recommendations since before it was a WG draft (the draft = was adopted about two years ago).=C2=A0 Namely, Mode 1 (enumerate all addre= sses) is recommended only if the user has done something explicit else Mode= 2 (default route + associated local addresses) is recommended.=C2=A0 While= Justin might be reworking the section around the recommended defaults, I d= on=E2=80=99t think the recommended defaults are going to change (unless of = course there=E2=80=99s a pretty substantial outcry that=E2=80=99s going to = upset what appeared to be the emerging rough consensus).

spt

--001a114bcaa079241f05662c1855-- From nobody Mon Feb 26 22:57:13 2018 Return-Path: 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 689361274D2 for ; Mon, 26 Feb 2018 22:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 5Bx_ey8OspCH for ; Mon, 26 Feb 2018 22:57:09 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AEBB124B18 for ; Mon, 26 Feb 2018 22:57:09 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id b13so7500193uam.10 for ; Mon, 26 Feb 2018 22:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UIR1bxjlhZ12uNDPOOawjzQ2Cnn/NEoRCGE5e/+5rXs=; b=YwP36bMwaAA33hxfXf5zQKNUN8e+qZnqoVp9Ir3/LYp7rcf0F/JghaL243cWuil3pB 20K0ebTh+kzFTiejewDkX3OlLl9WDsnGXqIqSl4/o5hyjhQ5yfZZiaI/SkoJhazpjQzx QnCDzBYduek03vCDcLKu8A4Fv1LYNVwzOaTNVKOYH5MxN7+m8P6oZ5UH4Hwk0DESteBa KtekHLUunsFB2bcbIJ9rzi1qQhkzLa0hGk7v2TLLZA0OUej764s0XozDm4bOSDn9IYdZ KL4yREHORj6g7hAiZ18nqKj5Qo7AIFOuxPsFtOuJnvKKJmY8v8addse4ur5uh5Pz/L3S 42OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UIR1bxjlhZ12uNDPOOawjzQ2Cnn/NEoRCGE5e/+5rXs=; b=kTsYZ2n/gN1o3/Pnf0Zu9skASRaGQLARSHc9Cz3PqvRtAsxcbkjCrtWjhSae8zSM26 ZiZ5bigxoYzj+rmXQVlh00WSKiqc02xHTkJRTo7RugNLC7JdICNaIjJMkbh5K9uM0xf7 Ydc1L1naXDoKOP6EQeQ7/Rqp2rh0mhqw2lC+Rr9IKn1GT7vusFQeLAibqmeD2cn8S5p+ e6YNFSUXAr2t1k9on2thJ0M3oE41cv6eC9u2cwVDyQsH0YqsE1Nf3zVAPd8IrWDwn49p kYjGGxi4h8+czYFZCvpoTD868m2eEelvORRgKjyAYxQWo49Jzt4DYNYipIUvfkZ33gAO mN3w== X-Gm-Message-State: APf1xPDyIUEVXBIHiE6R/D7mgk1ketfJsmWCTS65+ICVd5rS0RJ6hAiC ANH8sUB8nLD4xxEEV167Hju2ArTpryjsBwahaBcGgdYMXtY= X-Google-Smtp-Source: AG47ELvm3BVQX7H/34XVOsWX3jZPXVqFLox8DMGFSZ+AKtBNI14yt5rJVpWdWIkGS1C2Syhq8n6zHLytP/fEbZ442hE= X-Received: by 10.159.56.209 with SMTP id w17mr5266013uaf.108.1519714627928; Mon, 26 Feb 2018 22:57:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.206 with HTTP; Mon, 26 Feb 2018 22:56:47 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Mon, 26 Feb 2018 22:56:47 -0800 Message-ID: To: Martin Thomson Cc: "rtcweb@ietf.org" , Bernard Aboba Content-Type: multipart/alternative; boundary="f403045f38de8f604805662c2246" Archived-At: Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 06:57:11 -0000 --f403045f38de8f604805662c2246 Content-Type: text/plain; charset="UTF-8" https://github.com/juberti/draughts/pull/96 On Tue, Feb 13, 2018 at 4:44 PM, Justin Uberti wrote: > > > On Tue, Feb 13, 2018 at 3:05 PM, Martin Thomson > wrote: > >> Looks like you have it in hand. >> >> On Wed, Feb 14, 2018 at 7:59 AM, Justin Uberti >> wrote: >> > The intent is actually twofold: >> > 1) How to use OS routing - bind to 0.0.0.0/::. >> > 2) How to figure out the proper source address when binding to 0.0.0.0/:: >> - >> > do the steps you mention. >> >> Sounds like a reasonable plan. I'll trust you to get the split right >> however it works out (one section or two). >> > > OK. Will send a PR for your stamp this week. > >> >> > One option could be to simply split the Implementation Guidance into >> these >> > two sections, where the body of the second section would be as you >> describe >> > (and then both would have a descriptive section header). >> >> >> >> >> >> "If the client is behind a proxy and cannot resolve the IPs via DNS, >> >> the IPv4/v6 addresses of the proxy can be used instead." (Nit: "IP >> >> addresses") I think that this suggests a different default for clients >> >> that use proxies... >> > >> > >> > Not quite sure what you meant by different default. >> >> Mode 2 as default when a proxy is enabled has the unfortunate effect >> of requiring that the browser probe the default path to the origin. >> This text seems to say that if you won't do DNS, or if DNS returns an >> error, then you probe toward the proxy. Maybe these clients shouldn't >> even bother using that IP address. Of course, that pushes endpoints >> behind the same proxy onto relays unnecessarily, so it's crappy either >> way. >> >> 'twas an idle thought only. Pay it no mind. I'm sure that we can >> each come to our own conclusions about this. >> > > --f403045f38de8f604805662c2246 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Feb 13, 2018 at 4:44 PM, Just= in Uberti <juberti@google.com> wrote:


On Tue, Feb 13, 2018 at 3:05 PM, Martin = Thomson <martin.thomson@gmail.com> wrote:
Looks like you have it in hand.

On Wed, Feb 14, 2018 at 7:59 AM, Justin Uberti <juberti@google.com> wrote:
> The intent is actually twofold:
> 1) How to use OS routing - bind to 0.0.0.0/::.
> 2) How to figure out the proper source address when binding to 0.0.0.0/:: -<= br> > do the steps you mention.

Sounds like a reasonable plan.=C2=A0 I'll trust you to get the s= plit right
however it works out (one section or two).

<= /span>
OK. Will send a PR for your stamp this week.

> One option could be to simply split the Implementation Guidance into t= hese
> two sections, where the body of the second section would be as you des= cribe
> (and then both would have a descriptive section header).
>>
>>
>> "If the client is behind a proxy and cannot resolve the IPs v= ia DNS,
>> the IPv4/v6 addresses of the proxy can be used instead."=C2= =A0 (Nit: "IP
>> addresses") I think that this suggests a different default fo= r clients
>> that use proxies...
>
>
> Not quite sure what you meant by different default.

Mode 2 as default when a proxy is enabled has the unfortunate effect=
of requiring that the browser probe the default path to the origin.
This text seems to say that if you won't do DNS, or if DNS returns an error, then you probe toward the proxy.=C2=A0 Maybe these clients shouldn&#= 39;t
even bother using that IP address.=C2=A0 Of course, that pushes endpoints behind the same proxy onto relays unnecessarily, so it's crappy either<= br> way.

'twas an idle thought only.=C2=A0 Pay it no mind.=C2=A0 I'm sure th= at we can
each come to our own conclusions about this.


--f403045f38de8f604805662c2246-- From nobody Tue Feb 27 08:54:26 2018 Return-Path: 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 0B5B8126DFB for ; Tue, 27 Feb 2018 08:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aCzRbsPR1n4v for ; Tue, 27 Feb 2018 08:54:20 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CD01200E5 for ; Tue, 27 Feb 2018 08:54:20 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id l43so25624424wrc.2 for ; Tue, 27 Feb 2018 08:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=aCiiFkfihyLYhvNg2oAtWdQte8QoCi3zt0GSRdUMFVk=; b=bGLfv3OjXNG7bJFLyyntKJG9yzN9uqK3RBdx9OWwHfBh2r+QDBf4NFW/MHB0mQ9s57 h+0BcXMfFpPkdzzsfjmQa29KQizkO6sH2FkBlaht0FLNYrWEf7HS048lVdnnfAEuZby7 QFQJWFm8IoX8sI2s/mKbDK09Sj75T1afqHhVK1URPCJwUb5hsHUjK/F42mWiBvOh/o9l vqg6LytkXWtMOVKBFGcSCuUKiI4x1K551ixDfozG1vzY1cxoqBbuRORBWGMP6MEje45F 929v5Uai6iH2LwUiZGfXGkHIjaJ4Edys687nAKRQ3NmUeeSnQfbwnfz1baavTKUvpADm 7U0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=aCiiFkfihyLYhvNg2oAtWdQte8QoCi3zt0GSRdUMFVk=; b=Cx8NKe6EVZhBCEaeZjOqJhp5alaoagdgeF1eIiv6Zmq/x77krjtIRKbtrewCMkFyH7 zT0U8LP18LG4pVvFUrPO5V+C7Nbjk98pDLgMmbQRYV/aQ5N/CIzlo5n+NTKuxhQEo7Tw tRR8iMciM4GZR/y4trNg1fG3Lz12Cy7v7MUlwhbQ0kCA6v2QbVilIT9UB3FYfOFNazMK uCY1jamSWwCA2V/HW0s4W61Q2amRhysNIutS74qQ71eLQZ1/aAer4ljWEj5jKPn7hq7U nevNfpmClWKSzP16pdm2YpQFdY/xwWUM+PKm2Wu0WtfHewmAaTOBSyb4ahJB0c35WMfy XftA== X-Gm-Message-State: APf1xPCp+osrg5nDTPhh0M4ZPHNowb57cbo98hXTHME5WS5nekLl6ZIS LxBhRr46HejwPmIV9uInqs5d5N6Y X-Google-Smtp-Source: AH8x2267RuBmBlhXBsFCiMswM/TMcpIxyssSAV6jcQLhGqZwPoXZ7bAYTUiCs+AeS7VlzmCu/Dv88g== X-Received: by 10.223.191.10 with SMTP id p10mr14228222wrh.160.1519750458492; Tue, 27 Feb 2018 08:54:18 -0800 (PST) Received: from [192.168.0.117] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id t141sm16852732wmd.34.2018.02.27.08.54.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 08:54:17 -0800 (PST) To: discuss-webrtc , "public-webrtc@w3.org" , "rtcweb@ietf.org" From: Sergio Garcia Murillo Message-ID: <61db5e94-a500-6d62-ed8b-78c1ae2bad0a@gmail.com> Date: Tue, 27 Feb 2018 17:54:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------25863338B86AE1CA652962B1" Content-Language: en-US Archived-At: Subject: [rtcweb] Result of the first webrtc developers survey X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 16:54:23 -0000 This is a multi-part message in MIME format. --------------25863338B86AE1CA652962B1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, Finally, there have been 215 responses to the webrtc developers survey, so thank you all for participating! As promised, here are the google form analytics of the survey: * https://docs.google.com/forms/d/1YVKqVU_ziCYtp8RGGnwB8WcQWDhkXe-mOmaSkFTdJm8/viewanalytics * https://docs.google.com/forms/d/e/1FAIpQLSeMdJpUS911lLmeAOsC3wdRpDzoDNZik-7LmrrkjzKPFgkgbw/viewanalytics (Japanese version) And the raw results, just in case someone wants to do a more in deep analysis: * https://docs.google.com/spreadsheets/d/15k5cjwtiF1gekT9K1fY0iQs_B7E3_oLjnMZUYq3Jy2Y/edit?usp=sharing Best regards Sergio P.S. Most probably a coincidence, but the Standard C++ Foundation opened its "first-ever global C++ developer survey" which results will be "shared with the C++ standardization committee to help inform C++ evolution", so in case you area also a c++ developer (which seems the case based on our survey results), please participate! https://www.surveymonkey.com/r/5WWVVS2 --------------25863338B86AE1CA652962B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

Finally, there have been 215 responses to the webrtc developers survey, so thank you all for participating!

As promised, here are the google form analytics of the survey:

And the raw results, just in case someone wants to do a more in deep analysis:

Best regards
Sergio

P.S. Most probably a coincidence, but the Standard C++ Foundation opened its "first-ever global C++ developer survey" which results will be "shared with the C++ standardization committee to help inform C++ evolution", so in case you area also a c++ developer (which seems the case based on our survey results), please participate!

https://www.surveymonkey.com/r/5WWVVS2

--------------25863338B86AE1CA652962B1--