When I got started with the web 15 years ago, it was advised everywhere not to rely on user agent strings and rely on feature detection instead, and that using the user agent string should be a last resort solution.<p>Today, we are still seeing issues "solved" by switching one's user agents. And here we are reading Akamai whining about user agents getting unreliable. And we are talking unreliable <i>at the minor version</i> and specific platform version level.<p>It's not like we weren't warned ahead of time.<p>I'm sure problems will be sorted by proper http headers, data in handshakes or other things. And they should. Nobody should have to read user agent strings to optimize things, because things should also be optimized for a new, unknown user agent that would support these optimizations.
User agent strings are such a train wreck. I wish Chrome was braver and changed it to something like "Chromium (Blink, V8); Linux (Android)".
Eh. I guess I'm happy with any reduction of entropy in the UA string (which today almost contains your family name and dogs favorite meal in an unparseable string blob). But "client hints" seems like very little bang (device-specific cdn assets?) for the buck (an interactive, configurable and stateful protocol). And if this is for privacy reasons, but you can circumvent it by requesting client hints, then won't that end up an always-on default anyway that nobody benefits from in practice?<p>I guess if it's <i>fine</i> if users and devs don't need to think about it. OTOH, this is yet another barrier to competition in the browser space, which we desperately need to curb.<p>It seems like someone should overhaul the whole privacy mess with cookies, fingerprinting, user agents and other remnants from the 90s and take a <i>slightly</i> more principled approach to making a sane single standard, instead of adding hundreds of highly specific single-purpose headers and JS APIs.
While I am personally in favour of feature sniffing, rather than user agent sniffing, I think it's worth remembering the debacle about how the SameSite attribute on cookies was handled by the browsers a few years ago.<p>Several browsers shipped with an old implementation of the spec that is incompatible with the most recent, current version of the spec.<p>Setting the SameSite attribute to a specific value can result in the site working in newer browsers, but not in older browsers (or vice versa).<p>The only way to handle this is to sniff for a specific set of old browsers by user agent string, and to alter how cookies are set for those:<p><a href="https://www.chromium.org/updates/same-site/incompatible-clients/" rel="nofollow">https://www.chromium.org/updates/same-site/incompatible-clie...</a><p>Due to the prevalence of old iOS devices that can't be updated with a more modern browser (especially iPads), the company I work for has to keep this user agent sniffing in our codebases going forward.<p>If the user agent string is going to be deprecated or significantly weakened, there needs to be effort among browser vendors to avoid something like this ever happening again.
If only browsers had similar behavior across the platform and devices, user-agent wouldn’t be so useful to servers. They wouldn’t need to respond with customized content for each different user agent. As a developer, I’d prefer having to deal with at most a few dozen UAs instead of hundreds of specific ones.
Someone should also look into the "navigator" variable that websites can access. It provides a strangely open look into the user's machine.<p>For example, it allows websites to know about your OS, your CPU and your memory.<p>The "window" object also provides data that I would consider private. Like the screen size. Websites should only know the window size.<p>Demo: <a href="https://jsfiddle.net/uvtLc784/" rel="nofollow">https://jsfiddle.net/uvtLc784/</a>
Seems like a relevant time to bring up this old chestnut:<p><a href="https://webaim.org/blog/user-agent-string-history/" rel="nofollow">https://webaim.org/blog/user-agent-string-history/</a>
Similarly related, no longer being able to tell iPad OS and macOS apart server side was a major blow for us.<p>We have essentially “continue this in the app” buttons whose existence and how they passed state (iOS vs Android) was determined server side. We rewrote that all to happen client side because you can check “is it a Mac?” && “does it have multi-touch support?” And know it’s an iPad - at least until they build a touchscreen Mac.
This would sort itself out if browser implementations followed the standard and allowed us to set the user-agent ourselves.<p>Personally I would then set it to 1, 2 or 3 and have my server handle those cases.<p>Right now then ONLY user-agent code I have running is this:<p><pre><code> navigator.userAgent.indexOf('Android') == -1 && navigator.userAgent.indexOf('Other') == -1 && navigator.userAgent.indexOf('SamsungBrowser') == -1
</code></pre>
Good job Samsung/Google!