51Degrees user update on UACH
Summary
51Degrees already provides some support for Google’s User-Agent Client Hints (UACH) across all versions of our device detection products.
We have waited for the final version of UACH to be made publicly available in Chrome 89 before making a set of additional changes to our version 4 source code and data to provide complete support.
Google have confirmed there is no set timeframe for the deprecation or interference with the existing User-Agent HTTP header. The UK’s Competition and Market Authority (CMA) are also investigating so called “Privacy Sandbox”. We expect Google to wait for that investigation to conclude before removing any further features from their products, including the User-Agent.
This blog provides some background concerning the change and explains to 51Degrees users the lobbying efforts we support to reverse UACH. Also included are the modifications we will be making in Q2 2021 to fully support UACH based device detection, prior to the general release of Chrome 91 (assuming those lobbying efforts are not successful).
Article
51Degrees see two approaches to the User-Agent Client Hint (UACH) changes being advanced exclusively by Google.
The first is to lobby regulators and the industry to rethink both the problem seeking to be solved and the solution being advanced. This approach is far from certain and will require many more voices, but it is gaining traction as the digital market wake up to the death of the open web after 25 years.
The second approach is to modify the 51Degrees version 4 products to add complete support for UACH as delivered in Chrome 89.
This blog explains both approaches.
Take me to the techy bitsTyranny
51Degrees were quick to recognize the information asymmetries that would result from the so called “Privacy Sandbox”, the competition implications, and the fact that people’s privacy would not improve.
How are people more private when their directly identifiable personal information (name, address, email, and telephone number) can be attached to their entire web activity by a single company? Google comply with laws like GDPR by capturing consent via a one-sided contract when using essential services like maps, search, email, or setting up a mobile phone. Such contracts are likely illegal if ever tested in court.
“Privacy Sandbox” is merely a veil to provide legitimacy to what the Texas Attorney General describes as Google’s plan "to create a walled garden around the internet in which it controls websites and mobile applications”.
It is therefore gratifying that authoritative voices such as Oracle and the CMA have come out in support of these arguments. More voices are needed urgently.
51Degrees owner and CEO, James Rosewell, founded Marketers for an Open Web for two primary reasons. One was to provide anonymity to complainants engaging with regulators. The other was to work with other groups such as the Save Journalism Project, to advocate for an open and decentralized web that limits the tyranny of Google hegemony.
Are you continuing to steal from people?
UACH are one of 23 proposals that form “Privacy Sandbox”. While UACH may not get the headlines of the third-party cookie, it is similarly impactful and justified on the same flawed premise. Like the film Minority Report, UACH is justified on the basis of future crimes and a desire of some to prevent bad acts before they occur. While people have free will, bad acts occur. Unlike Google, 51Degrees does not advocate for police states that seek to limit freedoms.
In the case of UACH, Google say they wish to prevent so called “fingerprinting”. This a term that uses neural linguistic programming (NLP) to make the reader think of crimes. Others call the use of multiple signals to form a pseudo anonymous non personal identifier, or a “probabilistic identifier”. “Fingerprinting” and “probabilistic identifier” mean the same thing. The environment has become riddled with crime or violent language such as “threat” or “abuse”.
User-Agents, IP addresses, or the fonts available, all support good use cases such as fraud detection, performance improvements, optimizations of user interfaces, analytics and cost optimization, or market analysis among others. Like all technologies, from stones to uranium, they can be used by bad people to perform bad acts and in doing so, break laws. No one is yet to propose solutions that help law enforcers identify bad acts and bad actors. They need to.
To embrace UACH, and the 22 other proposals in “Privacy Sandbox”, feels like accepting that we have committed a bad act in the past. It is like answering the question “Are you continuing to steal from people?”. It is an impossible question to answer if you’ve never stolen anything before.
Nevertheless, we know our users rely on our innovative, fast, and high-quality device detection solutions to support their businesses and use cases. This is why we have adopted UACH whilst continue to vocally oppose Google and the W3C’s position on privacy.
Okay. What is changing?
Version 4.3 of 51Degrees will include support for the version of UACH shipped by Google in Chrome 89. Version 4.3 will be generally available across all APIs for .NET, Java, PHP, Python, NGINX, Node, and Varnish plus our cloud services ahead of the release of Chrome 91 in May 2021. Other APIs including HAProxy and Go will follow later in the year.
Developers will need to upgrade their device detection version for on-premise or cloud to version 4.3 when it is released to make use of UACH.
Components
51Degrees operates a data model for device detection that includes four components.
- Hardware – the model of device
- Platform – the operating system
- Software – the application or web browser
- Crawler – details about the robots, if present
Graphs
Each component has a series of graphs that are used to rapidly turn the evidence provided in the HTTP request to the requested structured properties and values associated with each component. For example, model XYZ is converted to price band, battery capacity, or release age in month.
If only the information associated with the hardware model is needed, then there is no need to waste computing power evaluating other components. This is a feature of 51Degrees that enables superior performance compared to alternative solutions.
Version 4.3 will provide additional graphs for each of the four components using the evidence from specific additional UACH header values when they are present, instead of the existing User-Agent HTTP header value.
New UACH Headers
UACH provides the following additional HTTP headers.
Name | HTTP Header Name | Description |
---|---|---|
brand | Sec-CH-UA | The User-Agent's commercial name (for example: "cURL", "Edge", "The World’s Best Web Browser") |
significant version | Sec-CH-UA | The User-Agent's marketing version, which includes distinguishable web-exposed features (for example: "72", "3", or "12.1") |
full version | Sec-CH-UA-Full-Version | The User-Agent's build version (for example: "72.0.3245.12", "3.14159", or "297.70E04154A"). Google has since deprecated this field, and are urging developers to use Sec-CH-UA-Full-Version-List instead. |
platform brand | Sec-CH-UA-Platform | The User-Agent's operating system’s commercial name. (for example: "Windows", "iOS", or "AmazingOS") |
platform version | Sec-CH-UA-Platform-Version | The User-Agent's operating system’s version. (for example: "NT 6.0", "15", or "17G") |
platform architecture | Sec-CH-UA-Arch | The User-Agent's underlying CPU architecture (for example: "ARM", or "x86") |
model | Sec-CH-UA-Model | The User-Agent's device model (for example: "", or "Pixel 2 XL") |
mobileness | Sec-CH-UA-Mobile | A boolean indicating if the User-Agent's device is a mobile device. (for example: ?0 or ?1) |
To simplify device detection, these headers will be grouped together for each of the three components that are impacted by UACH. The following table indicates the mapping between 51Degrees components and UACH headers.
Component | Headers |
---|---|
Browser | UA,UA-Full-Version |
Platform | UA-Platform,UA-Platform-Version |
Hardware | UA-Model,UA-Mobile,UA-Arch |
Accept-CH
Unfortunately, these additional headers are not all provided by default in the first HTTP request to a domain. They have to be requested by setting a response header in the initial response called Accept-CH. This will lead to performance problems and excessive data transfer. 51Degrees has raised an issue at the W3C concerning this problem, but it is yet to be acknowledged by Google.
In the meantime, we will provide new properties that must be added to the list of required properties to automatically set the Accept-CH response header value in APIs that can manipulate the HTTP response.
These new properties are shown in the following table alongside their description.
Property Name | Description | Example Value |
---|---|---|
SetHeaderBrowserAccept-CH | Represents the User-Agent’s brand,major version and User-Agent's full version. | "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99", "89.0.4389.72" |
SetHeaderHardwareAccept-CH | Represents User-Agent Model and a boolean value indicating if the User-Agent is a mobile device. | "SM-A515F",?0 |
SetHeaderPlatformAccept-CH | Represents User-Agent operating system and the version | "Windows", "10.0" |
These property values will be returned on first request based on the browser version and whether it is known to support UACH. For example, initially only Chrome 89 onwards will return these values. If the browser does not support UACH then these values will not be returned and there will be no attempt by 51Degrees to make use of UACH.
Enabling
The APIs will add the values returned from these properties to the response header only when these properties are included in the required properties list. Therefore, when creating the 51Degrees pipeline these properties will need to be included in the required properties list. See the following example Java code to indicate what is required.
Cloud
Users of the cloud service will also need to add these properties to the list of available properties when configuring their resource key.
Default headers
Current versions of 51Degrees support the HTTP header for browser name and version added by UACH by default to all web requests. This is the sec-ch-ua header and is shown below.
sec-ch-ua: “Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"
These new values introduce a concept called GREASE to both randomize the value and make parsing harder. This can be seen in the bolded text ";Not A Brand";v="99". 51Degrees ignores this information and has proposed changes at W3C to remove these unnecessary characters that merely serve to increase the data consumption and environmental footprint of the web.
Technically, it does matter if these characters remain, or are removed. By using the 51Degrees device detection solution, the results will always be reliable and normalized against a common structured data model.
Offline Processing
We sincerely hope that Google will abandon UACH as currently implemented and rethink. We are working hard via Marketers for an Open Web and W3C engagement to achieve this outcome. However, if this is not successful then data models that store User-Agents for subsequent offline processing will need to be modified to include the additional field names and values provided by UACH. This is a change that offline, or batch processors of HTTP header information, should plan for now.
Modify to reduce data overhead and migration complexity · Issue #200 · WICG/ua-client-hints · GitHub
Listen to more background
Earlier in the year, 51Degrees founder and CEO, James Rosewell, appeared on popular web podcast the F-Word with Bruce Lawson. Listen to the episode and understand more about why these changes are so important to the future of the open web.
It is disappointing Google are yet to respond or engage on these issues.