Make it clear that UAs are not required to support every client hint ever

[miketaylr]

Some feedback from WebKit/standards-positions#20 (comment)

Some examples we should generalize here in Infra:

https://wicg.github.io/savedata/#privacy-considerations
https://wicg.github.io/ua-client-hints/#fingerprinting

[gsnedders]

There's various places where we have lists of client hints in infra:

• https://wicg.github.io/client-hints-infrastructure/#client-hints-token
• https://wicg.github.io/client-hints-infrastructure/#policy-controlled-client-hints-features
• https://wicg.github.io/client-hints-infrastructure/#low-entropy-hint-table
• https://wicg.github.io/client-hints-infrastructure/#find-client-hint-value

Honestly, I'm not sure any of these are really worthwhile to have in the CH infrastructure spec.

Consider for the first:

A client hints token is a byte-lowercase representation of a Client Hint header field name.

For the policy-controlled features, we probably want each spec defining CH headers to contain the default allowlist, so that each spec defining its headers can discuss the privacy & security ramifications of that default allowlist.

For the low entropy hint table, the same applies.

For find client hint value, can we not just say something like:

When asked to find client hint value, given hint as input, if the implementation supports a Client Hint header whose field name is hint, it must return a suitable field value for that header. Otherwise, [???].

[gsnedders]

I guess fundamentally: it's not clear how this is a registry. The section appears to have various normative requirements, and be referenced by normative text.

[miketaylr]

I guess fundamentally: it's not clear how this is a registry. The section appears to have various normative requirements, and be referenced by normative text.

It's sort of in a transitional state IMHO. Ideally the normative bits are specced in HTML and Fetch (@arichiv has some in-flight PRs for this, or will at some point), and then what remains is the registry covering token names and permission policy defaults, etc. At that point it probably doesn't make sense for the document to be called "Infrastructure".

[miketaylr]

For find client hint value, can we not just say something like:

When asked to find client hint value, given hint as input, if the implementation supports a Client Hint header whose field name is hint, it must return a suitable field value for that header. Otherwise, [???].

That sounds good to me, as long as we have a sensible idea for what the Otherwise is. 😄

[gsnedders]

(The other thing that I didn't bother filing an issue for is "what does it mean for a field value to be 'suitable'")