HTTP Client Hints + Client Hints Infrastructure

[gsnedders]

Request for position on an emerging web specification

• WebKittens who can provide input: @johnwilander

Information about the spec

• Spec Title: HTTP Client Hints + Client Hints Infrastructure
• Spec URL: https://www.rfc-editor.org/rfc/rfc8942.html + https://wicg.github.io/client-hints-infrastructure/
• GitHub repository: https://github.com/httpwg/http-extensions + https://github.com/WICG/client-hints-infrastructure
• Issue Tracker (if not the repository's issue tracker): https://github.com/httpwg/http-extensions/labels/client-hints + https://github.com/WICG/client-hints-infrastructure/issues/

Design reviews and vendor positions

• TAG Design Review: Various (not sure what to pick for the actual HTTP spec!)
• Mozilla standards-positions issue: https://github.com/mozilla/standards-positions/issues/79

Bugs tracking this feature

• WebKit Bugzilla:
• Radar:

Anything else we need to know

These two specs jointly define the underlying infrastructure and mechanisms of Client Hints, but don't actually specify any hints themselves. Filing this mostly to have something to then link to when we're asked for opinions on specific client hints, for general client hint infra discussion.

[rniwa]

Many of client hints have very questionable use cases like device memory being used as a proxy to estimate how fast a given device is. At the end, we probably need to evaluate each client hints separately.

[othermaciej]

I think we'd be interested in implementing the Client Hints infrastructure if and only if there are any specific client hints we want to implement. So in that sense we'd be neutral.

However, as written, Client Hints Infrastructure seems to require support for all client hints that exist (not 100% sure about this) because:

• It hooks into Fetch to require running "append client hints to request".
• append client hints to request collects the hint names that domain has requested (or had delegated to it) and runs "find client hint value" on each.
• find client hint value has a global switch of all the different client hint headers that exist, and requires returning a value for each per the many different referenced specifications.

Thus, to my reading, it's nonconforming to support Client Hint Infrastructure without supporting all Client Hints that currently exist (and I guess any that are added in the future). There doesn't seem to be leeway to support only some. Perhaps I'm misreading or this is merely bad drafting and not intended.

[miketaylr]

There doesn't seem to be leeway to support only some.

Yeah, that's not super intentional. UA-CH is explicit about allowing a UA to return empty or false values or only support hints it wants to: https://wicg.github.io/ua-client-hints/#fingerprinting. I can file a bug to make that more generalized in CH infra.

[karlcow]

• Gecko https://bugzilla.mozilla.org/show_bug.cgi?id=935216
• WebKit https://bugs.webkit.org/show_bug.cgi?id=241749
• Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=458983 (Implemented)

Compatibility risks:

User Agent Freezing

• Chromium is starting to freeze parts of the user agent string through UserAgent HTTP header and navigator.userAgent. Chrome doesn't have a flexible mechanism to handle breakage due to User Agent sniffing gone wrong such as Site Interventions in Firefox. Web developers will have to rely on Chrome Client Hints to get the right information. And this will push for Client Hints on the Web.
• Gecko has an open bug for freezing the user agent string too, but has the possibility to use Site Interventions to patch up any breakage, until the pressure of having client hints used by Web developers at large scale, will create enough wide spread webcompat issues because of the lack of client hints.
• WebKit is in a similar spot than Gecko. it has Quirks.cpp to fix some of the issues with freezing parts of the user agent string, until Client Hints become a large enough issue.

For now, the compatibility risks are minimum, but they are foreseeable.

[gsnedders]

WebKit https://bugs.webkit.org/show_bug.cgi?id=241749

This isn't the appropriate bug, as this is about Client Hints broadly, not about any specific hint.

User Agent Freezing

Likewise, that's a tangential risk to UACH, not CH broadly.

[o-t-w]

Does this include User-Agent Client Hints JavaScript API or is that a separate issue?

[gsnedders]

Does this include User-Agent Client Hints JavaScript API or is that a separate issue?

That makes sense as part of #70 (UACH).

[annevk]

I'm mildly concerned about the same-origin policy impact of the new request headers as discussed in https://github.com/WICG/client-hints-infrastructure/issues/100. There's an attempt at https://github.com/whatwg/fetch/pull/1434 to mitigate some of that, but it needs quite a bit of work and whether it can be rolled out retroactively remains to be seen I suppose.

[litherum]

What's the difference between this and https://github.com/WebKit/standards-positions/issues/70?

[eeeps]

@litherum This is for the general infrastructure to send hints, but does not specify any particular hints to send. #70 is for a particular set of hints. Some other proposed particular hints, for reference:

• https://wicg.github.io/responsive-image-client-hints/ (which I edit)
• https://tfpauly.github.io/privacy-proxy/draft-pauly-httpbis-geoip-hint.html

[gsnedders]

And see also #15 and #140 for other Client Hints we've been asked for positions on.

[hober]

I'm mildly concerned about the same-origin policy impact of the new request headers as discussed in WICG/client-hints-infrastructure#100. There's an attempt at whatwg/fetch#1434 to mitigate some of that, but it needs quite a bit of work and whether it can be rolled out retroactively remains to be seen I suppose.

It looks like this issue is still open & the fetch PR hasn't landed. Marking this as 'blocked'.