search

WICG / client-hints-infrastructure

Specification for the Client Hints infrastructure - privacy preserving proactive content negotiation
https://wicg.github.io/client-hints-infrastructure
Other
61 stars 26 forks source link

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

Closed miketaylr closed 2 years ago

miketaylr commented 2 years ago

Some feedback from https://github.com/WebKit/standards-positions/issues/20#issuecomment-1172062942

Some examples we should generalize here in Infra:

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

gsnedders commented 2 years ago

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

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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