Hi, The PR looks good to me! Thanks for addressing my issues! :)
Regards, Christer From: Yoav Weiss <y...@yoav.ws> Date: Thursday, 7 May 2020 at 13.02 To: Christer Holmberg <christer.holmb...@ericsson.com> Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "last-c...@ietf.org" <last-c...@ietf.org>, HTTP Group <ietf-http...@w3.org>, "draft-ietf-httpbis-client-hints....@ietf.org" <draft-ietf-httpbis-client-hints....@ietf.org> Subject: Re: Genart last call review of draft-ietf-httpbis-client-hints-13 Addressed the latest points in the PR. Thanks! :) On Wed, May 6, 2020 at 3:20 PM Yoav Weiss <y...@yoav.ws<mailto:y...@yoav.ws>> wrote: On Wed, May 6, 2020 at 2:43 PM Christer Holmberg <christer.holmb...@ericsson.com<mailto: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<https://protect2.fireeye.com/v1/url?k=6272da56-3cd23ac2-62729acd-86d2114eab2f-315dfc5e8e3bb7de&q=1&e=7281b4e2-8b12-45aa-b9cc-269841f1ac96&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fpull%2F1171> 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<https://protect2.fireeye.com/v1/url?k=6a29e40a-3489049e-6a29a491-86d2114eab2f-5ccf1f3eadf9c7d7&q=1&e=7281b4e2-8b12-45aa-b9cc-269841f1ac96&u=https%3A%2F%2Fwicg.github.io%2Fclient-hints-infrastructure%2F%23low-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
