Please post a revised I-D when you’re ready; thanks. Barry
On Thu, May 7, 2020 at 6:02 AM Yoav Weiss <y...@yoav.ws> wrote: > Addressed the latest points in the PR. Thanks! :) > > On Wed, May 6, 2020 at 3:20 PM Yoav Weiss <y...@yoav.ws> wrote: > >> >> >> On Wed, May 6, 2020 at 2:43 PM Christer Holmberg < >> christer.holmb...@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 >>> >>>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
