How to make your concerns known to GoogleGet support for User Agent Client Hints
Information is present from the first request
Previously, all relevant information needed by the web server, especially the User Agent header which contains information about the hardware and software, was sent with every request by the client device.
The instant availability to the web server of the client device’s hardware and software helps to serve web content correctly and quickly; any delay in receiving information can negatively affect advertising bidding, and slow sites need to know which version of the site to load at the first request. Slow or suboptimal content would be served to users which will disproportionally harm people on older or cheaper devices.
Information is sent only once the server requests it
However, with the UA-CH “experiment” from Google, information is sent separately in a number of different HTTP headers. Many of these headers are sent only if the web server asks for them to be sent, which it does in its initial response. Because the web server may lack important information when it makes that response, the page it sends may not be optimized for the device and a delay is experienced.
Thus, it is only on subsequent requests that important UA-CH headers (such as device model) are sent.
The UA-CH draft unofficial community report (which is not even at the beginning stages of becoming a specification) states that the browser should remember the web server’s request to send the requested UA-CH headers, and therefore should send them in every request from the second request onwards. It does not define how long the browser should remember it for.
Assuming implementors of UA-CH, such as Google (via the Chromium browser source code), were to use the frequency of visits to a domain as a factor in remembering the UA-CH headers the domain requests, then this will benefit those domains that are bundled with the browser that are also operated by the web browser vendor. For example, it is conceivable that such a policy will benefit google.com which is bundled with the web browser and used frequently, and disadvantage other search engines such as Bing or DuckDuckGo.
Additionally, UA-CH headers are only sent in HTTPS connections, not HTTP and therefore can not be used to improve performance via proxy caches. Incidentally proxy caches were a major reason the web became the web as they enable intermediaries to store content closer to the user’s device.
When assessing increased latency there are two aspects to consider. Firstly, the server is not able to determine enough information on the first request to carry out necessary processing. Secondly, sending all the UA-CH headers separately makes the request bigger than it would otherwise be, therefore the whole process of making requests is slowed down. Our CEO and founder, James Rosewell, summarized this problem and offered simple improvements for Google at W3C. The suggestion was closed without any credible reason.
We’ve created a website to illustrate the latency impact you can expect from User Agent Client Hints: https://cma-uach-evidence.azurewebsites.net/. For example, a visit to that site shows a delay of 92ms from the first request through to the page being shown with UA-CH headers.
How can I avoid latency?
Google are aware of the latency issue within User Agent Client Hints. Within their first quarterly report to the UK Competition and Markets Authority (CMA), Google responded to concerns over the latency by saying they are investigating ways to improve performance. We’re skeptical anything will happen; as we have no idea how long this investigation may take, or whether they will fix the latency issues at all before wider deployment.
In this context, it’s worth mentioning a separate proposal called Critical-CH. At the time of writing, this doesn’t form part of the documentation that Google has presented relating to the rest of Client Hints, and we think it needs to be considered as unstable and speculative.
What Critical-CH adds to the mix is essentially the server requesting, in its response, “I really want these Client Hints”. But the browser may ignore the request. If it chooses not to ignore the request, then it can make the original request a second time. This doesn’t solve the round-trip latency issue and may confuse the situation even more as the server gets duplicate requests.
There are some suggestions from Google about how the server might be able to indicate Critical-CH as part of the process of the browser opening the connection to the server. However, these are just suggestions currently, and like the rest of Client Hints, it’s not clear to us how the standards community will view this work-around, nor how the changes that would be needed could make their way into web server software.
For more information on Critical-CH, please refer to the Client Hints infrastructure GitHub.
Unfortunately, until Google addresses the UA-CH latency issue, we are out of technical solutions. All of this is another example of Google dictating how the web should work, and in doing so favoring their own services. We’re sure you’d rather not be dealing with these challenges imposed by Google.
How can I make my concerns on latency known?
Google have set up a form that can be used to provide feedback either publicly or anonymously. They must comment in their reports to the CMA on entries raised with them.
We’ve raised our concerns surrounding the User Agent reduction and UA-CH loudly and clearly. We’ve explained that there is no justification for the change, and that it’s “privacy” is not acceptable for a resource used by most of the world. But we are a single voice.
We helped set up Movement for an Open Web (MOW) who have been campaigning against Google’s dominance within the digital market. If you’d like to make your concerns over Google’s proposals known, one way to do so is to join MOW. Email the group at email@example.com to express your interest in joining.
Alternatively, you can email your concerns directly to the CMA (who are overseeing Google’s Privacy Sandbox proposals) at firstname.lastname@example.org.