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>

> 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

Reply via email to