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

[Yoav Weiss <[e-mail]>]

On Wed, May 6, 2020 at 2:43 PM Christer Holmberg <
[e-mail]> 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://protect2.fireeye.com/v1/url?k=0a42e34e-54e25920-0a42a3d5-
> >
> 869a14f4b08c-11c3f32cbd74f2f2&q=1&e=978d85da-fab3-4523-a8d9-447aa6bdf056&u=
> https://github.com/httpwg/http-extensions/pull/1171
>
> Thanks!
>
> I think it looks ok.
>
> BTW, are high-entropy and low-entropy defined and well-known HTTP terms?
>

I'm not sure. The browser processing model defines a list of low-entropy CH
headers:
https://wicg.github.io/client-hints-infrastructure/#low-entropy-table
I could point at that.


> ---
>
> 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?
>
> Maybe just a note pointing out that there is no mechanism for a server to
> inform a client whether it understands and supports the hints.
>
> ---
>
> 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?
>
> Yes, I think it is better.
>
> -------
>
> Regards,
>
> Christer
>
>