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

[Ryosuke Niwa]

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/75dd1070/attachment.htm>