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.... Draft Spec: https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02#s...
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