HTTP Client Hints
draft-ietf-httpbis-client-hints-15

[Ballot comment]
Section 1: "passively providing such information allows servers to silently fingerprint the user" --> isn't pretty much all fingerprinting silent?

Moreover, I think it would be good to explain in Section 1 that Client Hints provides a way for servers to actively fingerprint clients rather than doing it passively.

Section 2.1: "Without such an opt-in, user agents SHOULD NOT send high-entropy hints, but MAY send low-entropy ones [CLIENT-HINTS-INFRASTRUCTURE]." --> Given the use of normative language here, I think either this doc or the referenced doc needs to define what high-entropy hints are. Are all hints not defined as low-entropy considered to be high-entropy? If so, then I think a change along the lines of what Benjamin proposed is warranted. If not (as the text in Section 4.1 sort of indicates), then this doc needs to specify what high-entropy hints are.

Section 4.1: "user choice mechanisms that allow users to balance privacy concerns against bandwidth limitations" --> This is vague enough that I don't understand what it is talking about. What is an example of such a mechanism?

Section 4.1:

  "The header-based opt-in means that we can remove passive
  fingerprinting vectors, such as the User-Agent string (enabling
  active access to that information through User-Agent Client Hints
  [4]), or otherwise expose information already available through
  script (e.g. the Save-Data Client Hint [5]), without increasing the
  passive fingerprinting surface."
 
How about changing that "we can" into a recommendation to do so? In other words, could this document recommend that if User-Agents are sending certain information in Client Hints that they stop sending it or similar information via other headers? Maybe this is too obvious, but given the breadth of HTTP clients in the wild, it may help to state the obvious.

[Ballot comment]
Hi,

Thanks for this document.  It seemed relatively easy to read, although I'm not sure whether I'm totally bought into the idea since it feels like it is perhaps making HTTP a little bit less stateless.  However, I'm not particularly familiar with the details of HTTP as it is outside my domain of expertise.

One issue that wasn't clear to me was how do you ensure that two independent entities don't both try and standardize the same client hint.  From looking at the IANA section in https://wicg.github.io/ua-client-hints/ it seems the answer is probably that the client hint headers would be expected to be registered in RFC3864.  It might be useful if this document had some text describing this, along with a reference to RFC 3864.

Regards,
Rob

[Ballot comment]
I have no significant concern here, but I would appreciate an answer if I understand the situation correctly.

The Accept-CH header value is  structure header value and uses sh-token which has a more restrictive syntax than the HTTP specifications token used for header field names. However, this restriction is not of any real practical concern as all registered HTTP headers starts with an ALPHA. I did notice that the new HTTP semantics documents proposed new registry was not mandating but strongly recommending to keep within what sh-token can except. Thus, do I assume correctly that this issue has been sufficiently discussed in the WG?

[Ballot comment]
[[ nits ]]

[ section 1 ]
* "requires external device" -> "requires an external device"?

[ section 2.2 ]
* "indicate user agents" -> "indicate to user agents"?

[ section 3.1 ]
* s/sh-list/sf-list/g

[ section 4.3 ]
* "we can remove" -> perhaps another wording that doesn't require "we"

* "unless the opt-in origin has explicitly delegated permission to another
  origin": is this delegation mechanism documented somewhere that should
  be referenced here?

* "is challenging and likely" -> "may be challenging or even"

[Ballot comment]
Section 1

  There are thousands of different devices accessing the web, each with
  different device capabilities and preference information.  These
  device capabilities include hardware and software characteristics, as
  well as dynamic user and user agent preferences.  Historically,

nit: should "user-agent" be hyphenated?

  applications that wanted to allow the server to optimize content
  delivery and user experience based on such capabilities had to rely
  on passive identification (e.g., by matching the User-Agent header

nit: it feels like "allow the server" would be something that involves
granting permission or the client sending an active signal (as proposed
by this document), as opposed to just the apaplication that "wanted the
server to optimize" and had to make do with such limited signal as was
already available.

  field (Section 5.5.3 of [RFC7231]) against an established database of
  user agent signatures), use HTTP cookies [RFC6265] and URL

nit: hyphenate user-agent again, used as an adjective.

  o  User agent detection cannot reliably identify all static
      variables, cannot infer dynamic user agent preferences, requires
      external device database, is not cache friendly, and is reliant on

nit: singular/plural mismatch ("an external device database" or
"external device databases")

  o  Cookie-based approaches are not portable across applications and
      servers, impose additional client-side latency by requiring
      JavaScript execution, and are not cache friendly.

(I think I missed a step in why a cookie-based approach inherently
requires javascript execution, though maybe it doesn't matter.)

  Proactive content negotiation (Section 3.4.1 of [RFC7231]) offers an
  alternative approach; user agents use specified, well-defined request
  headers to advertise their capabilities and characteristics, so that

Chasing the reference, it's not clear that it supports quite this strong
of a statement: in addition to the explicit negotiation fields, it also
allows using implicit characteristics such as client IP address and
User-Agent.

Section 2.1

  access of third parties to those same header fields.  Without such an
  opt-in, user agents SHOULD NOT send high-entropy hints, but MAY send
  low-entropy ones [CLIENT-HINTS-INFRASTRUCTURE].

It looks like the reference only defines a registry for low-entropy
hints, and we are inferring that any hints not listed in that table are
to be treated as "high-entropy".  Perhaps we could reword both
directions of this directive to refer only to the registry of
low-entropy hints (e.g., "SHOULD NOT send hints that are not listed in
[registry]")?

  Implementers need to be aware of the passive fingerprinting
  implications when implementing support for Client Hints, and follow
  the considerations outlined in the Security Considerations
  (Section 4) section of this document.

side note: in some sense the Accept-CH mechanism transforms it from a
passive to an active fingerprinting mechanism.

Section 2.2

  information in them.  When doing so, and if the resource is
  cacheable, the server MUST also generate a Vary response header field
  (Section 7.1.4 of [RFC7231]) to indicate which hints can affect the
  selected response and whether the selected response is appropriate
  for a later request.

side note: I suspect the answer I want is already present with a
detailed reading of RFC 7231, but I wonder if it's worth saying
something here about whether the Vary response header could/should
include registered client hint header field names that were not present
in the request in question.

Section 3.1

  Based on the Accept-CH example above, which is received in response
  to a user agent navigating to "https://example.com", and delivered
  over a secure transport, a user agent will have to persist an Accept-
  CH preference bound to "https://example.com".  It will then use it

What level of requirement is implied by "will have to" here?  IIUC, it's
just that "if anything is persisted, it must be keyed on" but with no
obligation to do any persistence.  If so, perhaps a wording like "any
persisted Accept-CH preference will be bound to" would be better?

  for navigations to e.g. "https://example.com/foobar.html", but not to
  e.g. "https://foobar.example.com/".  It will similarly use the
  preference for any same-origin resource requests (e.g. to

nit: comma after "e.g." (throughout).

  "https://example.com/image.jpg") initiated by the page constructed
  from the navigation's response, but not to cross-origin resource
  requests (e.g. "https://thirdparty.com/resource.js").  This
  preference will not extend to resource requests initiated to
  "https://example.com" from other origins (e.g. from navigations to
  "https://other-example.com/").

Perhaps thirdparty.example and other.example, to stay within the BCP32
space?

Section 3.2

  When selecting a response based on one or more Client Hints, and if
  the resource is cacheable, the server needs to generate a Vary
  response header field ([RFC7234]) to indicate which hints can affect
  the selected response and whether the selected response is
  appropriate for a later request.

Is BCP 14 language approprite here?

  Above example indicates that the cache key needs to include the Sec-
  CH-Example header field.

nit: please add the article "the" to make this a complete sentence.

Section 4

While I don't expect that I can tell the major browser vendors anything
new about the privacy considerations to client hints, I do think that we
should give some guidance to implementors of other HTTP clients, who may
not have such extensive depth of knowlege, on the general landscape in
which this mechanism is set.  The subsections hereof do a great job
covering a lot of relevant details and specific factors to consider;
thank you!  I think it may also be appropriate to have some more generic
lead-in text, noting that in the worst case, merely converting a passive
fingerprinting mechanism to an active fingerprinting mechanism with
server opt-in does not actually provide any privacy benefit (the worst
case being when all servers ask for all the data and clients accede)!
While we might hope that the need to jump through an extra hoop to
access fingerprinting information might dissuade some servers from
asking for it, it seems imprudent to assume that it will happen, so in
order to obtain real privacy benefit there needs to be some additional
policy controls in the client and in what hints are defined/implemented.
As I mentioned already, we already have a lot of the details for how to
apply such policy controls, and limitations to only define hints that
expose information already available in other means; what I'd like to
see is the high-level picture that ties them together.

Section 4.1

  upon it.  The header-based opt-in means that we can remove passive
  fingerprinting vectors, such as the User-Agent string (enabling
  active access to that information through User-Agent Client Hints
  [4]), or otherwise expose information already available through

I think this [4] is the same as [UA-CH].

Also, use of the first person ("we") is somewhat unusual in RFC style.

  Therefore, features relying on this document to define Client Hint
  headers MUST NOT provide new information that is otherwise not
  available to the application via other means, such as existing
  request headers, HTML, CSS, or JavaScript.

As written, this is a fairly weird condition.  What constitutes
"available to the application via other means"?  Does "put up an
interstitial until the user provides the information in question" count?

  o  Entropy - Exposing highly granular data can be used to help
      identify users across multiple requests to different origins.
      Reducing the set of header field values that can be expressed, or
      restricting them to an enumerated range where the advertised value
      is close but is not an exact representation of the current value,

nit: "close to" seems like it would scan better.

  Different features will be positioned in different points in the
  space between low-entropy, non-sensitive and static information (e.g.
  user agent information), and high-entropy, sensitive and dynamic
  information (e.g. geolocation).  User agents need to consider the
  value provided by a particular feature vs these considerations, and
  MAY have different policies regarding that tradeoff on a per-feature
  basis.

How about on a per-origin basis (and, e.g., domain reputation)?  An
"entropy budget" where an origin that asks for too many distinct hints
won't get all of them?
(I also wonder if a descriptive "may wish to have" is better than the
normative "MAY", here.)

  o  Implementers SHOULD restrict delivery of some or all Client Hints
      header fields to the opt-in origin only, unless the opt-in origin
      has explicitly delegated permission to another origin to request
      Client Hints header fields.

Am I reading things right that this document does not define any such
delegation mechanisms but is just admitting the possibility of such
mechanisms being defined in the future?  I'd suggest clarifying up in
§2.1 with a parenthetical (akin to the "outlined below" note about the
opt-in mechanism).

  Implementers SHOULD support Client Hints opt-in mechanisms and MUST
  clear persisted opt-in preferences when any one of site data,
  browsing history, browsing cache, cookies, or similar, are cleared.

Who is the target audience for this SHOULD?  If it's just "people
implementing this document", it seems ineffectual, and if it's any
broader scope it seems unenforcable.

Section 4.3

  Research into abuse of Client Hints might look at how HTTP responses
  that contain Client Hints differ from those with different values,

nit: what are "responses that contain Client Hints"?  We have discussed
Accept-CH header fields in responses, and client hints in requests, but
the only mention I recall of hints in responses was in the Vary header
field, and it's not clear that that is what was intended.

Section 5

  While HTTP header compression schemes reduce the cost of adding HTTP
  header fields, sending Client Hints to the server incurs an increase
  in request byte size.  Servers SHOULD take that into account when

nit: I wonder if this would be more clear as:

% Sending Client Hints to the server incurs an increase in request byte
% size.  Some of this increase can be mitigated by HTTP header
% compression schemes, but each new hint will still lead to some
% increased bandwidth usage.  Servers SHOULD [...]

Section 7.1

I'm not sure I understand why [FETCH] is listed as a normative
reference.

I find it amusing that we reference both 7231 and 7234 for Vary, though
to my untrained eye the current references both seem appropriate in
their respective locations.

Section 7.2

If [CLIENT-HINTS-INFRASTRUCTURE] is to be the source of truth for
low-entropy (and, by deduction) high-entropy hints, it seems like it
should be normative.

[Ballot comment]
** Section 4.1.  Per “Therefore, features relying on this document to define Client Hint headers MUST NOT provide new information that is otherwise not available to the application via other means, such as existing request headers, HTML, CSS, or JavaScript”, would this text allow for a shift in permissiveness if the references specs changed?  For example, if something was not permissible in Javascript/HTML/CSS “vX” today, but it was in “vX+1”, would that mean that additional data could be sent as hints?  I’m exploring the value of assigning version numbers to HTML, CSS and Javascript to freeze the security assumptions.

** Section 4.1.  Per “User agents need to consider the value provided by a particular feature vs these considerations, and MAY have different policies regarding that tradeoff on a per-feature basis”, IMO more is needed to handle these tradeoffs.  User agent implementations SHOULD expose this policy creation process through a rich set of configuration/tuning options and with an API to enable privacy-minded, third party software to assist the user in making choices.

** Section 4.1. Per “Implementers SHOULD restrict delivery of some or all Client Hints header fields to the opt-in origin only, unless the opt-in origin has explicitly delegated permission to another origin to request Client Hints header fields”, how does this delegation happen?

[Ballot discuss]
This one should be easy, then I plan to ballot "Yes":

Section 6.1:
* Why is an Experimental status RFC registering a new header field with "standard" status?  (See RFC3864, Section 4.2.1.)

[Ballot discuss]
This one should be easy:

Section 6.1:
* Why is an Experimental status RFC registering a new header field with "standard" status?  (See RFC3864, Section 4.2.1.)

[Ballot comment]
Nits:

Section 1:
* "... techniques are expensive to setup and maintain, ..." -- s/setup/set up/
* "... which data is required ..." -- s/is/are/
* I suspect paragraphs 5 and 7 of this section could be merged.

Section 2.1:
* "... access of third parties to same header fields."  -- s/to same/to those same/, perhaps?
* "Implementers SHOULD be aware ..." -- this feels like an awkward construction; might I choose not to be aware?

Section 2.2:
* "... contains one or more client hint header fields ..." -- Previous and subsequent sections capitalized "Client Hint", shouldn't that be done here too?

Section 4.1:
* The parenthetical example at the end of the second paragraph should be capitalized and is missing a period at the end.
* "Such features SHOULD take into account ..." -- same issue as before, this seems an odd use of BCP 14 language
* "User agents SHOULD consider ..." -- same
* "Implementers ought to consider ..." -- why is this only "ought to" given the prior SHOULDs?

Section 6.1:
* Why does "Specification document(s)" refer to only a specific section of this document?  Isn't the whole document applicable?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-client-hints-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single, new registration will be made as follows:

Header Field Name: Accept-CH
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be; Section 3.1 ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-08):

From: The IESG
To: IETF-Announce
CC: mnot@mnot.net, draft-ietf-httpbis-client-hints@ietf.org, Mark Nottingham , ietf-http-wg@w3.org, barryleiba@gmail.com, httpbis-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (HTTP Client Hints) to Experimental RFC


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'HTTP Client Hints'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  HTTP defines proactive content negotiation to allow servers to select
  the appropriate response for a given request, based upon the user
  agent's characteristics, as expressed in request headers.  In
  practice, clients are often unwilling to send those request headers,
  because it is not clear whether they will be used, and sending them
  impacts both performance and privacy.

  This document defines an Accept-CH response header that servers can
  use to advertise their use of request headers for proactive content
  negotiation, along with a set of guidelines for the creation of such
  headers, colloquially known as "Client Hints."




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/ballot/


No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup for draft-ietf-httpbis-client-hints

## 1. Summary

Mark Nottingham is the Document Shepherd; Barry Lieba is the Responsible AD.

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 intended status is Experimental, as there is currently only implementation in one major browser engine (Chromium, used in several browsers). The Working Group felt that it was useful to document this protocol extension to improve interoperability and encourage further implementation.

## 2. Review and Consensus

The document was reviewed by a broad range of Working Group participants, as well as external parties (through Github and other external venues). Members of the Web performance optimisation community are especially interested in this specification, as it allows for automating the use of "responsive images."

Consensus is rough regarding how useful this specification will be, but there was agreement that it was useful to document; hence the Experimental status.

## 3. Intellectual Property

The authors confirm that to their direct, personal knowledge, all IPR related to this document has already been disclosed.


## 4. Other Points

There are no downrefs.  IANA Considerations are clear.

# Shepherd Writeup for draft-ietf-httpbis-client-hints

## 1. Summary

Mark Nottingham is the Document Shepherd; Barry Lieba is the Responsible AD.

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 intended status is Experimental, as there is currently only implementation in one major browser engine (Chromium, used in several browsers). The Working Group felt that it was useful to document this protocol extension to improve interoperability and encourage further implementation.

## 2. Review and Consensus

The document was reviewed by a broad range of Working Group participants, as well as external parties (through Github and other external venues). Members of the Web performance optimisation community are especially interested in this specification, as it allows for automating the use of "responsive images."

Consensus is rough regarding how useful this specification will be, but there was agreement that it was useful to document; hence the Experimental status.

## 3. Intellectual Property

The authors confirm that to their direct, personal knowledge, all IPR related to this document has already been disclosed.


## 4. Other Points

There are no downrefs.  IANA Considerations are clear.