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

Mark Nottingham <mnot@mnot.net> Mon, 27 February 2017 05:28 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 695B2129B06 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 26 Feb 2017 21:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eYnx5_3QjGzw for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 26 Feb 2017 21:28:07 -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 75814129735 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 26 Feb 2017 21:28:07 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ciDoX-0006ik-Tn for ietf-http-wg-dist@listhub.w3.org; Mon, 27 Feb 2017 05:25:37 +0000
Resent-Date: Mon, 27 Feb 2017 05:25:37 +0000
Resent-Message-Id: <E1ciDoX-0006ik-Tn@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1ciDoN-0006hH-LS; Mon, 27 Feb 2017 05:25:27 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <mnot@mnot.net>) id 1ciDoE-0007yJ-UK; Mon, 27 Feb 2017 05:25:22 +0000
Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 738CD22E1F3; Mon, 27 Feb 2017 00:24:29 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAKRe7JHXrE4=4--n2Xs+LgxGvB1+Lu5dmKZZN7XddhH-ab_9+A@mail.gmail.com>
Date: Mon, 27 Feb 2017 16:24:25 +1100
Cc: Nick Doty <npdoty@ischool.berkeley.edu>, HTTP working group mailing list <ietf-http-wg@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7680F6FA-8E17-4240-BC0E-914C1028D131@mnot.net>
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> <CAKRe7JEqUr6Xryo7GaVGA5hT2MB+krOEiDJdKQLdkwGAEgxpgg@mail.gmail.com> <EAD963A1-8390-4771-B254-B4415467DD6C@mnot.net> <CAKRe7JHXrE4=4--n2Xs+LgxGvB1+Lu5dmKZZN7XddhH-ab_9+A@mail.gmail.com>
To: Ilya Grigorik <ilya@igvita.com>
X-Mailer: Apple Mail (2.3259)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-7.3
X-W3C-Hub-Spam-Report: AWL=2.296, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1ciDoE-0007yJ-UK 647232558b5bfae75fb6e7ae26e25f33
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/7680F6FA-8E17-4240-BC0E-914C1028D131@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33619
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>

Hi Ilya,

Looks good; I left a few editorial-ish notes in the pull request.

How do others feel? Note that (as I mentioned in an issue just now), I think our role here is to define the protocol elements and the potential privacy/security impact of using them, not to detail exactly how Web browsers are to use them. That's specified in the Fetch spec, and should happen over there. Make sense?

Ilya -- I also see this happening over at NetInfo: <https://github.com/WICG/netinfo/issues/46>. Is that something that we should be including here, or is it too early? How likely is it that it will deprecate Downlink?

Cheers,



> On 25 Feb 2017, at 4:39 am, Ilya Grigorik <ilya@igvita.com> wrote:
> 
> PTAL: https://github.com/httpwg/http-extensions/pull/305
> 
> On Sun, Feb 12, 2017 at 9:52 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> > On 11 Feb 2017, at 9:04 pm, Ilya Grigorik <ilya@igvita.com> wrote:
> >
> > 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.
> 
> Non-normative is better.
> 
> >
> > > 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?
> 
> The motivation was to avoid promoting active fingerprinting (via JS) into passive fingerprinting (in a header), by reducing the resolution of the data. Of course, if we do decide to require Accept-CH (at least for these headers), that seems like it would address it too.
> 
> 
> >
> > 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
> >
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/