The IE 11 user-agent forced Mozilla to freeze part of its user-agent string

Have more fun with your UA strings! Unclosed quotation marks, XXE strings, Shellshock, they might just earn you a bug bounty.

Maybe throw in the EICAR test string as well, getting their shitty antivirus to purge the log files may just help protect your privacy!

So it turned out that Chrome 93-95 had a weird issue with the video element: you couldn't replace the source attribute reliably. Unfortunately, that's something that mattered to us, so I had a hack in place that tested the browser version. It's still there in case someone hasn't updated their browser. Testing the feature was simply not possible. It was either that or just let (a large) part of our users get stuck on a frozen screen.

Feature testing is a lot harder when attempting to work around CSS bugs in cough cough Safari, unless you use weird things like @supports (<insert feature that vCurrent mobile Safari doesn't support but all other current browsers do>) and then hope it is fixed in a future Safari.

For your last point: that would be considered cute if you're attractive. Otherwise it's creepy.

Does anyone know of (or work on) an app still doing user-agent sniffing to determine browser features (as in, the sniffing code has been touched in the last ~decade)? If so, why do it that way?

> Client Hints are <del>the recommended</del><ins>Chrome's</ins> replacement for UA strings.

FTFY. Last I checked it's just a unilateral Chrome implementation, no one else recommends it.

"recommended"? That's just something that Chrome team created and no other browser vendor is interested in supporting it. Google seems to think that they can use their market dominance to force the idea.

The issue is that you often want to work around bugs in a browser. For instance, Safari technically supports a lot of features, but very often there are slight inconsistencies with other browsers. Would Safari’s capability be something like “capture-stream-with-bugs”?

The use of “Mozilla” I believe predates the Mozilla Foundation, as it was from Netscape’s user agent string before it was spun out. https://webaim.org/blog/user-agent-string-history/

You can't use trademark in that way if they would need it for compatibility. Nintendo made games have a "nintendo" title scroll on Gameboy and checked for it as "genuine cartridge" protection in a special chip, and sued third parties for trademark violations if they included the title scroll to get around the protection chip.

Courts ruled Nintendo couldn't use trademark in that way, that it was laundering in more rights than trademark provides.

No, the idea was right from the beginning that you could name (additionally) other user agents conforming to the same or lower specs as your client.

(Without this, it would have been nearly impossible to introduce a new browser. Mind that browsers were much more dissimilar in the early years. E.g., Netscape Navigator could access virtual hosts, while NCSA Mosaic, which didn't know about the host header field, could not. While some browsers came with JS, others, like Viola Web, followed a different scheme, more similar to HyperCard, etc. Therefore, a server may have well checked the user agent string in order to decide how to serve what content.)

Not when it's for compatibility and talking to a machine.

I doubt the user agent string would lead to a confusion of consumers, if consumers are end users and not web servers.

I don't think you can ban the use of a word with trademark if it does not cause confusion.

I think, there's still use for it. E.g., I recall when Chrome 32 would fail to play a newly created Web Audio BufferSource, unless the playback call came from inside a decodeAudioData() callback. At the same time, you couldn't use this approach to playback sound from e.g. Safari iOS, since the callback lacked the user interaction blessing, resulting in muted audio. Try-catch wasn't an option either, since, as soon as the playback failed over any attempt to play that node in the traditional way over a null-buffer exception, the source node was already expired and won't play at all. The only way to handle this situation was user agent sniffing in order to detect Chrome and to handle it as an edge case. (Mind that the API was still the same and there was no way to feature detect this behavior.) There's no guarantee that something like this won't happen again.

That's not possible: it assumes a perfect implementation. As I wrote in another comment: Chrome 93-95 had a weird issue with the video element. You can't test that in JavaScript. The feature exists, it just doesn't work correctly. You sometimes have to work around bugs in certain versions of certain browsers.

> Just force the switch to better methods.

I always thought software developers should have the needs of users in mind, but it turns out it's the other way around.

They had an opportunity to do that with HTTP/2, /3, but they kept the User Agent. It's a bit different, but it's still there.

I think this would be a great change to do alongside http/3 or something. That way we don't break old web sites.

Permanently end the pattern of rewarding extremely bad behavior from the past. This is so simple and would work.

This would break so many websites, which would have negative consequences for many people.

what are better methods?

"Webmasters" were told to use XHTML and they massively cried how that they just can't write correct code so they absolutely need sloppy parsers that would analyze the mess of unclosed tags and weirdly placed elements and try to understand the intent.

And the industry gave up. This is essentially the same story.

I guess, this is targeted at Apple's butterfly key switches, which were used in their 2015-2019 MacBooks and prone to fail due to dust and other small particle intrusions.

Compare: https://www.macrumors.com/guide/butterfly-keyboard-issues/

Looks like that's been replace by "Reduce User-Agent request header Reduce (formerly, "freeze") the amount of information available in the User-Agent request header. See https://www.chromium.org/updates/ua-reduction for more info. – Mac, Windows, Linux, ChromeOS, Android, Fuchsia, Lacros #reduce-user-agent"

It's not a bad idea for security either, as a way to combat fingerprinting efforts.

What? Since when? I just checked with useragentstring.com and the UA reports the same version I'm actually using.

I was under the impression that the User-Agent is kinda on its way out anyways.

I strongly suspect they’re referring to the aspects of the UA string specific to their own device. I.e. they used an MBP (whose vintage can be intuited from its notorious keyboard problems and) which has evidently stopped receiving OS updates past 10.15. Edit to add: I also suspect they thought this was a clever way to avoid some nerd inevitably chiding them to upgrade their OS, but it’s probably too clever to achieve that.

That honestly seemed a little unnecessary and made the whole thing confusing. I read it as: "This is only an issue on a MacBook, assuming that your s key sticks and the date is December 29th, 2022".

I suspect that the only part of that which is true is that the bug only occurs on macOS. The date or a sticky s keys isn't a prerequisite.

What would be more interesting is: Why isn't this an issue on Windows?

I presume that would unfortunately break websites in _other_ ways, if they're UA-sniffing Firefox in unconventional ways. At that point they might as well remove it altogether instead of drastically changing the UA string.

I'm with you for the most part. Today, with modern browsers on almost all devices and relatively high memory, compute and bandwidth capabilities - for certain.

However I can't agree with this:

> The UA header never had any business existing to begin with.

The early mobile web, and devices that were just too low-powered and/or low-bandwidth to support even early CSS/JS-based capabilities detection absolutely depended on server-side rendering to serve them mobile-HTML friendly sites.

Yeah, it was terrible, it was painful and insane to manage - but was necessary.

By default, I do not send a UA header. Mind you I use a text-only browser so I am not concerned with "responsive design", which is arguably one legit use for the UA header. The number of sites or hosting providers^1 that actually require a UA header in order to retrieve a webpage, let alone require a specific UA string, is relatively small. IME, they will fit in a short text file.^2 From firsthand experience I know that thousands of sites, i.e., from amongst the ones submitted to HN, do not require it. I suspect the true number of sites that do not require a UA header on the www is in the hundreds of millions. IMO, this is yet another incredible "tech" company stunt that there is currently so much commercially-related reliance on what is truthfully an optional header, and one that routinely contains "fake", i.e., arbitrary, data.

1. Or "website building companies" such as Squarespace.

2. The localhost-bound forward proxy adds a UA header for those few sites automatically.

At first I was like "Yeah buddy, preach on". Then came the next thought:

Then what. Site providers will still will want to know and this likely results in a browser detection excalation arms race pushed to JavaScript.

I still think servers shouldn't get to know so much about browser clients, certainly not PII-level details (PII-level being the norm as it exists today).

This. 100% this.

We live in the 21st century and have proper APIs to detect features now, we should not be relying on parsing this user-agent string which is 90% legacy-garbage anyways.

I mean, sites blocking compatible browsers is such a common problem that not only do user-agent switcher extensions exist, they're also some of the most popular extensions out there!

A side-effect of this will be web servers that won't allow scraping because your non-browser HTTP client won't have the same features that browsers have that also aid in profiling users for advertising.

We're already at a point where scraping can be hard without a full-fledged JS engine, a move towards feature detection will mean that you're going to have to use a browser that servers can easily fingerprint for ad targeting if you want to scrape data.

Chrome already deprecated UA strings 3 years ago. Google uses browser fingerprinting to detect if you're using Chrome so they can send you to working versions of their products, instead of the versions they send to other browsers that don't work as well.

I can see browsers being excluded if they aren't of the 'blessed' variety that either follows Chrome's implementation, or if they don't have features that advertisers want that allow for easy user identification/tracking/fingerprinting/etc.

While I generally agree with you I bristtle at the "just do what chrome does" sentiment.

Chrome and Google taken co trol of the standard in ways that generally aren't good for anyone.

This is just anti-competitive practice, yes? Presumably unlawful.