Hi Yoav, I have not received the pull request yet, so I will comment only based on your e-mail reply :)
In general, I am happy with your explanations, and for most parts I think some text giving the explanations in the draft would be useful. ------- Major issues: MaQ1: >> Section 2.1. describes sending of Client Hints, based on Accept-CH, and >> Section 3.1. defines the Accept-CH header field. >> >> First, there is no guidance on what a client does BEFORE it receives >> Accept-CH. >> I assume it does not include support of any features. >> >> Second, there is no guidance on what a client does if it does NOT receive >> Accept-CH (because the server does not support it). Will it then send another >> request and include supported features ? What if it is too late, and the >> server >> has already made choises? >> >> I think some client behavior guidance would be useful. > > Generally, without an opt-in (either before Accept-CH is received or when the > server does not support it), clients SHOULD NOT send high-entropy hints, but > MAY send low-entropy ones. I think some guidance text would be useful. --- MaQ2: >> Related to Q3, there is not server procedure on when Accept-CH is sent to the >> client. Also, can an Accept-CH with updated information be sent? > > Servers which wish to receive client information through Client Hints SHOULD > add Accept-CH to their responses as early as possible. > Later Accept-CH response headers with updated information will override a > previous opt-in. Some text would be useful for both cases above. --- 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. --- MaQ4: >> Section 3.1 says: >> >> “It SHOULD be persisted and bound to the origin to enable delivery of >>Client >> Hints on subsequent requests to the server's origin.” >> >> …and the subsequent text then gives an example. >> >> First, what is the time scope of “subsequent requests”? A session? An hour? A >> day? For how long does the client need to remember the Accept-CH header field >> value for a given origin server? > > A session, so similar lifetime properties as session cookies. Add some text, please :) >> Second, the procedure does not seem to take into account that certain >> aspects, >> e.g., network characteristics, may change between when requests are sent to >> an >> origin server. > > It is the server preference that's persisted, not the specific information. > Varying client characteristics will result in varying Client Hints request > headers at different points in time. Ok. -------- 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. --- MiQ2: >> The 4th last paragraph of Section 1 says: >> >> “It also defines guidelines for content negotiation mechanisms that use it, >> colloquially referred to as Client Hints.” >> >> The 2nd last paragraph of Section 1 says: >> >> “This document defines Client Hints, a framework that enables servers >> to opt-in to specific proactive content negotiation features, >> adapting their content accordingly.” >> >> The 2nd last pargraph also talks about “usage of infrastructure”, which I >> don’t >> really understand. I assume you mean the Client Hints framework? >> >> First, I think the text in the 4th last paragraph should be replaced by the >> text in the 2nd last paragraph. >> >> Second, I think the text introducing the framework should come BEFORE the >> text >> introducing the Accept-CH header field. >> >> Something like: >> >> "This document defines Client Hints, a framework that enables servers >> to opt-in to specific proactive content negotiation features, >> adapting their content accordingly. This document also defines a new >> response header, Accept-CH, that allows an origin server to explicitly >> ask that clients send these headers in requests. >> >> Client Hints mitigate performance concerns by assuring that clients >> will only send the request headers when they're actually going to be >> used, and 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. >> >> The document does not define specific usages of Client Hints. Such usages >> Need to be defined in their respective specifications. >> >> One example of such usage is the User Agent Client Hints [UA-CH]." > > Makes sense. Thanks! :) ------- Nits/editorial comments: EdQ1: >> The document uses both “client” and “user agent” terminology. Is there a >> reason >> for that, or could one be picked? > > No reason in particular. We can probably stick to "client". Sounds good :) Thanks! Regards, Christer _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
