On Wed, May 6, 2020 at 2:43 PM Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
