The Critical-CH header can trigger a request re-try. It's for situations where the browser could be unaware of the site's CH preferences (like the first navigation request to a site before the browser has received and stored CH preferences) or if a site has changed those references, and the site would rather drop the request and retry over getting a potentially "incomplete" request
This would *not* override potential mitigations or reductions in fingerprinting surfaces imposed by the browser. Any headers that would be blocked would still be silently dropped. (cc davidben, mjs who I forgot to CC the first time) On Thu, Jan 28, 2021 at 9:35 PM Ryosuke Niwa <rn...@webkit.org> wrote: > What's the point of specifying Critical-CH as opposed to relying on CH > provided by the browser? > > Is the idea that some browsers may decide to hide some client hints to > reduce the fingerprinting surface? > If so, then this new header seems to just defeat that because a website > can specify all the client hints as critical. > > - R. Niwa > > On Wed, Jan 27, 2021 at 4:40 AM Aaron Tagliaboschi via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > >> Explainer: >> https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md#critical-ch >> Draft Spec: >> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02#section-3 >> >> The Client Hint Reliability proposal is a set of features aimed at making >> Client Hints >> <https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-15> more >> reliably available and mitigating >> mis-matches between a site's preferences and the preferences stored in >> the browser. The idea >> behind the Critical-CH response header is to signal to browsers that >> there are hints the server >> would rather pay a round trip than not have not the first request. The >> basic algorithm is as follows: >> >> If, after receiving a request with Critical-CH and Accept-CH headers, >> there is a hint indicated in >> the Critical-CH header that the browser did not send but would not block >> sending, the browser >> should store the new CH preferences, drop the request, and start a new >> one with the new >> headers included. >> >> Aaron Tagliaboschi | Software Engineer, Chrome Trust & Safety >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
