Re: [Gen-art] Genart last call review of draft-ietf-httpbis-client-hints-13

[Yoav Weiss <[e-mail]>]

On Thu, May 7, 2020 at 3:07 PM Barry Leiba <[e-mail]> wrote:

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

Will do as soon as the PR
<https://github.com/httpwg/http-extensions/pull/1171> is approved and
landed.


>
> Barry
>
> On Thu, May 7, 2020 at 6:02 AM Yoav Weiss <[e-mail]> wrote:
>
>> Addressed the latest points in the PR. Thanks! :)
>>
>> On Wed, May 6, 2020 at 3:20 PM Yoav Weiss <[e-mail]> wrote:
>>
>>>
>>>
>>> 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
>>>>
>>>>