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-definiti... <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 <mjs@apple.com> wrote:
On Nov 2, 2020, at 8:56 AM, Yoav Weiss <yoav@yoav.ws <mailto:yoav@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@apple.com <mailto:mjs@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/141> https://github.com/WICG/ua-client-hints/issues/142 <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/143> https://github.com/WICG/ua-client-hints/issues/144 <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/145> https://github.com/WICG/ua-client-hints/issues/146 <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/147> https://github.com/WICG/ua-client-hints/issues/148 <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/149> https://github.com/WICG/ua-client-hints/issues/150 <https://github.com/WICG/ua-client-hints/issues/150> https://github.com/WICG/ua-client-hints/issues/151 <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@yoav.ws <mailto:yoav@yoav.ws>> wrote:
Yet-another ping! :)
On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss <yoav@yoav.ws <mailto:yoav@yoav.ws>> wrote: Friendly ping! :)
On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss <yoav@yoav.ws <mailto:yoav@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@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev <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