Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

On Tue, Nov 3, 2020 at 8:03 PM Alex Christensen 
wrote:

> If I understand this correctly, the state of having received an Accept-CH
> header field in a response to a previous request is used to determine
> whether these new Sec-CH-* header fields will be sent.  Not only does this
> add a new place to store bits on the client (as acknowledged by
> https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition
>  )
> but it also seems to not provide a method for a server to receive client
> hint header fields on the first request from a client.  Would both of these
> concerns be resolved if we used something like ALPN instead of needing to
> store state on the client?
>

+David Benjamin 's Client Hints reliability proposal
and its ALPS part

are
planned to tackle something very similar to your ALPN proposal.

FWIW, the Accept-CH cache can only be set by HTTP response headers on the
top-level document, and are cleared whenever client state (e.g. cookies)
are cleared. So while it is another place to store state, it doesn't
outlive current same-origin client-side storage.

 Am I understanding the Client Hints Infrastructure correctly?
>
> On Nov 2, 2020, at 3:32 PM, Maciej Stachowiak  wrote:
>
>
>
> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
>
> Thanks for re-reviewing, Maciej!
>
> Adding Mike Taylor, who's likely to take a closer look at this.
>
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:
>
>>
>> I just did a fresh review of that spec and explainer. Thanks for
>> addressing many of the previous issues. This addresses many of the
>> potential objections.
>>
>> Here’s the new issues I filed:
>>
>> https://github.com/WICG/ua-client-hints/issues/141
>> https://github.com/WICG/ua-client-hints/issues/142
>> https://github.com/WICG/ua-client-hints/issues/143
>> https://github.com/WICG/ua-client-hints/issues/144
>> https://github.com/WICG/ua-client-hints/issues/145
>> https://github.com/WICG/ua-client-hints/issues/146
>> https://github.com/WICG/ua-client-hints/issues/147
>> https://github.com/WICG/ua-client-hints/issues/148
>> https://github.com/WICG/ua-client-hints/issues/149
>> https://github.com/WICG/ua-client-hints/issues/150
>> https://github.com/WICG/ua-client-hints/issues/151
>>
>>
> Thanks for filing those! We'll take a look and respond shortly.
>
>
>> Most of these are minor/editorial, but I think 151 is potentially a
>> deal-breaker. I may be misreading the spec, but as written
>> getHighEntropyValues seems to give access to all of the high entropy client
>> hints to third-party scripts in the first party context, and scripts
>> running in third-party iframes, regardless of which ones the site has opted
>> into via the relevant HTTP header.
>>
>
> That's indeed the case, as we didn't consider the Client Hints opt-in to
> be something that impacts the availability of the JS API. (as it doesn't do
> that for other hints)
>
>
> We’re currently deeply skeptical of implementing any of the other client
> hints due to their expansion of fingerprinting surface, so I don’t feel
> particularly compelled by that precedent. That said, it’s likely the other
> client hints have this same problem, where they expose fingerprinting
> surface way more widely than they may be intending to.
>
> That would be a huge problem, as it would grant a lot of active
>> fingerprinting surface unnecessarily
>>
>
> We did discuss
>  
> adding
> a Feature Policy (now Permission Policy) to that effect. Would that help
> with your concerns?
>
>
> My understanding is that feature policy applies at the frame level, and
> therefore could not be used to control what happens when a third-party
> script in a first party context calls the API. Even for third-party
> iframes, it seems like Feature Policy could only default-deny this JS API
> entirely, and would not be able to filter the results down to the set
> delegated via HTTP headers (or otherwise). Maybe you intend a feature
> policy per individual high entropy hint, but first of all that seems like
> overkill, and second, the spec is clearly not written to support such
> filtering.
>
> So no, it would not address the concerns.
>
> I think the best approach is to limit the hints to those opted into (or,
> in case of a third-party frame, delegated). That or remove the script API
> entirely. The origin-based delegation model that works well at the HTTP
> level is not well aligned with the widespread practice of including
> third-party scripts in the top frame.
>
> The spec does not eve allow denying the request entirely as written. A
> non-normative Note suggests that is allowed, but I can’t find any step in
> the algorithm that would ever reject the promise.
>
>
>
>> (perhaps even expanding beyond what is currently possible with the UA
>> string).
>>
>
> Can you expand on 

Re: [webkit-dev] User Agent Client Hints

[Alex Christensen]

If I understand this correctly, the state of having received an Accept-CH 
header field in a response to a previous request is used to determine whether 
these new Sec-CH-* header fields will be sent.  Not only does this add a new 
place to store bits on the client (as acknowledged by 
https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition 

 ) but it also seems to not provide a method for a server to receive client 
hint header fields on the first request from a client.  Would both of these 
concerns be resolved if we used something like ALPN instead of needing to store 
state on the client?  Am I understanding the Client Hints Infrastructure 
correctly?

> On Nov 2, 2020, at 3:32 PM, Maciej Stachowiak  wrote:
> 
> 
> 
>> On Nov 2, 2020, at 8:56 AM, Yoav Weiss mailto:y...@yoav.ws>> 
>> wrote:
>> 
>> Thanks for re-reviewing, Maciej!
>> 
>> Adding Mike Taylor, who's likely to take a closer look at this.
>> 
>> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak > > wrote:
>> 
>> I just did a fresh review of that spec and explainer. Thanks for addressing 
>> many of the previous issues. This addresses many of the potential objections.
>> 
>> Here’s the new issues I filed:
>> 
>> https://github.com/WICG/ua-client-hints/issues/141 
>> 
>> https://github.com/WICG/ua-client-hints/issues/142 
>> 
>> https://github.com/WICG/ua-client-hints/issues/143 
>> 
>> https://github.com/WICG/ua-client-hints/issues/144 
>> 
>> https://github.com/WICG/ua-client-hints/issues/145 
>> 
>> https://github.com/WICG/ua-client-hints/issues/146 
>> 
>> https://github.com/WICG/ua-client-hints/issues/147 
>> 
>> https://github.com/WICG/ua-client-hints/issues/148 
>> 
>> https://github.com/WICG/ua-client-hints/issues/149 
>> 
>> https://github.com/WICG/ua-client-hints/issues/150 
>> 
>> https://github.com/WICG/ua-client-hints/issues/151 
>> 
>> 
>> 
>> Thanks for filing those! We'll take a look and respond shortly.
>>  
>> Most of these are minor/editorial, but I think 151 is potentially a 
>> deal-breaker. I may be misreading the spec, but as written 
>> getHighEntropyValues seems to give access to all of the high entropy client 
>> hints to third-party scripts in the first party context, and scripts running 
>> in third-party iframes, regardless of which ones the site has opted into via 
>> the relevant HTTP header. 
>> 
>> That's indeed the case, as we didn't consider the Client Hints opt-in to be 
>> something that impacts the availability of the JS API. (as it doesn't do 
>> that for other hints)
> 
> We’re currently deeply skeptical of implementing any of the other client 
> hints due to their expansion of fingerprinting surface, so I don’t feel 
> particularly compelled by that precedent. That said, it’s likely the other 
> client hints have this same problem, where they expose fingerprinting surface 
> way more widely than they may be intending to.
> 
>> That would be a huge problem, as it would grant a lot of active 
>> fingerprinting surface unnecessarily 
>> 
>> We did discuss 
>>  
>> adding a Feature Policy (now Permission Policy) to that effect. Would that 
>> help with your concerns?
> 
> My understanding is that feature policy applies at the frame level, and 
> therefore could not be used to control what happens when a third-party script 
> in a first party context calls the API. Even for third-party iframes, it 
> seems like Feature Policy could only default-deny this JS API entirely, and 
> would not be able to filter the results down to the set delegated via HTTP 
> headers (or otherwise). Maybe you intend a feature policy per individual high 
> entropy hint, but first of all that seems like overkill, and second, the spec 
> is clearly not written to support such filtering.
> 
> So no, it would not address the concerns.
> 
> I think the best approach is to limit the hints to those opted into (or, in 
> case of a third-party frame, delegated). That or remove the script API 
> entirely. The origin-based delegation model that works well at the HTTP level 
> is not well aligned with the widespread practice of including third-party 
> scripts in the top frame.
> 
> The spec does not eve allow denying the request entirely as written. A 
> non-normative Note suggests 

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

Thanks for the background. Let's continue to discuss on the issue.

On Tue, Nov 3, 2020 at 12:32 AM Maciej Stachowiak  wrote:

>
>
> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
>
> Thanks for re-reviewing, Maciej!
>
> Adding Mike Taylor, who's likely to take a closer look at this.
>
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:
>
>>
>> I just did a fresh review of that spec and explainer. Thanks for
>> addressing many of the previous issues. This addresses many of the
>> potential objections.
>>
>> Here’s the new issues I filed:
>>
>> https://github.com/WICG/ua-client-hints/issues/141
>> https://github.com/WICG/ua-client-hints/issues/142
>> https://github.com/WICG/ua-client-hints/issues/143
>> https://github.com/WICG/ua-client-hints/issues/144
>> https://github.com/WICG/ua-client-hints/issues/145
>> https://github.com/WICG/ua-client-hints/issues/146
>> https://github.com/WICG/ua-client-hints/issues/147
>> https://github.com/WICG/ua-client-hints/issues/148
>> https://github.com/WICG/ua-client-hints/issues/149
>> https://github.com/WICG/ua-client-hints/issues/150
>> https://github.com/WICG/ua-client-hints/issues/151
>>
>>
> Thanks for filing those! We'll take a look and respond shortly.
>
>
>> Most of these are minor/editorial, but I think 151 is potentially a
>> deal-breaker. I may be misreading the spec, but as written
>> getHighEntropyValues seems to give access to all of the high entropy client
>> hints to third-party scripts in the first party context, and scripts
>> running in third-party iframes, regardless of which ones the site has opted
>> into via the relevant HTTP header.
>>
>
> That's indeed the case, as we didn't consider the Client Hints opt-in to
> be something that impacts the availability of the JS API. (as it doesn't do
> that for other hints)
>
>
> We’re currently deeply skeptical of implementing any of the other client
> hints due to their expansion of fingerprinting surface, so I don’t feel
> particularly compelled by that precedent. That said, it’s likely the other
> client hints have this same problem, where they expose fingerprinting
> surface way more widely than they may be intending to.
>
> That would be a huge problem, as it would grant a lot of active
>> fingerprinting surface unnecessarily
>>
>
> We did discuss
>  
> adding
> a Feature Policy (now Permission Policy) to that effect. Would that help
> with your concerns?
>
>
> My understanding is that feature policy applies at the frame level, and
> therefore could not be used to control what happens when a third-party
> script in a first party context calls the API. Even for third-party
> iframes, it seems like Feature Policy could only default-deny this JS API
> entirely, and would not be able to filter the results down to the set
> delegated via HTTP headers (or otherwise). Maybe you intend a feature
> policy per individual high entropy hint, but first of all that seems like
> overkill, and second, the spec is clearly not written to support such
> filtering.
>
> So no, it would not address the concerns.
>
> I think the best approach is to limit the hints to those opted into (or,
> in case of a third-party frame, delegated). That or remove the script API
> entirely. The origin-based delegation model that works well at the HTTP
> level is not well aligned with the widespread practice of including
> third-party scripts in the top frame.
>
> The spec does not eve allow denying the request entirely as written. A
> non-normative Note suggests that is allowed, but I can’t find any step in
> the algorithm that would ever reject the promise.
>
>
>
>> (perhaps even expanding beyond what is currently possible with the UA
>> string).
>>
>
> Can you expand on that last point?
>
>
> I mean that the client hints might include info that is not in the UA
> sting (possibly not at all, or possibly frozen in UA string but could be
> unfrozen in the client hints).
>
>
>
>>
>> Regards,
>> Maciej
>>
>>
>> On Oct 27, 2020, at 12:35 AM, Yoav Weiss  wrote:
>>
>> Yet-another ping! :)
>>
>> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  wrote:
>>
>>> Friendly ping! :)
>>>
>>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:
>>>
 Hi WebKit folks,

 Circling back on the previous discussion
  about
 User-Agent ClientHint. The feature was implemented in Chromium and is being
 rolled out in Chrome.

 There were some concerns mentioned in the previous thread, that we
 believe were since addressed. Would the feature be something that WebKit
 would consider shipping?

 Cheers :)
 Yoav

>>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
___
webkit-dev mailing list

Re: [webkit-dev] User Agent Client Hints

[Maciej Stachowiak]

> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
> 
> Thanks for re-reviewing, Maciej!
> 
> Adding Mike Taylor, who's likely to take a closer look at this.
> 
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  > wrote:
> 
> I just did a fresh review of that spec and explainer. Thanks for addressing 
> many of the previous issues. This addresses many of the potential objections.
> 
> Here’s the new issues I filed:
> 
> https://github.com/WICG/ua-client-hints/issues/141 
> 
> https://github.com/WICG/ua-client-hints/issues/142 
> 
> https://github.com/WICG/ua-client-hints/issues/143 
> 
> https://github.com/WICG/ua-client-hints/issues/144 
> 
> https://github.com/WICG/ua-client-hints/issues/145 
> 
> https://github.com/WICG/ua-client-hints/issues/146 
> 
> https://github.com/WICG/ua-client-hints/issues/147 
> 
> https://github.com/WICG/ua-client-hints/issues/148 
> 
> https://github.com/WICG/ua-client-hints/issues/149 
> 
> https://github.com/WICG/ua-client-hints/issues/150 
> 
> https://github.com/WICG/ua-client-hints/issues/151 
> 
> 
> 
> Thanks for filing those! We'll take a look and respond shortly.
>  
> Most of these are minor/editorial, but I think 151 is potentially a 
> deal-breaker. I may be misreading the spec, but as written 
> getHighEntropyValues seems to give access to all of the high entropy client 
> hints to third-party scripts in the first party context, and scripts running 
> in third-party iframes, regardless of which ones the site has opted into via 
> the relevant HTTP header. 
> 
> That's indeed the case, as we didn't consider the Client Hints opt-in to be 
> something that impacts the availability of the JS API. (as it doesn't do that 
> for other hints)

We’re currently deeply skeptical of implementing any of the other client hints 
due to their expansion of fingerprinting surface, so I don’t feel particularly 
compelled by that precedent. That said, it’s likely the other client hints have 
this same problem, where they expose fingerprinting surface way more widely 
than they may be intending to.

> That would be a huge problem, as it would grant a lot of active 
> fingerprinting surface unnecessarily 
> 
> We did discuss 
>  
> adding a Feature Policy (now Permission Policy) to that effect. Would that 
> help with your concerns?

My understanding is that feature policy applies at the frame level, and 
therefore could not be used to control what happens when a third-party script 
in a first party context calls the API. Even for third-party iframes, it seems 
like Feature Policy could only default-deny this JS API entirely, and would not 
be able to filter the results down to the set delegated via HTTP headers (or 
otherwise). Maybe you intend a feature policy per individual high entropy hint, 
but first of all that seems like overkill, and second, the spec is clearly not 
written to support such filtering.

So no, it would not address the concerns.

I think the best approach is to limit the hints to those opted into (or, in 
case of a third-party frame, delegated). That or remove the script API 
entirely. The origin-based delegation model that works well at the HTTP level 
is not well aligned with the widespread practice of including third-party 
scripts in the top frame.

The spec does not eve allow denying the request entirely as written. A 
non-normative Note suggests that is allowed, but I can’t find any step in the 
algorithm that would ever reject the promise.

>  
> (perhaps even expanding beyond what is currently possible with the UA string).
> 
> Can you expand on that last point?

I mean that the client hints might include info that is not in the UA sting 
(possibly not at all, or possibly frozen in UA string but could be unfrozen in 
the client hints).

>  
> 
> Regards,
> Maciej
> 
> 
>> On Oct 27, 2020, at 12:35 AM, Yoav Weiss > > wrote:
>> 
>> Yet-another ping! :)
>> 
>> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss > > wrote:
>> Friendly ping! :)
>> 
>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss > > wrote:
>> Hi WebKit folks,
>> 
>> Circling back on the previous discussion 
>>  about 
>> User-Agent ClientHint. The feature was implemented in Chromium and is being 
>> rolled out in 

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

Thanks for re-reviewing, Maciej!

Adding Mike Taylor, who's likely to take a closer look at this.

On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:

>
> I just did a fresh review of that spec and explainer. Thanks for
> addressing many of the previous issues. This addresses many of the
> potential objections.
>
> Here’s the new issues I filed:
>
> https://github.com/WICG/ua-client-hints/issues/141
> https://github.com/WICG/ua-client-hints/issues/142
> https://github.com/WICG/ua-client-hints/issues/143
> https://github.com/WICG/ua-client-hints/issues/144
> https://github.com/WICG/ua-client-hints/issues/145
> https://github.com/WICG/ua-client-hints/issues/146
> https://github.com/WICG/ua-client-hints/issues/147
> https://github.com/WICG/ua-client-hints/issues/148
> https://github.com/WICG/ua-client-hints/issues/149
> https://github.com/WICG/ua-client-hints/issues/150
> https://github.com/WICG/ua-client-hints/issues/151
>
>
Thanks for filing those! We'll take a look and respond shortly.


> Most of these are minor/editorial, but I think 151 is potentially a
> deal-breaker. I may be misreading the spec, but as written
> getHighEntropyValues seems to give access to all of the high entropy client
> hints to third-party scripts in the first party context, and scripts
> running in third-party iframes, regardless of which ones the site has opted
> into via the relevant HTTP header.
>

That's indeed the case, as we didn't consider the Client Hints opt-in to be
something that impacts the availability of the JS API. (as it doesn't do
that for other hints)

That would be a huge problem, as it would grant a lot of active
> fingerprinting surface unnecessarily
>

We did discuss

adding
a Feature Policy (now Permission Policy) to that effect. Would that help
with your concerns?


> (perhaps even expanding beyond what is currently possible with the UA
> string).
>

Can you expand on that last point?


>
> Regards,
> Maciej
>
>
> On Oct 27, 2020, at 12:35 AM, Yoav Weiss  wrote:
>
> Yet-another ping! :)
>
> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  wrote:
>
>> Friendly ping! :)
>>
>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:
>>
>>> Hi WebKit folks,
>>>
>>> Circling back on the previous discussion
>>> 
>>> about User-Agent ClientHint. The feature was implemented in Chromium and is
>>> being rolled out in Chrome.
>>>
>>> There were some concerns mentioned in the previous thread, that we
>>> believe were since addressed. Would the feature be something that WebKit
>>> would consider shipping?
>>>
>>> Cheers :)
>>> Yoav
>>>
>> ___
> 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] User Agent Client Hints

[Maciej Stachowiak]

I just did a fresh review of that spec and explainer. Thanks for addressing 
many of the previous issues. This addresses many of the potential objections.

Here’s the new issues I filed:

https://github.com/WICG/ua-client-hints/issues/141 

https://github.com/WICG/ua-client-hints/issues/142 

https://github.com/WICG/ua-client-hints/issues/143 

https://github.com/WICG/ua-client-hints/issues/144 

https://github.com/WICG/ua-client-hints/issues/145 

https://github.com/WICG/ua-client-hints/issues/146 

https://github.com/WICG/ua-client-hints/issues/147 

https://github.com/WICG/ua-client-hints/issues/148 

https://github.com/WICG/ua-client-hints/issues/149 

https://github.com/WICG/ua-client-hints/issues/150 

https://github.com/WICG/ua-client-hints/issues/151 


Most of these are minor/editorial, but I think 151 is potentially a 
deal-breaker. I may be misreading the spec, but as written getHighEntropyValues 
seems to give access to all of the high entropy client hints to third-party 
scripts in the first party context, and scripts running in third-party iframes, 
regardless of which ones the site has opted into via the relevant HTTP header. 
That would be a huge problem, as it would grant a lot of active fingerprinting 
surface unnecessarily (perhaps even expanding beyond what is currently possible 
with the UA string).

Regards,
Maciej


> On Oct 27, 2020, at 12:35 AM, Yoav Weiss  wrote:
> 
> Yet-another ping! :)
> 
> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  > wrote:
> Friendly ping! :)
> 
> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  > wrote:
> Hi WebKit folks,
> 
> Circling back on the previous discussion 
>  about 
> User-Agent ClientHint. The feature was implemented in Chromium and is being 
> rolled out in Chrome.
> 
> There were some concerns mentioned in the previous thread, that we believe 
> were since addressed. Would the feature be something that WebKit would 
> consider shipping? 
> 
> Cheers :)
> Yoav
> ___
> 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] User Agent Client Hints

[Yoav Weiss]

Yet-another ping! :)

On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  wrote:

> Friendly ping! :)
>
> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:
>
>> Hi WebKit folks,
>>
>> Circling back on the previous discussion
>> 
>> about User-Agent ClientHint. The feature was implemented in Chromium and is
>> being rolled out in Chrome.
>>
>> There were some concerns mentioned in the previous thread, that we
>> believe were since addressed. Would the feature be something that WebKit
>> would consider shipping?
>>
>> Cheers :)
>> Yoav
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

Friendly ping! :)

On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:

> Hi WebKit folks,
>
> Circling back on the previous discussion
> 
> about User-Agent ClientHint. The feature was implemented in Chromium and is
> being rolled out in Chrome.
>
> There were some concerns mentioned in the previous thread, that we believe
> were since addressed. Would the feature be something that WebKit would
> consider shipping?
>
> Cheers :)
> Yoav
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] User Agent Client Hints

[Yoav Weiss]

Hi WebKit folks,

Circling back on the previous discussion
 about
User-Agent ClientHint. The feature was implemented in Chromium and is being
rolled out in Chrome.

There were some concerns mentioned in the previous thread, that we believe
were since addressed. Would the feature be something that WebKit would
consider shipping?

Cheers :)
Yoav
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev