Explainer: Reducing User-Agent Granularity(github.com) |
Explainer: Reducing User-Agent Granularity(github.com) |
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.
"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).
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."
Yes, headers, if added, should be about the capabilities of the browser, not the browser vendor, the underlying OS or hardware.
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.
If the client requests HTML, it’s a pretty safe assumption they want to have something display-able.
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.