I’ve been following the development of this initiative from Google more or less since it was first filed as a note on Github.

Yesterday, the Chrome team announced an “Intent to Deprecate and Freeze: The User-Agent string”.

Along with this intent, an intent to ship Client Hints infrastructure and UA Client Hints is published. “UA client hints” (UA-CH) is similar to the client hints we’ve seen around for a while now.

Why Change Perfectly Good Tires at 100 km/h?

The history of the User-Agent is long and proud, but it also carries a lot of legacy. The legacy itself is not a big deal by itself but the Chrome team seem to want a “fresh start”. However, privacy seem to be the most important motivation. (Google thinks Privacy is important! Sometimes…) The sudden focus on the privacy aspect of client hints, I’d guess is related to the push back a few years ago.

The official motivation of freezing the User-Agent header is to make it less useful for parties who use it for fingerprinting purposes. The idea is that if more devices have the same User-Agent string, the harder it is to fingerprint the user.

The fresh start is the “User Agent Client Hints“. More or less the same bits of info is available through the hints as in the User-Agent header, but it is claimed to be more secure as only the Sec-CH-UA header is sent by default. Availability of the other hints is governed by Feature Policies.

Whether this approach will address the original privacy concerns, remains to be seen.

Impact of the Change

First, let me emphasise that the impact of this is limited to Chrome browsers which is about 60% globally. The percentage varies a lot by continent and mobile/tablet/desktop use cases.

For some reason Google thinks doing content negotiation based on the User-Agent is a bad thing. Done right, this is called Device- or Feature Detection, done wrong it’s called “UA-sniffing”. From a user and UX perspective adapting content, presentation and experience to the browsing context is great, but apparently form an advertising and indexing perspective it’s a painful.

Personally I think Google is underestimating the impact of shipping the two intents with almost no time for the community to react and adapt.

Professionally, I’ve been hands on with the mobile web space and seen it develop for more than 15 years and I know that many, big and small, websites rely on device detection based on the User-Agent header. From Googles perspective it may seem easy to switch to the alternative UA-CH, but this is where the team pushing this change doesn’t understand the impact:

Functionality based on device detection is critical, widespread and not only in front end code. Huge software systems with backend code rely on device detection, as well as entire infrastructure stacks.

Websites, advertising platforms, analytics providers, security/fraud detection providers and other industries will have to do a lot of work to now support both device detection based on User-Agent AND UA-CH (yes both). May be a big thing if you’re not using a Device Detection solution.

The Process and Documentation

Is it the right approach that two people can push for such a big, potentially breaking change?

Don’t get me wrong!! Great, smart people(!) and I know that more people has been involved. But for such changes, a more formal process should be in place.

The amount, and quality, of the documentation is too low. 3-4 documents aimed at the web dev community on Github with high level explanations of functionality is not good enough. At the very least, example code and reference implementations on UA-CH and corresponding plumbing and interfaces to other standards should be available early in the process.

For example, what is the value of the sec-ch-ua-model hint intended to be? Have device manufacturers had their opinions heard?

The Alternative

Client Hints are not available on the very first navigation request (first page view). Origin Policies is supposed to address this issue, and I’m surprised that the team is pushing for UA-CH before there is a solution to get device- and bowser info on first navigation request! This is a show-stopper in my book! The Sec-CH-Mobile hint will address some of the issue but far from all cases. Luckily there is device detection software.

At a high level the sparse documentation outline how to use UA-CH in similar ways as the User-Agent. For example, to delegate device information to a 3rd party (for example an Image CDN serving images on your webpage) feature policies govern the security.

In Chrome Canary, with ‘Experimental Web Platform features’ enabled, this is meant to work. (Give it a try on this Glitch) It does not work, so I filed a bug. This illustrate the problem that the alternative is not ready for the web community, yet. At such a tight schedule, the tools, docs and infrastructure should work and be available for the community to play around with. It’s not.

Too Tight Schedule

Chrome Canary (v81) already send the sec-ch-ua header by default, but still with the defects outlined above, and the body of work that many stakeholders need to undertake, I think the schedule is too aggressive.

What About the Android Ecosystem?

Above I highlighted the proposed sec-ch-ua-model header. For many websites and apps, this header will be crucial to ensure good user experience.

The vanilla Chrome browser is not the big issue, but I’m thinking of customized browsers using the Blink engine, and apps with webviews for that matter, like the Samsung Internet browser. Vendors are still able to customize http headers, including the User-Agent as well as sec-ch-ua-model. Will vendors continue to update User-Agent in addition to possibly adding sec-ch-ua-model with a relevant identification?

Like explained, there are many good reasons to keep the User-Agent current. Especially for vendors within the Android eco system who have their own infrastructure. Samsung and Huawei for example. Which means that the impact of 60% mentioned above, is likely to be less.

Will UA Client Hints Work as Intended?

For passive fingerprinting, maybe. sec-ch-ua is still pretty useful for that purpose. The community has not been presented with statistics of the potential positive impact. Moreover, slightly more “active” fingerprinting is still possible by delegating access to all the hints using feature policy as plumbing.

The origin is of course in control of who gets access to the hints. Regardless, 3rd parties will have access to the hints. (Also, it’s going to be interesting to see how many * we’ll see in the Feature Policy declaration. Moreover, together with the “sister client hints” the fingerprinting will even be pretty accurate!

Device detection will still play an important role. Maybe Chrome will give more human-readable info than before, but having additional device and browser information available is still crucial for the same reasons and use cases which today depend on the User-Agent. The difference in the future is that device detection solutions will have to consider both the User-Agent header as well as the UA-CH headers.

What about legacy? Will UA-CH also start to carry legacy? I’ll leave that open…