-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define "brand" and "full version" for CH-UA #124
Comments
Hi @romainmenke, thanks for the issue!
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).
Would you mind clarifying what you mean here? |
I do not have an android device so I can not easily judge the situation on Android. @romainmenke said :
@miketaylr said :
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 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 The same issue exists for every Chromium based browser. This part of the specification is line with my concern :
There are valid use cases for user agent sniffing for applications like polyfill.io. But the current wording of the specification allows anything as 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 |
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. |
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 ofbrand
+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
andfull 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?
The text was updated successfully, but these errors were encountered: