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

[Aaron Tagliaboschi via webkit-dev]

By default, the browser only sends the brand, major/significant version,
and whether or not the browser has signalled it wants a "mobile"
experience. Other than that, the browser only sends hints that the site has
signalled it wants through the Accept-CH response header.

If, for example, the browser has never visited the site before, then the
browser has never received an Accept-CH response header from that site and
therefore doesn't know that the site wants any extra headers. This also
happens when information about the site is clear, which also clears the
client hint preferences

It could also be that the site has changed the hints it wants to receive
since you last visited, in which case you might not have sent all of the
headers it actually wants.

In both cases, it's not that the browser is blocking the headers, but that
the preferences stored in the browser are out of sync with the preferences
of the site.

On Thu, Jan 28, 2021 at 10:53 PM Ryosuke Niwa  wrote:

> 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 
> 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  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
  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

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

[Ryosuke Niwa via webkit-dev]

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 
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  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
>>>  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

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

[Aaron Tagliaboschi via webkit-dev]

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  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
>>  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

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

[Ryosuke Niwa via webkit-dev]

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
>  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

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

[Aaron Tagliaboschi via webkit-dev]

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
 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