[webkit-dev] Request for position: Critical-CH response header, part of Client Hints Reliability proposal

[Aaron Tagliaboschi]

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 <rniwa at 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 at 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 at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210128/106ea5fa/attachment.htm>