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

Nick Doty <> Wed, 14 December 2016 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E06CC1297CD for <>; Tue, 13 Dec 2016 17:11:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.797
X-Spam-Status: No, score=-9.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LhMgWUsQgBIm for <>; Tue, 13 Dec 2016 17:11:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC09512953B for <>; Tue, 13 Dec 2016 17:11:44 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cGy4N-0000El-A7 for; Wed, 14 Dec 2016 01:09:19 +0000
Resent-Date: Wed, 14 Dec 2016 01:09:19 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cGy4C-00009R-Ka for; Wed, 14 Dec 2016 01:09:08 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cGy46-0004Eb-0r for; Wed, 14 Dec 2016 01:09:03 +0000
Received: by with SMTP id p66so1708618pga.2 for <>; Tue, 13 Dec 2016 17:08:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=33CR1Ct3g1AwWQ7QtMO6uTSWIshOcxi63qRr9RgTuQE=; b=yGDVTqL2Rvm9pJ29tyfV1E8K9uS3cwtU2HyPFtLY2MiRfs5y8jmwUpM09WV0plZ73t oShAtv/naAgPfWcJpjECeWwi3W3EFyxqIS2dLN9lbaNbhk4mJ3pzA7x8d6pOZvCeSJq2 +jbQAk2YLg3pJasu/p1LKAp0VAbtEkawIhMxHecXT67clNip8jHZ++wDRbFr9za2kTkx EXgzKOxZPSkwQBVGQYR34f2B/rozfbxqObsJhjIKXbzsFxLvgn0Nkg0aWPvBKK5LKAbw 8ny4ZaUa0tzQROri1/FVsVv4RmbU/DeL1FZjO1a1F6IK70VHP6K8YmTaO3DrJn2fq0KF gRqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=33CR1Ct3g1AwWQ7QtMO6uTSWIshOcxi63qRr9RgTuQE=; b=gLlDfGxe9+L5/0oTcwdh2XiLpuJph9GwywHM0LOo5iXp690eo1Ji+GosTwM9mm5VmX kHI2uVivyLSHuUfEYf/eViVJziRQNjPjUHA49coj9icWF5O8mO2c6ejz39VpHmQNqeRi t/Os8qytObvmzpGcVV1q4D86wOjZVvtsdBnEyA+o45bBgoea43KteFSPu6FGhLtEKu4M c/Kn/CooeGCWRPMZddCuPyOqIn/tgx3j8pXDFNCcrCjKTc2kFmAehzcisPQOe7hjabgx O0OqSoKKCpbvJm9R9JranZ+1RBvqtMwf7EQJsWzsZwmswn4zq4GfckOCx7MffWKkGfpq WXDQ==
X-Gm-Message-State: AKaTC01js0PKPSqpqcs5XEynmiVEJbZCS7R/xIOhObXeaVvVz6VdvtLBdss2Bv90IKAcXSSB
X-Received: by with SMTP id x76mr104293442pfk.33.1481677714896; Tue, 13 Dec 2016 17:08:34 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id d15sm82491915pfl.46.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Dec 2016 17:08:33 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_20195B2F-BE16-4FCA-AF49-B4258B2D1D35"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Nick Doty <>
In-Reply-To: <15ba01d24d4b$bbd65ec0$33831c40$>
Date: Tue, 13 Dec 2016 17:08:24 -0800
Cc: Mike O'Neill <>
Message-Id: <>
References: <> <15ba01d24d4b$bbd65ec0$33831c40$>
To:, "public-privacy (W3C mailing list)" <>
X-Mailer: Apple Mail (2.3124)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.1
X-W3C-Hub-Spam-Report: AWL=0.775, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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: 1cGy46-0004Eb-0r 2d65c5863aeae1346ce0bae89df73e2a
Subject: Re: I-D Action: draft-ietf-httpbis-client-hints-03.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/33174
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I share Mike's concern about the privacy issues of this proposed mechanism. It appears that this feature would ease browser fingerprinting; inhibit efforts to detect or mitigate browser fingerprinting; and expose local network information. The Security Considerations section does not adequately describe or mitigate these impacts.

In particular, while some information exposed in these hints may already be available to client-side JavaScript in some browser implementations, making the same information available in (potentially all) HTTP requests would make fingerprinting more trivially achievable and, importantly, less detectable. Making fingerprinting detectable is a key goal given the challenge of eliminating the capability altogether and the potential harmful effects of unsanctioned tracking methods. Moving information about the user from active client-side code into HTTP requests inhibits user agents, researchers and policymakers in detecting that fingerprinting is ongoing.

Related, adding HTTP headers for subrequests, including to static resources, exposes client information to parties that previously would not have been able to access it, and in a way where the user agent cannot detect it. The Introduction notes as a limitation that HTTP cookies are bound by the same-origin policy; we typically cite the same-origin policy as a feature of the Web privacy model, not something to be removed.

Finally, this draft includes adding access to local network information; as defined, this is potentially high entropy (as opposed to "Save-Data" which has only the "on" value) the "Downlink" header has (at least) 33 values in the cited Community Group report and user agents and can also reveal private network topology that might otherwise have been intentionally obscured.

Mitigations could include, as Mike suggests, asking users to opt in, although explaining the details to users may be difficult. Detectability could be improved by requiring that user agents only send client hint information in HTTP if the server has specifically requested it in an HTTP response header. Specifying that hints should not be sent to other origins on subrequests would limit the unintentional spread of this client information. At that point, however, it's not entirely clear how great the functional advantage is over using existing mechanisms (like client-side JavaScript access to user agent information and explicit HTTP cookies for managing preferences). Restricting values to a smaller enumerated range is mentioned, but the specification does not provide such an enumeration or recommend its use.

While I'm glad to see that there has been some discussion of active/passive fingerprinting and our draft on mitigating browser fingerprinting (, I'm not sure those issues have been substantively resolved. That implementers could potentially implement a variety of mitigations is accurate, but if we consider which of those mitigations is necessary to prevent a marked harm to user privacy, we could include some mitigations in the design, such that UA/server implementation variation doesn't determine the outcome.

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.

Both the Downlink and Save-Data client hint, if broadly implemented, would likely reveal new information about the user's environment. Also, it's generally concerning when the first sentence of the Security Considerations section does not summarize the security or privacy issues of a specification but instead suggests to the casual reader that there's nothing to see here.

> However, implementors
>    should consider the privacy implications of various methods to enable
>    delivery of Client Hints - see "Sending Client Hints" section.

The Security Considerations section also refers to the Sending Client Hints section, but I don't understand the point it's trying to make. Is it just that user agents can use user preferences to decide whether to send client hints and could use that as a time to consider privacy implications?


> On Dec 3, 2016, at 1:58 AM, Mike O'Neill <> wrote:
> I worry that this makes fingerprinting easier for tracking servers, especially for subresources.
> It is true that these capabilities are already available via JS but only for browsing contexts and the extra turnaround forces some stickiness. This would make these granular user-agent capabilities immediately available to any resource, without need for a round trip.
> I think that at least the availability of a user opt-in should be a MUST.
> -----Original Message-----
> From: []
> Sent: 02 December 2016 18:08
> To:
> Cc:
> Subject: I-D Action: draft-ietf-httpbis-client-hints-03.txt
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Hypertext Transfer Protocol of the IETF.
>        Title           : HTTP Client Hints
>        Author          : Ilya Grigorik
> 	Filename        : draft-ietf-httpbis-client-hints-03.txt
> 	Pages           : 13
> 	Date            : 2016-12-02
> Abstract:
>   An increasing diversity of Web-connected devices and software
>   capabilities has created a need to deliver optimized content for each
>   device.
>   This specification defines a set of HTTP request header fields,
>   colloquially known as Client Hints, to address this.  They are
>   intended to be used as input to proactive content negotiation; just
>   as the Accept header field allows clients to indicate what formats
>   they prefer, Client Hints allow clients to indicate a list of device
>   and agent specific preferences.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at: