I'm still confused here. In what scenario would a browser decide to not send client hints but later decide it's okay to send them?
On Thu, Jan 28, 2021 at 7:13 PM Aaron Tagliaboschi <aaron...@chromium.org> wrote: > 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