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

Ilya Grigorik <ilya@igvita.com> Mon, 27 February 2017 05: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 31985129B14 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 26 Feb 2017 21:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 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_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
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 BC-anLXKBdbX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 26 Feb 2017 21:51:47 -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 493D8129B12 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 26 Feb 2017 21:51:47 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ciEAx-0000gt-1d for ietf-http-wg-dist@listhub.w3.org; Mon, 27 Feb 2017 05:48:47 +0000
Resent-Date: Mon, 27 Feb 2017 05:48:47 +0000
Resent-Message-Id: <E1ciEAx-0000gt-1d@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 1ciEAo-0000fY-Mk for ietf-http-wg@listhub.w3.org; Mon, 27 Feb 2017 05:48:38 +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 1ciEAg-0000mz-F8 for ietf-http-wg@w3.org; Mon, 27 Feb 2017 05:48:33 +0000
Received: by mail-wm0-f48.google.com with SMTP id t18so16202542wmt.0 for <ietf-http-wg@w3.org>; Sun, 26 Feb 2017 21:48:09 -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=Op7XmhFquZpVIO7FMnIyf2sgxb0nss0efq3bySPSa4Y=; b=XJyt/NxQa7x4ZGqceGb7pylVBlRrCFmeuPyHmYAicyRAiQwYrI1x/qvZTu87hqdZAk rzYcEH+LLOcfLBcQH8Rdg74IkA+YuUgyWNwR2kD7SLHlaw1ZDptMTmwcp5fNzfqh6v9C DnVreVTFbPoad5ZrPZ4sZ9hgNTR1nyfEttV0P57tU1ZXl93i2Av4B1M98ipDMaSTwUun g2XBQzh0mQBvyvjbyCW9ivCfpKu1jJJdfHZhlWb8Wet6uFTNYuQK8utwYFiUUSOaxMNK 95z8wwZJLnnMbNLUNc7Wh2mKTfeUTdK7P9lLSIhmKxgI3llONehaKh5j3D6Xkr4u7bI+ i7yw==
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=Op7XmhFquZpVIO7FMnIyf2sgxb0nss0efq3bySPSa4Y=; b=rfb39kHxChIg0cYdfNMVi6kMRXsa8+P5fMjguGkdNvvW/CUj0RtsrRdkBf8nFjbjq8 ljnZZnOkerq5DR3V0KwzuWCrchpfjLMHb/kqz9Cofe5W/Vqi8fjXFS6FdZ6t2AMjYKYu hqH9QHsSR+4M83mQFT5DOtCirmxTrB8o+fQ0Lmg5pI2Nj7Smm9duNoRaLs9eeL/wNyXg TeEPewcgz1Su2WKUf6S6+0uXViYZFNnlif2v+W/Yp3RIF0YElIWQJEF87pZv7ef4fD53 phHP+6cC6cK7s0HkAlH42rvSr3f92yb3WaCuE3ZkP3qCd3UK71SQ5pN98ISFGsIQ1b/d rrsw==
X-Gm-Message-State: AMke39n+ToTzh03ZQHZVLVCdi9aDqEQxFA+i6xC0I7ird2S7Zi4owCBEw/jl8Ui8jed44A==
X-Received: by 10.28.225.132 with SMTP id y126mr11099213wmg.127.1488174483214; Sun, 26 Feb 2017 21:48:03 -0800 (PST)
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com. [74.125.82.48]) by smtp.gmail.com with ESMTPSA id o2sm20779749wra.42.2017.02.26.21.48.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2017 21:48:02 -0800 (PST)
Received: by mail-wm0-f48.google.com with SMTP id 196so16245035wmm.1; Sun, 26 Feb 2017 21:48:02 -0800 (PST)
X-Received: by 10.28.173.74 with SMTP id w71mr11104819wme.14.1488174481818; Sun, 26 Feb 2017 21:48:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.141.135 with HTTP; Sun, 26 Feb 2017 21:47:21 -0800 (PST)
In-Reply-To: <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> <7680F6FA-8E17-4240-BC0E-914C1028D131@mnot.net>
From: Ilya Grigorik <ilya@igvita.com>
Date: Sun, 26 Feb 2017 21:47:21 -0800
X-Gmail-Original-Message-ID: <CAKRe7JFK5RFPgCLinjzyOLdbBZ0=Wtsdy+NhayGJ_zb2SVHh9w@mail.gmail.com>
Message-ID: <CAKRe7JFK5RFPgCLinjzyOLdbBZ0=Wtsdy+NhayGJ_zb2SVHh9w@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=001a11444a865a50ed05497c9ff8
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=-7.9
X-W3C-Hub-Spam-Report: 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, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1ciEAg-0000mz-F8 95581a2d501a3b9045659490bf2241aa
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/CAKRe7JFK5RFPgCLinjzyOLdbBZ0=Wtsdy+NhayGJ_zb2SVHh9w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33620
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>

On Sun, Feb 26, 2017 at 9:24 PM, Mark Nottingham <mnot@mnot.net> wrote:

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

Thanks! Followed up on the PR.


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


Still under active discussion.. Personally, I don't think we need to
include those in CH. They do reference CH and there is discussion about
using Accept-CH, but that's all fine. If we need to, we can always craft
separate specs for those later.


> How likely is it that it will deprecate Downlink?
>

Good question.. not sure. I think we need some operational experience to
figure that out.

Perhaps a more relevant one to consider is:
https://github.com/WICG/netinfo/issues/47.

ig


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