Re: Genart last call review of draft-ietf-httpbis-client-hints-13

On Tue, May 5, 2020 at 8:51 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Yoav,
>
> I have not received the pull request yet, so I will comment only based on
> your e-mail reply :)
>

Apologies for the delay. PR is now up at
https://github.com/httpwg/http-extensions/pull/1171


>
> In general, I am happy with your explanations, and for most parts I think
> some text giving the explanations in the draft would be useful.
>
> -------
>
> Major issues:
>
> MaQ1:
>
> >> Section 2.1. describes sending of Client Hints, based on Accept-CH, and
> Section 3.1. defines the Accept-CH header field.
> >>
> >> First, there is no guidance on what a client does BEFORE it receives
> Accept-CH.
> >> I assume it does not include support of any features.
> >>
> >> Second, there is no guidance on what a client does if it does NOT
> receive
> >> Accept-CH (because the server does not support it). Will it then send
> another
> >> request and include supported features ? What if it is too late, and
> the server
> >> has already made choises?
> >>
> >> I think some client behavior guidance would be useful.
> >
> > Generally, without an opt-in (either before Accept-CH is received or
> when the server does not support it), clients SHOULD NOT send high-entropy
> hints, but MAY send low-entropy ones.
>
> I think some guidance text would be useful.
>
> ---
>
> MaQ2:
>
> >> Related to Q3, there is not server procedure on when Accept-CH is sent
> to the
> >> client. Also, can an Accept-CH with updated information be sent?
> >
> > Servers which wish to receive client information through Client Hints
> SHOULD add Accept-CH to their responses as early as possible.
> > Later Accept-CH response headers with updated information will override
> a previous opt-in.
>
> Some text would be useful for both cases above.
>
> ---
>
> MaQ3:
>
> >> Related to MaQ2, what happens if a server receives hints that it does
> not
> >> understand, or does not support?
> >
> > Servers SHOULD ignore hints they do not understand or do not support.
>
> Is there are reason for not using MUST? SHOULD typically means
> MUST-unless-X. What would X be?
>
> Is there a way for the server to indicate to the client that it did not
> understand/support the hints? Whatever the answer, I think it would be good
> to have some text about that.
>

There's no such a mechanism, similar to other request headers.
Do you have sample text in mind that may make that point clearer?


>
> ---
>
> MaQ4:
>
> >> Section 3.1 says:
> >>
> >>   “It SHOULD be persisted and bound to the origin to enable delivery of
> Client
> >>   Hints on subsequent requests to the server's origin.”
> >>
> >> …and the subsequent text then gives an example.
> >>
> >> First, what is the time scope of “subsequent requests”? A session? An
> hour? A
> >> day? For how long does the client need to remember the Accept-CH header
> field
> >> value for a given origin server?
> >
> > A session, so similar lifetime properties as session cookies.
>
> Add some text, please :)
>
> >> Second, the procedure does not seem to take into account that certain
> aspects,
> >> e.g., network characteristics, may change between when requests are
> sent to an
> >> origin server.
> >
> > It is the server preference that's persisted, not the specific
> information. Varying client characteristics will result in varying Client
> Hints request headers at different points in time.
>
> Ok.
>
> --------
>
> Minor issues:
>
> MiQ1:
>
> >> Section 1 described that proactive content negotiation allows servers to
> >> silently fingerprint the user agent.
> >>
> >> But, later in the Section it is described that Client Hints also allow
> a server
> >> the perform fingerprinting, and the Security Considerations also say
> that there
> >> is really no difference.
> >>
> >> So, does Section 1 need to talk about fingerprinting at all?
> >
> > Section 1 describes the fact that traditional (read: pre-Client Hints)
> content negotiation methods relied on sending information to all servers,
> which enabled passive fingerprinting,
> > and how Client Hints breaks away from that paradigm, by only sending
> (high entropy) hints when the server needs them and opts-in to receive them.
>
> A server can request the hints even if it doesn't "need" them, but it
> wants to do fingerprinting. The client does not know what the server will
> do with the information.
>
> My point is that the reader should not get an impression that client hints
> somehow prevents fingerprinting. It doesn't. The only difference is that
> the server has to ask for the information.
>

Current draft includes " Client Hints mitigate ... privacy concerns of
passive fingerprinting by requiring explicit opt-in and disclosure of
required headers by the server through the use of the Accept-CH response
header."
Should that be clearer?


> ---
>
> MiQ2:
>
> >> The 4th last paragraph of Section 1 says:
> >>
> >>   “It also defines guidelines for content negotiation mechanisms that
> use it,
> >>   colloquially referred to as Client Hints.”
> >>
> >> The 2nd last paragraph of Section 1 says:
> >>
> >>   “This document defines Client Hints, a framework that enables servers
> >>     to opt-in to specific proactive content negotiation features,
> >>     adapting their content accordingly.”
> >>
> >> The 2nd last pargraph also talks about “usage of infrastructure”, which
> I don’t
> >> really understand. I assume you mean the Client Hints framework?
> >>
> >> First, I think the text in the 4th last paragraph should be replaced by
> the
> >> text in the 2nd last paragraph.
> >>
> >> Second, I think the text introducing the framework should come BEFORE
> the text
> >> introducing the Accept-CH header field.
> >>
> >> Something like:
> >>
> >>   "This document defines Client Hints, a framework that enables servers
> >>   to opt-in to specific proactive content negotiation features,
> >>   adapting their content accordingly. This document also defines a new
> >>   response header, Accept-CH, that allows an origin server to explicitly
> >>   ask that clients send these headers in requests.
> >>
> >>   Client Hints mitigate performance concerns by assuring that clients
> >>   will only send the request headers when they're actually going to be
> >>   used, and privacy concerns of passive fingerprinting by requiring
> >>   explicit opt-in and disclosure of required headers by the server
> >>   through the use of the Accept-CH response header.
> >>
> >>   The document does not define specific usages of Client Hints. Such
> usages
> >>   Need to be defined in their respective specifications.
> >>
> >>   One example of such usage is the User Agent Client Hints [UA-CH]."
> >
> > Makes sense.
>
> Thanks! :)
>

Added a small tweak on "guidelines for content negotiation mechanisms that
use the framework".
You can review the PR to see if that works.

-------
>
> Nits/editorial comments:
>
> EdQ1:
>
> >> The document uses both “client” and “user agent” terminology. Is there
> a reason
> >> for that, or could one be picked?
> >
> > No reason in particular. We can probably stick to "client".
>
> Sounds good :)
>
> Thanks!
>
> Regards,
>
> Christer
>
>