Re: I-D Action: draft-ietf-httpbis-client-hints-03.txt

Ilya Grigorik <ilya@igvita.com> Sat, 11 February 2017 10:08 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15BE1294E0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 11 Feb 2017 02:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.4
X-Spam-Level:
X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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=igvita-com.20150623.gappssmtp.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 PTm2WSFrm6rC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 11 Feb 2017 02:08:43 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D961294A5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 11 Feb 2017 02:08:43 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ccUYe-0000h0-J0 for ietf-http-wg-dist@listhub.w3.org; Sat, 11 Feb 2017 10:05:32 +0000
Resent-Date: Sat, 11 Feb 2017 10:05:32 +0000
Resent-Message-Id: <E1ccUYe-0000h0-J0@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ilya@igvita.com>) id 1ccUYW-0000fK-O6 for ietf-http-wg@listhub.w3.org; Sat, 11 Feb 2017 10:05:24 +0000
Received: from mail-wr0-f176.google.com ([209.85.128.176]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ilya@igvita.com>) id 1ccUYP-000316-MU for ietf-http-wg@w3.org; Sat, 11 Feb 2017 10:05:19 +0000
Received: by mail-wr0-f176.google.com with SMTP id 89so123897587wrr.2 for <ietf-http-wg@w3.org>; Sat, 11 Feb 2017 02:04:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igvita-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wjRAWIZWcl968zhjcwl6rIANYXNLX0Cy/sr46OZMVVE=; b=wH7KjUW6c0h6DDojTISNqZwt0oMq2pghKNUdy68txG0Jj4rZOCL37yW/zNo2Q9GaX5 q7izEvqF2mMtWYXgBfQlBc5XEvRf2QzzIGjAvD84a0FCTNTeZtge+fjdQxeqjF0Y+Xnd UDLoxEd+lmuKNaBqj0oAJaG4Xv4L2nxq911xpJEFqNXwBUP+U5HrXzsktKxJHtLLznkQ KCxtx4W8MchbYugvZ2IpCt/LTFvvroFJ61ofyEaxthMMgUJG+hutT25VDb49IiMkZUWA MVNFCrJyxLPX9rC4j5oIK8dV3yZPx2odPqhIXbANPoyWy/MaljRS3kZv/bjg6HJckb00 69pg==
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=wjRAWIZWcl968zhjcwl6rIANYXNLX0Cy/sr46OZMVVE=; b=c0WdbM+HbIfpdmfKl1SCQwKgmPRHKCqCekes6qNPQ2EZDW5VURqK6bDvvCOyGZS8PB yCLW2OGg3ouZtJMxSKoXaZEoJAIUm1KoUfq2e/JH7bGu8NHdJxehsrLnSm7/BByFp0o1 ZZhNo34D2BbwIkO/pvbqmYWdMznnquBlxzztV/i8sf7SaPDcjVMtFpeBaBp/ddodlOBu zD8YxKe5BUhAE/OCrquZyAiyS2pj/YFYQYICY/F6RZNCza0tnC9t59g4tk3Q34WYX+vV fJKD5j92u/Mw4uDZ0+lVntVZZwZH9PF3/+3qN4AqaiDiC9EsFk0lUe/8Z/mHbfo1pjJo f/Bw==
X-Gm-Message-State: AMke39lG66BrX7N4E8dg94Y9Z1QH6N+1QriAxPnOM1pmGbab3UFLnFTjGkAkvSX93OECww==
X-Received: by 10.223.136.155 with SMTP id f27mr11101190wrf.98.1486807490932; Sat, 11 Feb 2017 02:04:50 -0800 (PST)
Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com. [209.85.128.180]) by smtp.gmail.com with ESMTPSA id k4sm4601421wmf.22.2017.02.11.02.04.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Feb 2017 02:04:49 -0800 (PST)
Received: by mail-wr0-f180.google.com with SMTP id k90so123542696wrc.3; Sat, 11 Feb 2017 02:04:49 -0800 (PST)
X-Received: by 10.223.136.109 with SMTP id e42mr11606355wre.14.1486807488891; Sat, 11 Feb 2017 02:04:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.141.131 with HTTP; Sat, 11 Feb 2017 02:04:08 -0800 (PST)
In-Reply-To: <EEB185E5-BC2E-47AB-BDB2-C5ABDDA9EB19@ischool.berkeley.edu>
References: <148070210225.29664.2630836091018103593.idtracker@ietfa.amsl.com> <15ba01d24d4b$bbd65ec0$33831c40$@baycloud.com> <AEB52D75-E794-468E-B954-E57A63C6EB3D@ischool.berkeley.edu> <F4E8AD6F-2981-440D-9D1F-09A5D361FD6A@mnot.net> <7AE1C62F-3899-412E-8EB3-062FDC8CFEEF@mnot.net> <224212CF-7955-4F83-A194-C33BC9F0A139@ischool.berkeley.edu> <3E5E3BDC-3257-44CA-B1C0-2648823AF492@mnot.net> <EEB185E5-BC2E-47AB-BDB2-C5ABDDA9EB19@ischool.berkeley.edu>
From: Ilya Grigorik <ilya@igvita.com>
Date: Sat, 11 Feb 2017 02:04:08 -0800
X-Gmail-Original-Message-ID: <CAKRe7JEqUr6Xryo7GaVGA5hT2MB+krOEiDJdKQLdkwGAEgxpgg@mail.gmail.com>
Message-ID: <CAKRe7JEqUr6Xryo7GaVGA5hT2MB+krOEiDJdKQLdkwGAEgxpgg@mail.gmail.com>
To: Nick Doty <npdoty@ischool.berkeley.edu>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP working group mailing list <ietf-http-wg@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Content-Type: multipart/alternative; boundary=001a114725ac39af0d05483e5894
Received-SPF: pass client-ip=209.85.128.176; envelope-from=ilya@igvita.com; helo=mail-wr0-f176.google.com
X-W3C-Hub-Spam-Status: No, score=-7.7
X-W3C-Hub-Spam-Report: AWL=1.560, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1ccUYP-000316-MU 127ac0a24656f7ebdb981f4a2eb7360c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: I-D Action: draft-ietf-httpbis-client-hints-03.txt
Archived-At: <http://www.w3.org/mid/CAKRe7JEqUr6Xryo7GaVGA5hT2MB+krOEiDJdKQLdkwGAEgxpgg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33472
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hey all, apologies about the (super) delayed response!

Re, Accept-CH:
https://github.com/httpwg/http-extensions/issues/284#issuecomment-279133287

> Ilya, as an aside -- referring to NetInfo is going to be problematic; it
> will likely block publication. Can we make that non-normative (or ideally,
> drop it)?
>

I'd prefer to keep the (non-normative) reference if possible.. let me know.

> AFAICT Width and Viewport-Width do not require pixel precision; would
> rounding to the nearest 10 be sufficient?


Pixel precision is available via JS. I don't see why we'd impose an
arbitrary rule here to round it here?

On Thu, Feb 2, 2017 at 3:30 PM, Nick Doty <npdoty@ischool.berkeley.edu>
 wrote:

> > Implementers might provide user choice mechanisms so that users may
> balance privacy concerns with bandwidth limitations. Implementations
> specific to certain use cases or threat models might avoid transmitting
> these headers altogether, or limit them to secure contexts or authenticated
> sessions. Implementers should be aware that explaining the privacy
> implications of passive fingerprinting or network information disclosure
> may be challenging.


^ tried to merge the comments from above -- yay/nay? As an aside, we should
probably move the wordsmithing into GitHub? :)

We can update section 2.1 to cover the above.
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-03#section-2.1

--

Did I miss anything?

ig



On Mon, Feb 6, 2017 at 4:42 PM, Nick Doty <npdoty@ischool.berkeley.edu>
wrote:

> On Feb 2, 2017, at 5:27 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > On 3 Feb 2017, at 10:30 am, Nick Doty <npdoty@ischool.berkeley.edu>
> wrote:
> >
> >>>>> Mitigations could include, as Mike suggests, asking users to opt in,
> although explaining the details to users may be difficult.
> >>>>
> >>>> That's already discussed in Security Considerations, although we
> could certainly expand it. Would you mind making text suggestions?
> >>>
> >>> Nick?
> >>
> >> A draft of text that could be added to the mechanisms/mitigations
> paragraph:
> >>
> >>> Implementers may
> >
> > might? Otherwise people could read it as MAY.
>
> Sure. I like "might" for that, but whatever is your group's preferred way
> to indicate conditionality without RFC2119 status is fine by me.
>
> >> provide user choice mechanisms so that users may balance privacy
> concerns with bandwidth limitations. Implementations specific to certain
> use cases or threat models might avoid transmitting these headers
> altogether, or limit them to authenticated sessions.
> >
> > s/authenticated sessions/secure contexts/ (or whatever the current
> terminology is)?
>
> I actually meant that the UA might want to distinguish between when they
> know a user is logged-in or otherwise already identified to a site, rather
> than over a secure HTTPS channel.
>
> >> Implementers should be aware that explaining the privacy implications
> of passive fingerprinting or network information disclosure may be
> challenging.
> >
> > How is this actionable?
>
> I meant this as a warning or limitation on the use of user choice as a
> mitigation. Given this challenge, implementations ought to rely on other
> mitigations unless informed user choice really seems plausible for their
> population.
>
> >>>>> The first sentence of the Security Considerations section appears to
> be false.
> >>>>>> Client Hints defined in this specification do not expose new
> >>>>>> information about the user's environment beyond what is already
> >>>>>> available to, and can be communicated by, the application at runtime
> >>>>>> via JavaScript and CSS.
> >>
> >> Presumably this could be addressed in re-writing the Security
> Considerations section. A potential start to that section:
> >>
> >> Client Hints defined in this specification may expose information about
> user's devices or network connections and include information in HTTP
> headers that may previously have been accessible through client-side
> scripting. Implementers should be aware of implications for new information
> disclosure, information disclosure to different parties and for the
> increased capacity for passive fingerprinting.
> >
> > +1
>