Chromium proposal to use client hints in parallel with diminished User-Agent headers
The role of the HTTP header 'User-Agent' might diminish in 2020 as future versions of Chromium may freeze and then replace the HTTP header. Google propose providing information about the device, operating system, browser, and architecture with a client hint implementation, which gives slightly more control to the user. The proposal is yet to be reviewed by the W3C and is open to consultation.
If adopted Cient Hints will require a few simple changes for a web site to continue to gain access to information about the device, browser, and operating system. It is almost identical to the techniques already needed to fully identify web browsers such as Opera or UC. As such 51Degrees data files and APIs already support the concepts of client hint User-Agent header without any modifications to the deployed API.
This blog provides a technical overview of the changes and explains how 51Degrees already supports the Client Hint User-Agent model.
Background
The proposed change to Client Hints appears to be driven out of a desire to improve the perception of privacy associated with web browsing.
The User-Agent string - a sequence of characters that can be used with 51Degrees and other device detection services - is perceived to represent a privacy risk as it contains limited non-personal information about the browser, operating system, and device. Users have little control (beyond their choice of web browser vendor) over the data that is sent about their device, operating system, or browser. Personal information should never be included in the User-Agent header. The assertion that a privacy risks exists is yet to be substantiated.
From an engineering perspective, the User-Agent string is inefficient as it contains many characters and is unstructured. 51Degrees has built a set of technologies specifically to make sense of these strings.
Client Hints could remove much of the complexity associated with identifying the browser, operating system, and device. Client Hints do not remove the need to maintain an accurate catalog of the associated device, browser, and operating system data.
User-Agents
A User-Agent is sent with every HTTP request to inform the web server, site, and service about the capabilities of the user's agent. Here's an example from a Pixel 2 XL.
Mozilla/5.0 (Linux; Android 8.0.0; Pixel 2 XL Build/OPD1.170816.0a04) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Mobile Safari/537.36
Algorithms developed by 51Degrees can turn this single string of characters into information about the device (Pixel 2 XL), operating system (Android 8), and browser (Chrome 79) with over 99.9% accuracy.
Such information is essential to analyze web traffic accurately, diagnose browser or device-specific issues such as slow performance of video rendering, and to adapt the web site to the specific capabilities of the device. Other use cases include.
- Providing web services such as news and commerce in developing countries.
- Dynamic creation of Content Security Policies (CSP).
- Programmatic advertising. Most recent standards have the single User-Agent string baked in.
- Understanding web traffic to improve experiences - analytics.
- Servicing applications to Android devices.
- Fraud and non-human identification services.
- Diagnosing slow performance or UI problems based on actual devices, not the high-end ones used exclusively by web professionals.
- Optimizing images and video.
User-Agent Client Hints
At the time of writing - mid-January 2020 - much detail is still needed concerning the specific information and the proposal is yet to be agreed. A summary of the various working papers and statements would suggest the following.
Unlike the User-Agent - which is sent out with every single web request - Client Hints in Chrome are likely only to hand out the information when two conditions are satisfied.
- the web site asks for the information, AND
- the user and the browser vendor allow it.
When the two conditions are satisfied, User-Agent clients will send the associated data in structured header fields during subsequent responses.
The W3C defines a complete list of Client Hints in the working paper, the User-Agent Client Hints Draft Community Group Report as.
| HTTP Header | Description |
|---|---|
| Sec-CH-Arch | Architecture of the platform. E.g. ARM64 |
| Sec-CH-Model | Model of the User-Agent. E.g. Pixel 2 XL |
| Sec-CH-Platform | Platform on which a given User-Agent is executing. E.g Android 8.0 |
| Sec-CH-UA | User-Agent’s branding and version. E.g. Chrome 79 |
| Sec-CH-Mobile | Information about whether a User-Agent prefers a 'mobile' user experience. E.g true or false. It’s not clear how a mobile is defined and by whom which is why this business prefers Sec-CH-Model to enable the web service to decide. |
Table 1- probable User-Agent Client Hint headers
They can be requested either via an HTTP response header or via the HTML <meta> element. An example of a possible implementation follows.
1. Via HTTP headers in the response from the webserver.
Accept-CH: Arch, Model, Platform, UA, Mobile
2. Via HTML.
<meta http-equiv='Accept-CH' content='Arch, Model, Platform, UA, Mobile'>
User-Agent data via Client Hints is unlikely to be available to third parties e.g., cloud analytical services, such as Google Analytics.
What does this mean?
The User-Agent string (not the same as a 'user's agent': the device, operating system, and browser they're using) as an unstructured sequence of characters was never an ideal method of providing the information.
The information it provides, when used responsibly, provides an invaluable tool for web professionals and businesses to understand how their web site is being used. For example; In these JavaScript intensive times, knowing what hardware the web page is running on helps identify performance issues beyond mobile and desktop. Afterall some mobiles cost $50, others over $1000. They are not the same, and web professionals need to know.
What to change?
Not all browsers, app, and crawlers will adopt the change.
Web professionals will need to adapt to the techniques used above and run both User-Agent header and client hint techniques for many years to come. 51Degrees data files and APIs already support the concepts of Client Hint User-Agent header without any modifications to the deployed API.
Data models that rely on a single string of characters to represent the User-Agent, for example, Open Real-Time Bidding in programmatic advertising - will need to be adjusted to either consolidate the client hint fields or follow the same data model. This will require cross-industry working in many cases.
What's changing?
51Degrees are well placed to help with the migration and automatically provide information about device, browser, and operating system when Client Hints become mainstream. For the majority of users, the main change will be to request client hint headers and provide these additional headers as evidence to the 51Degrees cloud or on-premise APIs.
Get Involved?
For those who feel the proposal has not been well thought through, relies on unproven techniques, and will diminish the web for a significant number of people - particularly in developing countries - getting in contact with Chromium is essential.
Two simple methods are to post on the following GitHub and Chromium groups.
Latest updates
Edited for 2022
Since this blog was written in early 2020, there's been a lot of updates surrounding User-Agent Client Hints. For the latest news, refer to our Client Hints blogs. We delve deeper User-Agent Client Hints with our blog User-Agent Client Hints: your questions answered, or you can see what values are returned with our Client Hints demonstration page.