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

Please post a revised I-D when you’re ready; thanks.

Barry

On Thu, May 7, 2020 at 6:02 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Addressed the latest points in the PR. Thanks! :)
>
> On Wed, May 6, 2020 at 3:20 PM Yoav Weiss <yoav@yoav.ws> wrote:
>
>>
>>
>> On Wed, May 6, 2020 at 2:43 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://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
>>>
>>>