Explainer: Reducing User-Agent Granularity(github.com)
github.com
Explainer: Reducing User-Agent Granularity
https://github.com/WICG/ua-client-hints
1 comments
There's two arguments I've heard against removing the User-Agent field:
"It helps us understand browser share" and "UA sniffing is faster than feature testing".
I believe both of these could be remedied quite easily with some minor work. Websites shouldn't have access to browser version, cpu architecture, model name etc by default. Websites with legitimate needs for this information can request access from the user and the user would be in charge of determining whether the website has earned the right to this information (useful for eg. sites that want to report "last login at [date] from [browser] on [platform]").
In terms of UA sniffing being faster than feature detection old browsers will continue to send their outdated User-Agent strings. Websites will simply have to opt to use feature detection in actively developed browsers.
In terms of the server determining whether it should serve a "lite" version of the site, there's potential in headers like "Save-Data: on". There's also research into headers that would send incredibly coarse information about the devices capabilities (eg memory available rounded down to nearest 1024^n bytes).
"It helps us understand browser share" and "UA sniffing is faster than feature testing".
I believe both of these could be remedied quite easily with some minor work. Websites shouldn't have access to browser version, cpu architecture, model name etc by default. Websites with legitimate needs for this information can request access from the user and the user would be in charge of determining whether the website has earned the right to this information (useful for eg. sites that want to report "last login at [date] from [browser] on [platform]").
In terms of UA sniffing being faster than feature detection old browsers will continue to send their outdated User-Agent strings. Websites will simply have to opt to use feature detection in actively developed browsers.
In terms of the server determining whether it should serve a "lite" version of the site, there's potential in headers like "Save-Data: on". There's also research into headers that would send incredibly coarse information about the devices capabilities (eg memory available rounded down to nearest 1024^n bytes).
> Websites with legitimate needs for this information can request access from the user and the user would be in charge of determining whether the website has earned the right to this information
That seems much like what the author is proposing: "User agents can make intelligent decisions about what to reveal in each of these attributes. Top-level sites a user visits frequently (or installs!) might get more granular data than cross-origin, nested sites, for example. We could conceivably even inject a permission prompt between the site's request and the Promise's resolution, if we decided that was a reasonable approach."
That seems much like what the author is proposing: "User agents can make intelligent decisions about what to reveal in each of these attributes. Top-level sites a user visits frequently (or installs!) might get more granular data than cross-origin, nested sites, for example. We could conceivably even inject a permission prompt between the site's request and the Promise's resolution, if we decided that was a reasonable approach."
> potential in headers like "Save-Data: on"
Yes, headers, if added, should be about the capabilities of the browser, not the browser vendor, the underlying OS or hardware.
Yes, headers, if added, should be about the capabilities of the browser, not the browser vendor, the underlying OS or hardware.
The problem with expressing capabilities is they will never be binary in the real world, and the feature set is growing constantly.
Often with emerging functionality, one vendor will do an experiment, other vendors will refine and it will go through the standards process. If Chromium first introduces `Whargarbl: On` and WebKit implements it differently, the header may become something like `Whargarbl: -webkit-frobnicate`. Dozens of headers like that may be sent.
This is almost certainly better suited to feature testing in the runtime.
Often with emerging functionality, one vendor will do an experiment, other vendors will refine and it will go through the standards process. If Chromium first introduces `Whargarbl: On` and WebKit implements it differently, the header may become something like `Whargarbl: -webkit-frobnicate`. Dozens of headers like that may be sent.
This is almost certainly better suited to feature testing in the runtime.
No doubt, feature detection is much better. There are a few things that needs to be on the header-level, like compression standards and encoding, but the less data is attached to a request by default, the better.
I completely agree. Adding additional headers seems silly.
My counter proposal to the original article:
* User-Agent is almost neutered. It should send something like:
User-Agent: Browser (I want data I am going to display)
User-Agent: API-Client (I want some other data, a javascript call, etc)
And nothing else. I might possibly accept differentiating between desktop and mobile browsers. The javascript Window.navigator.userAgent should also be limited in the same way. No sane code uses it for anything. Of course, in the real world there is insane code all over the place so I suspect my modest proposal is a non-starter.
My counter proposal to the original article:
* User-Agent is almost neutered. It should send something like:
User-Agent: Browser (I want data I am going to display)
User-Agent: API-Client (I want some other data, a javascript call, etc)
And nothing else. I might possibly accept differentiating between desktop and mobile browsers. The javascript Window.navigator.userAgent should also be limited in the same way. No sane code uses it for anything. Of course, in the real world there is insane code all over the place so I suspect my modest proposal is a non-starter.
Arguably browser vs. API client is already covered by the Accept header. A browser request has something like `Accept: text/html,application/xhtml+xml,[…]`, where an API client request has something like `Accept: application/json`.
If the client requests HTML, it’s a pretty safe assumption they want to have something display-able.
If the client requests HTML, it’s a pretty safe assumption they want to have something display-able.
It's not even arguably - you are right. But the Accept header is also a mess these days and a lot of requests don't set it.
I’ve been a full-time web dev since 2005, and I have never needed to sniff around in the User-Agent string. Having the server care about what browser is on the other end is an anti-pattern, makes life difficult for browser-developers (and caching systems), and helps creepy tracking software fingerprint people.
So instead of weighing down HTTP requests with a bunch of new headers next to no one will need, I think we should instead move to end browser-sniffing. Fix the User-Agent string like OP proposes, but add nothing to replace it.