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

Ilya Grigorik <ilya@igvita.com> Fri, 24 February 2017 17:51 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 A6DE912944A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 24 Feb 2017 09:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.401
X-Spam-Level:
X-Spam-Status: No, score=-6.401 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] 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 zC-5shMBYnzK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 24 Feb 2017 09:50:58 -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 03A12129444 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 24 Feb 2017 09:50:57 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1chJxV-0001ai-Oo for ietf-http-wg-dist@listhub.w3.org; Fri, 24 Feb 2017 17:47:09 +0000
Resent-Date: Fri, 24 Feb 2017 17:47:09 +0000
Resent-Message-Id: <E1chJxV-0001ai-Oo@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 <ilya@igvita.com>) id 1chJxA-0001VO-E3 for ietf-http-wg@listhub.w3.org; Fri, 24 Feb 2017 17:46:48 +0000
Received: from mail-wm0-f48.google.com ([74.125.82.48]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ilya@igvita.com>) id 1chJx2-0006Gv-9a for ietf-http-wg@w3.org; Fri, 24 Feb 2017 17:46:43 +0000
Received: by mail-wm0-f48.google.com with SMTP id 196so9888036wmm.1 for <ietf-http-wg@w3.org>; Fri, 24 Feb 2017 09:46:18 -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=kwuLQt2ogxL4NFcpL3aOoa07sV6HNDw8xXZEm90sEzc=; b=M34B66cj3JFPL6fPUxXFOAlKWfw1fz4qiW3R0BWEx8XBDTf5+scjLj2Y5NwxTCrfT9 fiOw67xc2cEjSDEAUEKwKmM0zwQ+cbsTHV4eOK6qP2kDI94+ONXs245SPwz2gaQoLQ5O cpqzZKlteToCQ1IToDdc3WW4pEk/xDNeIPrpblwoyC0vZyKsv1S35fQ0mmjF2oxdCP5v I5ftvQ8OVwQMcaRLvuBGVx4oc2PdFNT/ledhAKKCirtU7XQpCFjBUrJxwvsoSYFsXXLO kgT9jct6252TgTd9KeVZYOqCfmeFf3Us+x2jseBH+4GbimOIpLRaWeL+xZZeN/gTHoV1 6FlA==
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=kwuLQt2ogxL4NFcpL3aOoa07sV6HNDw8xXZEm90sEzc=; b=jdCIFBRN0NJWUT2rYodc4O1zVLIKLBYSe9PUJ/dnMo/WDdnt6FjSdSMfpyk0PAU971 pNxbQHjt/bqDpt27yyj8GM1f4eAhqux7cBHc6F1kZXEIuatWhTcF0gBVboXo4v1rHLNm h2zvwx74olDPXXbJtRwgh05HKY+j5dFLoMTwJQG4C3Mh9PH8RpOS7IJBNYT7LJrK2C8D HYomwUWpypFc5KUS/WZL9WRQ1lNgQiLFB+YqL+wWbxmpmx1SnuLSFn1JTozFsF3Vc2Em ef5teyxcE/MmoFigDQrAxjkeE5FQkq/XrNqc25A1Lf/h+c+SB0FLL374Qcx/YlXKWiHh mRrg==
X-Gm-Message-State: AMke39mqWK12CmWrwxnlkcYmKiuQUlKIt7G+YEdx45Rclo2wXlbZJYRtt2e3yVIqbVTeug==
X-Received: by 10.28.216.14 with SMTP id p14mr3497964wmg.56.1487958010067; Fri, 24 Feb 2017 09:40:10 -0800 (PST)
Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com. [209.85.128.174]) by smtp.gmail.com with ESMTPSA id c133sm3145411wmd.13.2017.02.24.09.40.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 09:40:08 -0800 (PST)
Received: by mail-wr0-f174.google.com with SMTP id 89so17646167wrr.3; Fri, 24 Feb 2017 09:40:08 -0800 (PST)
X-Received: by 10.223.136.168 with SMTP id f37mr3594394wrf.98.1487958008018; Fri, 24 Feb 2017 09:40:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.141.135 with HTTP; Fri, 24 Feb 2017 09:39:27 -0800 (PST)
In-Reply-To: <EAD963A1-8390-4771-B254-B4415467DD6C@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>
From: Ilya Grigorik <ilya@igvita.com>
Date: Fri, 24 Feb 2017 09:39:27 -0800
X-Gmail-Original-Message-ID: <CAKRe7JHXrE4=4--n2Xs+LgxGvB1+Lu5dmKZZN7XddhH-ab_9+A@mail.gmail.com>
Message-ID: <CAKRe7JHXrE4=4--n2Xs+LgxGvB1+Lu5dmKZZN7XddhH-ab_9+A@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
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-Type: multipart/alternative; boundary=001a11461dc4824b9a05494a3814
Received-SPF: pass client-ip=74.125.82.48; envelope-from=ilya@igvita.com; helo=mail-wm0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-6.5
X-W3C-Hub-Spam-Report: AWL=0.893, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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: titan.w3.org 1chJx2-0006Gv-9a 160bea3d31c34c388bf982a17a29a791
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/CAKRe7JHXrE4=4--n2Xs+LgxGvB1+Lu5dmKZZN7XddhH-ab_9+A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33611
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>

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/
>
>