[webkit-dev] User Agent Client Hints
yoav at yoav.ws
Tue Nov 3 12:11:31 PST 2020
On Tue, Nov 3, 2020 at 8:03 PM Alex Christensen <achristensen at apple.com>
> 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
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:
> 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
> 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
> 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).
>> 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 :)
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev