Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

Justin Uberti <juberti@google.com> Thu, 29 March 2018 21:21 UTC

Return-Path: <juberti@google.com>
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 CCDC8126D05 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2018 14:21:46 -0700 (PDT)
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 UOAjKlParuiH for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2018 14:21:37 -0700 (PDT)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 D502712EA24 for <rtcweb@ietf.org>; Thu, 29 Mar 2018 14:21:22 -0700 (PDT)
Received: by mail-ua0-x22e.google.com with SMTP id s92so4429223uas.11 for <rtcweb@ietf.org>; Thu, 29 Mar 2018 14:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JuV3yzlO91MJh7E/CIVSXLkh5AgwfK5APE+Hx3d+Lok=; b=M/lcZx6DmEKfQCN/OG3HDnJCWbHc/HbBgNzdXuDmVweF6xhp/q11J2mEBMPOWQNRaf GLfsrjhoJxNm8VaZVK2Ku2qPMK+rYpu3Z7D+pnQYvPLjHMQehShuagoMMAp+aKldqgV3 rdXto1NrdfirFxul7OjSPp5N8xxxnjGT6IbwZ0A1U1uoAa8Ls+NctshzjXI1uSXcEgDQ w4e/DPsYB16TzkEITSOXsbbLvgLjaOjjtX27MzAaocPtuxmC5I1k4QYthwC5yuN2DaTn JI1XtbEmJCQdhArfM1D1o98GrzNnd47VE1PCiMQZAALIovHz5mjsSQWUqwi5FowO7wF0 8VFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JuV3yzlO91MJh7E/CIVSXLkh5AgwfK5APE+Hx3d+Lok=; b=K0MpmqloYu4w9/s9B/Jv9YKbeqknqpllx7OgJcQ5khD2SLb2Y7v5IiN9pze9PksKoN PE3rTNTsF7TO+VTzxux1as4Llr+AeS2Am3Pzkpj2u1/Jmmmietc5A2+qcR4CFegL8swU 0iVVXOfL5co6AeELgtxos3pPsjGh+3RNB7dTZNHVeJl0HaTwU6ofv94hJVX/2znVGa/+ 2gSbhEBNyhyMuO+TcvjWoOHCXbrqQypH20Lvl4vbWiS0i2n/SOyYZbxS5PhgCOOGaWYy O80B/NBkou+lln6ECUjvIQm7y4ZyUHocuy7rotti6cT8ZEh1Z75yz6QKBlaWxMC3tmPD UJ5w==
X-Gm-Message-State: AElRT7Fyyh0gvkDh6sjMROQBnKIrjiPNaFpphsSGHVexXNkm1+coFFG5 /3v6H9/9kmkUH0hPo+o2Be1w0O0edy5elncUOvz8Kg==
X-Google-Smtp-Source: AIpwx4+mnTM301H7VRp8yyZUeTBG3DIAHIRhTPh2ijkFgAAnbagzu4kFBDF25f0JZdXatWa2tsYhA5urjQOzBHintFY=
X-Received: by 10.176.21.1 with SMTP id o1mr6253977uae.60.1522358481532; Thu, 29 Mar 2018 14:21:21 -0700 (PDT)
MIME-Version: 1.0
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca> <ce205a81-64c8-f2d0-8dea-0ce9f1f1c5de@gmail.com> <20180329173403.78d6efde@lminiero> <CALiegf=8Q+xSW7qxcdzUFC-otC87_x3Twjjjpi9bgns7Su553A@mail.gmail.com>
In-Reply-To: <CALiegf=8Q+xSW7qxcdzUFC-otC87_x3Twjjjpi9bgns7Su553A@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 29 Mar 2018 21:21:10 +0000
Message-ID: <CAOJ7v-1EP=2SCQQNtXhCoEO-GuBuG198GyU6pE1jrwyLXu2zdg@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: Lorenzo Miniero <lorenzo@meetecho.com>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="001a11463dcc83df5a056893b4c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/26iEq4wGs4lNvVd10fJfgL7uLlM>
Subject: Re: [rtcweb] WGLC 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 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2018 21:21:47 -0000

This notion of sites asking for device access just to get a full set of IP
addresses has been discussed many times, but I am not aware of any cases of
this happening in the real world.

If the user is on a VPN and trying to contact a MCU that is on the VPN,
Mode 2 (no devices access needed) will do the right thing, assuming HTTP
traffic is being routed correctly.


On Thu, Mar 29, 2018 at 2:04 PM Iñaki Baz Castillo <ibc@aliax.net> wrote:

> On 29 March 2018 at 17:34, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
> > And let's not forget we're not just talking of discriminating data
> > channels, here. As someone else already pointed out, this would affect
> > recvonly audio/video PeerConnections as well. Requiring access to
> > a local device to implement those would be a very hacky solution (and
> > in fact Safari, which currently does something like this, is horrible
> > in that regard), especially considering that, just as for data channels,
> > there would be no need to require access to your webcam if you just
> > wanted to attend a webinar and never say anything yourself. It would
> > actually have the effect of looking even shadier to end users ("why
> > exactly do you want to access my webcam? I'm just trying to watch
> > something here!"), just as it would for datachannel-only PCs, and
> > further reduce the trust people would have in WebRTC as a technology.
> >
> > As Lennart said, a different popup that says something like "this page
> > wants to create <something>" would be a much better solution. Yes,
> > another UI knob or something like this, but still much better than
> > abusing the only consent request we currently expose simply because
> > it's, again, the only we have and we don't want to annoy users too much.
>
> Completely agreed with Lorenzo. Asking for "mic/webcam access" to get
> full IP access and then not using the mic/webcam (because the app just
> wants to receive media or run a datachannel) is a hacky and ugly
> solution.
>
> Please, just add a new prompt to ask for full IP access and save such
> a setting per origin (same as getUserMedia when HTTPS). That's all.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>