Support User Agent Client Hints

[heowc]

I recently heard about the deprecated UserAgent header. Do you plan to add related content?

See https://wicg.github.io/ua-client-hints/

[ZacSadan]

+1

[paz-pm]

+1

[heowc]

Do you have loadmap this issue? 🤔

[nicjansma]

Hi!

Tagging a few of the maintainers to get their opinion: @commenthol @elsigh @tobie

Does the project have a plan or roadmap for how to incorporate Client Hints (or, to explicitly be blind to Client Hints)?

With Chrome's roadmap for the reduction and freezing of the User-Agent string, we're fast approaching when the Chrome UA will start to change by default:

• Chrome 92 (July 2021): JavaScript developer warnings accessing .userAgent
• Chrome 95-100: Sites can opt-in to frozen UA for testing
• Chrome 100 (March 2022): Sites can opt-out of UA freezing (until May 2023)
• Chrome 101 (April 2022): Version reduced to NN.0.0.0
• Chrome 107 (Oct 2022): Desktop platform frozen (hardcoded)
• Chrome 110 (Feb 2023): Mobile platform frozen (hardcoded)
• Chrome 113 (May 2023): Sites can no-longer opt-out of UA deprecation

Starting with Chrome 101+, the UA version will be frozen to NN.0.0.0, and in Chrome 107+ desktop UAs will start lying in the platform (because it will be frozen).

Obviously Chrome isn't the only UA in the world, but it likely accounts for a large % of website traffic.

To drive home how this may affect things in 2023+, this is what a Mac may report (when Client Hints are requested):

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.0.0 Safari/537.36
Sec-CH-UA-Full-Version: "93.0.4577.82"
Sec-CH-UA-Platform: "macOS"
Sec-CH-UA-Platform-Version: "12.0.1"

In the above case, Intel Mac OS X 10_15_7 is hard-coded (even for current newer versions of Mac OSX, such as Monterey 12.0.1), and 93.0.0.0 only provides the major version (instead of 93.0.4577.82). To really understand the user-agent characteristics, you would want to prioritize the Sec-CH-UA-* values over the User-Agent string.

A similar issue already exists today for Windows 11 detection. The Windows 11 UA string (on Edge/Chrome/Opera) will say Windows 10.0 while the Sec-CH-UA-Platform-Version Client Hint will give the correct answer of 13.0.0 (for Windows 11). Today's ua-parser YAML only ever returns Windows 10.

Consumers of libraries like ua-parser will start seeing incorrect data, if they don't incorporate the Sec-CH-UA-* values. What's not clear to me is if the ua-parser library itself should try to do this.

Some ideas for how this library could be updated to support Client Hints:

Proposal 1 - ua-parser identifies frozen UA strings

• The YAML rules could detect "frozen" User-Agent strings and give a signal to consumers so they know the UA may be "lying" about some aspects.
• For example, Intel Mac OS X 10_15_7 is fronzen and will likely be wrong. A new frozen attribute could be set if it detects the frozen UA.
• The consuming application would take this hint and prioritize Client Hints, or something.
• Downside: I'm not sure this would help consuming applications much, as a Client Hint-aware application would probably always prioritize Client Hints over UA-parsed values

Proposal 2 - ua-parser consumes and prioritizes Client Hints' data

• The reference implementations could be updated to incorporate any known Sec-CH-* Client Hint headers when querying it, such as prioritizing those hints over the existing RegEx rules.
• The YAML probably wouldn't need to be updated
• Downside: This would probably be a lot of work to update all of the languages

Proposal 3 - ua-parser is blind to Client Hints

• Don't make any changes to the regex or reference implementations
• Add documentation so that consumers understand how Client Hints may be more reliable and should be prioritized
• Downside: Everyone consuming ua-parser will have to write their own application logic to incorporate Client Hints

I'm sure there are more ways to approach this, but understanding what this library intends to support may help consumers (like my company) decide if we want to wait for (or build) that support into ua-parser, or just handle Client Hints in our own application.

Some additional resources:

• https://www.chromium.org/updates/ua-reduction/
• https://web.dev/user-agent-client-hints/
• https://github.com/WICG/ua-client-hints
• https://useragent.me/post/user_agent_client_hints

[nicjansma]

One additional benefit of Proposal 2 (ua-parser consumes and prioritizes Client Hints' data) is to help standardize the logic for situations like Windows 11 detection.

Windows 11 will have a Sec-CH-UA-Platform-Version: 13.0.0 (or higher). That 13.x should be "translated" to be Windows 11 logically.

[nicjansma]

@commenthol @elsigh @tobie @romenrg @cherio @mattrobenolt @dmolsen sorry to ping a few of you directly, but I think this issue deserves some attention as the timeline for the Chrome User-Agent to be frozen is fast-approaching:

• Chrome 92 (July 2021): JavaScript developer warnings accessing .userAgent
• Chrome 95-100: Sites can opt-in to frozen UA for testing
• Chrome 100 (March 2022): Sites can opt-out of UA freezing (until May 2023)
• Chrome 101 (April 2022): Version reduced to NN.0.0.0
  • <----- we're here
• Chrome 107 (Oct 2022): Desktop platform frozen (hardcoded)
• Chrome 110 (Feb 2023): Mobile platform frozen (hardcoded)
• Chrome 113 (May 2023): Sites can no-longer opt-out of UA deprecation

In 3 months the Chrome Desktop platform will be frozen, as Mobile platform will be next Feb. In those cases, the platform version will be incorrect unless Client Hints are taken into account in some way.

If there aren't any plans to update ua-parser to consume Client Hints (Proposal 3 above) that's fine! But I think at least a documentation update may be warranted to raise awareness.

[heowc]

In the long run, I think Proposition 1 can be inefficient. So I like suggestion 2 more. 👍

[commenthol]

@nicjansma

Thanks for your proposals.

The purpose of this library is to parse the User-Agent Header and returns information on Browser, OS, and brand model.
It is unaware of the underlying network protocols and HTTP-Headers.

The Client-Hints approach requires the server to interact with the client using the Accept-CH and maybe others.
With this, the returned client values are not required to be parsed by this library any longer.
Furthermore, values should be far more accurate than what this library extracts.

This means that ua-parser should not prioritize or judge values from Client-Hints as it can't do that. This would always require some logic outside ua-parser (Proposal-3).

Therefore I would see this interaction with Client-Hints outside the scope of ua-parser. For legacy browsers not supporting Client-Hints I still see ua-parser as a valuable, but fading, source.

[nicjansma]

That's a fair assessment @commenthol. I would suggest a documentation update for uap-core and/or some of the reference libraries then, possibly pointing to this issue or a brief summary of how a consumer of ua-parser should also incorporate Client Hints.

I can help with that type of documentation if it would be accepted into the README.

[commenthol]

HI @nicjansma ,
Happy to hear that the proposed is well received. Yes please feel free to create a PR with your recommendations on how clients might use uap-core together with client hints.
I'd suggest to create a separate document in ./docs and link this from the README.md as I can imagine that the recommendation might require their space.
What do you think?

[untitaker]

I think there is definitely merit in a library that takes a list of http headers, parses all information possible out of it and returns the data in exactly the same format as uap-core-based libraries do. This would be very useful to build drop-in replacements that have to return the same exact browser names etc as uap-core has.

I am not saying this has to be part of uap-core, and there is definitely more setup required from the developer to get the same amount of information (requesting high-entropy fields etc), but this could be a piece of logic that can be factored out.