[webkit-dev] User Agent Client Hints

Tue Nov 3 12:11:31 PST 2020

On Tue, Nov 3, 2020 at 8:03 PM Alex Christensen <achristensen at apple.com>
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 <davidben at chromium.org>'s Client Hints reliability proposal
and its ALPS part
<https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md#application-layer-protocol-settings>
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 <mjs at apple.com> wrote:
>
>
>
> On Nov 2, 2020, at 8:56 AM, Yoav Weiss <yoav at 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 <mjs at apple.com> 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
> <https://github.com/WICG/ua-client-hints/issues/37#issuecomment-576730548> 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 <yoav at yoav.ws> wrote:
>>
>> Yet-another ping! :)
>>
>> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss <yoav at yoav.ws> wrote:
>>
>>> Friendly ping! :)
>>>
>>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss <yoav at yoav.ws> wrote:
>>>
>>>> Hi WebKit folks,
>>>>
>>>> Circling back on the previous discussion
>>>> <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031195.html> 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 at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
> _______________________________________________
> 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/20201103/e1272417/attachment.htm>