Re: Working Group Last Call: HTTP Client Hints

On 18.02.2020 05:09, Mark Nottingham wrote:
> ...

Here's my feedback:

Terminology: please use "header field" or "field" consistently.

In Section 1:

    well as dynamic user and client preferences.  Applications that want
    to allow the server to optimize content delivery and user experience
    based on such capabilities have, historically, had to rely on passive
    identification (e.g., by matching User-Agent (Section 5.5.3 of
    [RFC7231]) header field against an established database of client
    signatures), used HTTP cookies and URL parameters, or use some
    combination of these and similar mechanisms to enable ad hoc content
    negotiation.

Please add refernce to Cookie spec.

    However, proactive content negotiation requires clients to send these
    request headers prolifically.  This causes performance concerns
    (because it creates "bloat" in requests), as well as privacy issues;
    passively providing such information allows servers to silently
    fingerprint the user agent.

FWIW, it doesn't really *require* them to be send prolifically; it's
just the easiest way to do so.

If there was a requirement for that, *this* spec by definition couldn't
exist.

    This document defines the Client Hints infrastructure, a framework
    that enables servers to opt-in to specific proactive content
    negotiation features, which will enable them to adapt their content
    accordingly.  However, it does not define any specific features that
    will use that infrastructure.  Those features will be defined in
    their respective specifications.

It would be great if this could link to at least one example of those.

In 1.1.:

    This document uses the Augmented Backus-Naur Form (ABNF) notation of
    [RFC5234] with the list rule extension defined in [RFC7230],
    Appendix B.  It includes by reference the DIGIT rule from [RFC5234]
    and the OWS and field-name rules from [RFC7230].

No, it doesn't.

In Section 2:

    A Client Hint request header field is a HTTP header field that is
    used by HTTP clients to indicate configuration data that can be used
    by the server to select an appropriate response.  Each one conveys
    client preferences that the server can use to adapt and optimize the
    response.

Is it really always "configuration data"?

2.1.  Sending Client Hints

    Clients control which Client Hints are sent in requests, based on
    their default settings, user configuration, and server preferences.
    The client and server can use an opt-in mechanism outlined below to
    negotiate which fields should be sent to allow for efficient content
    adaption, and optionally use additional mechanisms to negotiate
    delegation policies that control access of third parties to same
    fields.

    Implementers should be aware of the passive fingerprinting
    implications when implementing support for Client Hints, and follow
    the considerations outlined in "Security Considerations" section of
    this document.

General comment: it seems to me that BCP14 keywords are uppercased
somewhat randomly...

    Implementers should be aware of the passive fingerprinting
    implications when implementing support for Client Hints, and follow
    the considerations outlined in "Security Considerations" section of
    this document.

Please make this a proper xml2rfc link...


Section 3.:

    Servers can advertise support for Client Hints using the mechnisms
    described below.

a) a/mechnisms/mechanisms/
b) looks like a single mechanism to me, actually


In 3.1:

    The Accept-CH response header field or the equivalent HTML meta
    element with http-equiv attribute ([HTML]) indicate server support
    for particular hints indicated in its value.

A more precise reference might be good here. The HTML spec is really big.

    Accept-CH is a Structured Header [I-D.ietf-httpbis-header-structure].
    Its value MUST be an sh-list (Section 3.1 of
    [I-D.ietf-httpbis-header-structure]) whose members are tokens
    (Section 3.7 of [I-D.ietf-httpbis-header-structure]).  Its ABNF is:

There is no Section 3.7 there; maybe
<https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-15#section-3.3.4>?

      Accept-CH = sh-list

    For example:

      Accept-CH: Sec-CH-Example, Sec-CH-Example-2

    When a client receives an HTTP response advertising support for
    provided list of Clients Hints, it SHOULD process it as origin
    ([RFC6454]) opt-in to receive Client Hint header fields advertised in
    the field-value, for subsequent same-origin requests.

RFC6454 appears as informative reference, but has a normative
requirement referencing it.

    For example, 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 SHOULD persist an
    Accept-CH preference bound to "https://example.com" and use it for
    user agent navigations to "https://example.com" and any same-origin
    resource requests initiated by the page constructed from the
    navigation's response.  This preference SHOULD NOT extend to resource
    requests initiated to "https://example.com" from other origins.

Don't put normative keywords into examples. The requirements are alreay
defined earlier, right? For instance, say "will have to" instead of
"SHOULD".

In 3.1.1:

I'd make that Section 3.2.

In 4.1:

    o  Entropy

       *  Exposing highly granular data may help identify users across
          multiple requests to different origins.  Reducing the set of
          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, can improve
          privacy and reduce risk of linkability by ensuring that the
          same value is sent by multiple users.
    o  Sensitivity

       *  The feature SHOULD NOT expose user sensitive information.  To
          that end, information available to the application, but gated
          behind specific user actions (e.g. a permission prompt or user
          activation) SHOULD NOT be exposed as a Client Hint.
    o  Change over time

       *  The feature SHOULD NOT expose user information that changes
          over time, unless the state change itself is also exposed (e.g.
          through JavaScript callbacks).

The list is structured a bit strange. Maybe make it a definition list.


Appendix A.  Interaction with Variants Response Header Field

    Client Hints may be combined with Variants response header field
    [VARIANTS] to enable fine-grained control of the cache key for
    improved cache efficiency.  Features that define Client Hints will
    need to specify the related variants algorithms as described in
    Section 6 of [VARIANTS].

Unless we're planning to finish VARIANTS really soon, I'd drop this
appendix.

Received on Sunday, 23 February 2020 13:17:12 UTC