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
• GitHub repository: https://github.com/httpwg/http-extensions
• Issue Tracker (if not the repository's issue tracker): https://github.com/httpwg/http-extensions/labels/client-hints

Additional spec URL, repository, and issue tracker: https://wicg.github.io/client-hints-infrastructure/, https://github.com/WICG/client-hints-infrastructure, & https://github.com/WICG/client-hints-infrastructure/issues/.

Design reviews and vendor positions

• TAG Design Review:
• Mozilla standards-positions issue: Client Hints mozilla/standards-positions#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.

[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 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.

[litherum]

What's the difference between this and #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'.