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

Lennart Grahl <lennart.grahl@gmail.com> Wed, 28 March 2018 01:50 UTC

Return-Path: <lennart.grahl@gmail.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 4DEC7126BF7 for <rtcweb@ietfa.amsl.com>; Tue, 27 Mar 2018 18:50:08 -0700 (PDT)
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 iRZrP9WXJLgb for <rtcweb@ietfa.amsl.com>; Tue, 27 Mar 2018 18:50:06 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 9AE94120724 for <rtcweb@ietf.org>; Tue, 27 Mar 2018 18:50:06 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id m13so684093wrj.5 for <rtcweb@ietf.org>; Tue, 27 Mar 2018 18:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9Jz8qAA8Y4Gx1MR/HcTDVQEikPgQwf/NA1K0d0Nx1mQ=; b=S5AnUXt4y5cCO2SshY2i5PrFv0LTt+V/vUUSusBFnisqshuULJ1gji7erOWq1uyB9z +I+XICH5cJPKAliJ561ilXc74SHseFC3o1kALO+CM07kJvtBvWKf3AOHyRDWE538QomP 1jRNRN8uAFS1KwyKyRmIfMVdeKWcjDZERWxBQWJ6lMjWjE474IRyP1hh+6IHPSYwel6b ICS6hJxPgdDSs4pYU7RkSy6VCcy64+UYAHDAEZOb1Ru0LgD5KxSQSDC7kwvxqaOjeN51 R08LNinaRRtSxORUjNzrP13WMjP2VHtH98inp4S3a0DnvwOBEfvhU2e5OfVcZEpUWKXZ fULw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9Jz8qAA8Y4Gx1MR/HcTDVQEikPgQwf/NA1K0d0Nx1mQ=; b=tkDGcUnkw0MpV7dLPX2zpL6n/HbTrX7nUsYCOHhoi+vKGdYXurE06uANKDh1TwjI7E ZR/q2Qq5jxzAYGoU4toNPBB3gdzWZk9w8K2SJPESRCDNBWwShpwbG2Vvwatd6srh2Sgu 6kubSCuY6XOc489s9robvz+TvfToS/bE3iyemSWj94gGs1lU3cQJaxlcyVzlkk6qxZ2t cu0jnaHeqx/CCwduh9Whw6M6h7EOnZ2gLDMVIgCJLIePkP6ZbFfWanbXfqaas0KajAaA rt59q2uyXI/JEwM7eSDUhB+dhsONmhJ5764eraRFAC6xHyqZ+tNcZMvy6XCPRUpZQFHD L57Q==
X-Gm-Message-State: AElRT7EEOh7CRNStdvhdVmSpWvnYZIxxv6nlM8KD/JGIQgAvNffZXfbp E0paBGC1SMedMrV96+C3Gt/MD7wC
X-Google-Smtp-Source: AIpwx4+zBBYMS0RaSm6SYe2380/XpiuT4GlvUFeGbYM9ldHg19vU2NdEkVeIhxPYbraJt+GIyOK/XA==
X-Received: by 10.223.157.3 with SMTP id k3mr1254872wre.179.1522201805128; Tue, 27 Mar 2018 18:50:05 -0700 (PDT)
Received: from ?IPv6:2003:cd:6bc2:9a00:f042:6c27:8554:c13b? (p200300CD6BC29A00F0426C278554C13B.dip0.t-ipconnect.de. [2003:cd:6bc2:9a00:f042:6c27:8554:c13b]) by smtp.gmail.com with ESMTPSA id m62sm3674504wmi.19.2018.03.27.18.49.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Mar 2018 18:50:04 -0700 (PDT)
To: rtcweb@ietf.org
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca>
From: Lennart Grahl <lennart.grahl@gmail.com>
Openpgp: preference=signencrypt
Message-ID: <ce205a81-64c8-f2d0-8dea-0ce9f1f1c5de@gmail.com>
Date: Wed, 28 Mar 2018 03:49:59 +0200
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: <8C7113E7-1D06-4FF4-BDD8-9F40E9C94D86@iii.ca>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/UROjI2qcfKU8C-L_CPC9ccHorZU>
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: Wed, 28 Mar 2018 01:50:08 -0000

On 27.03.2018 18:57, Cullen Jennings wrote:
> This draft results in the situation where implementations decide if they should reveal the users location to the website by asking a questions of the form "Will you allow example.com to use your camera?" If the user says that is OK to use their camera, in many cases they have also allowed the website to get their location via the IP address. From a user point of view, I think this is awful, There are many reasons I might allow a website I do not trust to know my location to access my camera - for example, I have a black cover over my camera and the website won't work unless I say yes to this request. Or a webcam worker where the job involves revealing video but revealing the locations they work at may put them at risk of serious harm. Or I am in a domestic abuse shelter and want to have a call but revealing may location puts me at risk of physical harm. I do not think the IETF should in any way endorse this extremely misleading form of consent. It is simply not consent. I realize this would be good for companies that are primary funded by by web advertising for which location is valuable.

I agree with you here and this is most likely the reason why WebRTC is
on the blacklist of many privacy extensions for browsers.

However, I believe there could be a form of consent in the browsers -
tell them what you actually want to do: Expose (all) private IP
addresses to create a direct connection. Yes, getting users to
understand what it means to "establish a direct connection" may not be
trivial - granted. But it's much more sincere AND it would not
discriminate data channel only use cases (yeah, it's really shady to
request capture permissions to be able to use mode 1).

And FWIW I'm not sure this form of consent fits into the scope of the
IETF. Maybe the modes could be defined in this document and which mode
to choose under which circumstances could be moved into the W3C WebRTC spec.

Cheers
Lennart