Should the Accept-CH header restrict hints available in Navigator?

[AramZS]

I'm unclear on the intent of the interaction (if any) between the Accept-CH header and the Navigator-level function getUserAgent.

I would assume (and I would prefer) that any client hint not marked as accepted in the header set by the server-response should not be available to javascript operating on the page? But this isn't fully clear in the given documentation. I tested this in Canary (presumably the intended design of the feature) and did not get the expected result.

Page tested with: https://ua-client-hints-test.glitch.me/?client_hints_to_exclude=Arch

Code: https://glitch.com/edit/#!/ua-client-hints-test?path=server.js:38:56

You will note that on 2nd load the server, as expected, does not read a sec-ch-ua-arch value, however the navigator.getUserAgent function does return that value.

Is that the intended behavior?

[yoavweiss]

The intent is for the page to opt-in to receiving the information it requires. The page can do that in the form of a Client Hints (using Accept-CH headers) or in the form of accessing the getUserAgent method and its returned values.

So, having the API work even if the server has not requested the Client Hints is WAI. Closing, but let me know if you have further questions.

[AramZS]

That covers my question, thanks!

[jonarnes]

@yoavweiss related to the ticket, I understand the getUserAgent() should be available even without using Accept-CH headers. However, shouldn't the API at least be governed by a Feature-Policy? At least for 3rd parties?

[yoavweiss]

At least as defined right now, the Feature Policy is restricting the exposure of the information through Client Hints but not through getUserAgent().

[jonarnes]

From a fingerprinting- and ua-sniffing (or should I say "hint sniffing") perspective I struggle to see the logic behind that differentiation.

• Any 3rd party script included get access to detailed information about the user-agent without the origins knowledge or permission
• Even if passive fingerprinting is restricted, not restricting active fingerprinting through javascript seems like a missed opportunity. Especially for 3rd parties, but also for 1st party IMO.
• Personally I would not consider a 3party used getUserAgent() as an opt-in. It should be the 1st party opting in, and delegating to the 3rd party.
• By requiring an effort to opt-in, one could also assume a more informed use of the information made available with less regex hacks etc. which is one of the reasons the User-Agent has developed as it has.

I'd propose a feature policy is required to access getUserAgent() when sec-fetch-site is cross-site for example.

[yoavweiss]

#37 seems like a better approach to achieve the same: an opt-in that enables limiting 3P exposure to getUserAgent.

Let's continue the discussion there