Define "brand" and "full version" for CH-UA

[romainmenke]

see : https://datatracker.ietf.org/doc/html/draft-west-ua-client-hints-00#section-2

Examples :

In polyfill.io the User Agent string is used to determine the required polyfills to make a website work in specific browsers. (https://polyfill.io/v3/polyfill.js?features=fetch)

At Mr. Henry we use the User Agent string to determine which Javascript and CSS bundles will work correctly. We also split error reporting so that errors from old or obscure browsers do not cause signal overload for product teams. (change your UA to something older like IE 11 : https://www.mrhenry.be/supportdetails/)

The shared principle is that the underlying engine capabilities are important.
We do not care about the device, browser brand,...

Getting this right means that we can support more users while also saving bandwidth, cpu cycles, ...

One major challenge here are the non Safari browsers and webviews on iOS and Chromium based browsers like Edge, Samsung Internet, Opera, ...

A CriOS UA string (Chrome on iOS) does not contain this information today :

Mozilla/5.0 (iPhone; CPU iPhone OS 14_8 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/92.0.4515.90 Mobile/15E148 Safari/604.1

• CriOS/92.0.4515.90 is meaningless for this use case as it has no correlation to the underlying WebKit version that is actually used.
• Safari/604.1 has been frozen since Safari 11.

CriOS/92.0.4515.90 would fit the current definition of brand + full version but it wouldn't be useful (or at least not for me :) )

We could infer it from other parts and/or keep track of CriOS versions in a table. But this process is error prone and doesn't scale well because there are a lot of WebViews embedded in Apps.

---

My concern is that brand and full version are too vague in the current specification.

Maybe these values are not fit for my purpose?
But should it then be clarified that these values do not need to have any correlation with the browser engine?
Is there another header more appropriate for reliable engine capability detection?

[miketaylr]

Hi @romainmenke, thanks for the issue!

One major challenge here are the non Safari browsers and webviews on iOS and Chromium based browsers like Edge, Samsung Internet, Opera, ...

To confirm, you mean all browsers on iOS, correct? Or do you also mean webview on Android?

I agree that it would be nice if Chrome for iOS supported UA-CH (as well as Safari).

My concern is that brand and full version are too vague in the current specification.

Would you mind clarifying what you mean here?

[romainmenke]

To confirm, you mean all browsers on iOS, correct? Or do you also mean webview on Android?

I do not have an android device so I can not easily judge the situation on Android.

---

@romainmenke said :

My concern is that brand and full version are too vague in the current specification.

@miketaylr said :

Would you mind clarifying what you mean here?

The current behaviour for Chrome on iOS is to erase the information about the underlying engine in the user agent string. They replace it with CriOS/x.y.z.

The same is done by every other browser I could test in iOS except Brave. Brave chooses to preserve the actual information.

My concern is that brand and full version are too vague.
Do you list the brand and version of the label on the outside : CriOS x.y.z?
Or do you list the brand and version of the actual browser : Safari x.y.x?

The same issue exists for every Chromium based browser.
Is it Opera x.y.z or Chromium x.y.z.

This part of the specification is line with my concern :

While I'm optimistic that we can reset
expectations around sniffing by freezing the thing that's sniffed-
upon today, and creating a sane set of options for developers, it's
likely that this is hopelessly naive. It's reasonable to ponder what
we should do to encourage sniffing in the right way, if we believe
it's going to happen one way or another.

There are valid use cases for user agent sniffing for applications like polyfill.io.
These only intend to make as many websites work for as many people as possible.

But the current wording of the specification allows anything as brand and full version.
Also values which are non-bogus but still technically incorrect.

Requiring at least the inclusion of the underlying engine name and its version would be more useful in my opinion. But maybe this is not the intended use case for Sec-CH-UA?

[romainmenke]

To state it differently.

The current specification takes into account the anti-pattern of websites checking for older user agents and blocking end users from accessing content. It tries to prevent this with GREASE-like UA strings.

It however doesn't state anything that user agents must add correct information about their engine identity. (maybe I missed this completely)

To work through this issue both sides need to be done correctly.
User agents need to advertise correctly who they are and sites need to correctly parse and handle this information.