Re: Working Group Last Call: HTTP Client Hints

Thanks for your feedback, Julian!
I PRed the related changes at
https://github.com/httpwg/http-extensions/pull/1072

On Sun, Feb 23, 2020 at 2:20 PM Julian Reschke <julian.reschke@gmx.de>
wrote:

> On 18.02.2020 05:09, Mark Nottingham wrote:
> > ...
>
> Here's my feedback:
>
> Terminology: please use "header field" or "field" consistently.
>

Done.


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

Sure. That would be a reference to https://tools.ietf.org/html/rfc6265 or
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05?
I'm guessing the former, but preferred asking.


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

Replaced it with "However, traditional proactive content negotiation
techniques often mean that clients send these request headers
prolifically."


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

Linked to UA Client Hints.


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

Removed everything but the 5234 reference.


>
> 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"?
>

Removed "configuration"


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

Renamed a few instances that were not meant to be used in the BCP14 keyword
sense, and capitalized others.


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

Added a 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
>

Good catch, thanks!


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

Sure! Added a section number. Not sure how to link directly to specific
anchors in other specs.


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

Indeed.


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

Added a "!"


>
>     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".
>

Changed.


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

Can you point to an example of what you mean by that?


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

mnot - thoughts?