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

https://miketaylr.com/posts/2022/12/how-the-IE-11-ua-string-broke-sites-in-firefox.html

by glandium • 4 years ago

216 121 4 years ago

miketaylr.com

benj111• 4 years ago

I get this warning for TSB in the UK. I was wondering why, despite having the latest version.

Spivak• 4 years ago

The more this happens the more Chrome deciding to freeze the UA string forever makes sense.

LightHugger• 4 years ago

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

Nextgrid• 4 years ago

Which is also exactly why it ended up being reverted.

PenguinCoder• 4 years ago

User agent strings aren't reliable for fingerprinting users or devices already. Shouldn't be using them as high fidelity IOCs. But yeah, some still do. Much better ways to fingerprint users or devices on HTTP/websites.

ape4• 4 years ago

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"

chungy• 4 years ago

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

Hamuko• 4 years ago

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

Dalewyn• 4 years ago

Perhaps reflective of the times.

A browser becomes less and less an agent of the user with each passing day.

olliej3• 4 years ago

Yeah, all browser developers have tried to essentially freeze the UA, if nothing else to stop keying site behaviour off random subsets of it. For example here is my UA:

    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Safari/605.1.15

Which is all sorts of frozen (old os version, intel on an arm device, etc)

zitterbewegung• 4 years ago

Are they talking about only MacBook Pros with Intel chips since they reference Butterfly keyboards or is that sarcasm that sort of feels out of place ?

eyelidlessness5• 4 years ago

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.

auscompgeek2• 4 years ago

Mozilla froze the macOS version in User-Agent strings past Catalina too, also due to web compatibility issues (particularly with older versions of the Unity game engine).

Other engines do the same as well: https://www.otsukare.info/2021/02/15/capping-macos-user-agen...

eyelidlessness5• 4 years ago

I welcome any correction or explanation for why my comment was unhelpful.

mrweasel• 4 years ago

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?

jrochkind12• 4 years ago

In retrospect, wasn't putting "Mozilla" in your user-agent string when you aren't the Mozilla Foundation or project a trademark violation, that they could have enforced?

rmccue• 4 years ago

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/

jdsully• 4 years ago

They would have passed on the trademark rights with the rest of the IP

rileymat2• 4 years ago

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.

eyelidlessness5• 4 years ago

On the other hand, the whole reason UA strings are such a mess is because they have a long history of confusing humans who program computers. And being used sometimes intentionally for that purpose. And being used sometimes intentionally to mitigate that.

cma3• 4 years ago

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.

jrochkind12• 4 years ago

ah, righto. thanks for specific case history example. and indeed i'm glad of this.

It's weird in this case because it's not Mozilla itself that was requiring Mozilla in the user-agent string for a site to allow or support the browser, but third-parties, who Mozilla didn't encourage or particularly want to do that, as far as I know.

But it's still probably true that it would not be enforceable under trademark for this and other reasons, okay.

I wonder if Firefox has ever considered taking "Mozilla" _out_ of their user-agent! At this point it's probably impossible. We're just stuck with this mess.

mattl2• 4 years ago

This isn’t quite right. The BIOS checks for a copy of the Nintendo logo/name in certain ways on boot because licensed games include a copy.

Nintendo also manufactured the games which made this easier.

Vogtinator• 4 years ago

Do you have sources for such rulings? I'm only aware of the very similar https://en.wikipedia.org/wiki/Sega_v._Accolade.

Dylan16807• 4 years ago

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

masswerk7• 4 years ago

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.)

fortnum• 4 years ago

The title is clickbait. If anyone forced here anything, then it was not IE but - once again - webmasters who don't deserve that "title" ;)

drdaeman• 4 years ago

"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.

MBCook4• 4 years ago

I know it would be a temporary disaster but I think at this point I wish Safari, FF, Chrome and Edge would just decide on a flag day to get rid of user agents.

From March 17th, 2023 (or whatever) all user agent strings are now “WebBrowser/1.0” until the end of time.

Just force the switch to better methods.

logicallee• 4 years ago

what are better methods?

MBCook4• 4 years ago

Just check if the thing you want is defined in JS. Maybe add some supplementary methods to help with that kind of check.

Parsing out the UA header mess is a disaster.

masswerk7• 4 years ago

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.

Bick2• 4 years ago

Also this:

https://catchjs.com/Blog/SameSiteCookies

woojoo666• 4 years ago

That just sounds like a browser bug though. Client side code shouldn't try to work around it, the website should just notify all users that Chrome is broken and won't play audio properly

323• 4 years ago

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.

oleganza• 4 years ago

HTTP/2 is more like a transport envelope around HTTP/1, the goal of http/2 was to optimize transmission and avoid breaking http/1 semantics for servers and clients.

josephg• 4 years ago

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

tag2103• 4 years ago

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

zagrebian3• 4 years ago

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

tgv3• 4 years ago

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.

ris58h3• 4 years ago

What if Chrome had other bug that you can't work around? Users just would have to update it. It is that simple.

feyman_r• 4 years ago

Client Hints are the recommended replacement for UA strings. I believe the default behavior for Chromium browsers is already changing (looking for schedule link).

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hin...

inthepipe• 4 years ago

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”?

oefrha2• 4 years ago

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.

zagrebian3• 4 years ago

Well, Chrome and Edge.

rwalle• 4 years ago

"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.

azinman2• 4 years ago

If it’s an improvement, why is that a bad thing? I do expect them to lead if they’re in a dominant position. Sitting idly would be the wasted opportunity.

bobse3• 4 years ago

Teams are broken under Firefox
change useragent to egde/chrome
it works now

Thank you Microsoft.

pbhjpbhj2• 4 years ago

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

bobse3• 4 years ago

This is Rajesh and welcome to Microsoft forums. Please install Microsoft Edge TM. Bye.

olliej3• 4 years ago

No, it's just standard web developer laziness. They haven't made it IE only, they just broke the less popular browser, and likely anything else that is not chrome/blink, because chrome/blink is the new IE: its bugs define "correct behavior" it shipping something means "it's standard", no different from the "IE is the internet" era (and just like chrome there was a long period where IE was the best browser, before devs started targeting it alone).

tzot• 4 years ago

So rv0110.0 would not work?

auscompgeek2• 4 years ago

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.

masswerk7• 4 years ago

I can well see some non-trivial issues with `parseInt()`…

  if (paseInt(revMajor) === 72) { … } // rev 0110 detected!

;-)

Hizonner2• 4 years ago

Stop sending User-Agent. Replace it with nothing. Not client hints. Nothing.

If sites start rejecting Firefox clients because of that, then instead change it to send exactly the same User-Agent (and other software identification) that Chrome sends, and commit to exactly faking Chrome's signals in the future.

The UA header never had any business existing to begin with. Servers guessing client capabilities from the software they're running, or trying to work around client bugs, is architecturally insane, concentrates power excessively, and guarantees that morons will write bugs like the one this story is about. And the other uses of the information are simply evil.

If you need to signal specific capabilities, which you generally should not be doing because you shouldn't have punted all real attempts at standardization years ago, then signal specific capabilities. Or let the server try stuff and give only success or failure feedback.

metadat• 4 years ago

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).

Hizonner2• 4 years ago

You can't stop fingerprinting. I wish you could, but you can't.

But you CAN make it enough of a pain to cut down on the number of half-qualified Web monkeys who try to use the information in ham-handed ways. You can stop just handing the information over for free to people who might want to casually exploit you. You might even make it harder for some more sophisticated and/or committed actors to do it; for example, if I'm an ISP running a middlebox and trying to fingerprint all the traffic that runs through me, I can't use JavaScript. And you can save some bandwidth in the process.

codetrotter• 4 years ago

Won't this likely result in browser detection to be pushed to JavaScript and create an arms escalation race?

NoScript.

https://noscript.net/

MBCook4• 4 years ago

But that should happen.

Does the user’s browser support WebDoodle2? Why try to parse a weird history of nonsense and combine that with a table of what versions of what browser supports what?

Just check if document.doodle2 is defined. Done. Reliable. Easy.

FF pretends to be Chrome pretends to be Safari pretends to be IE pretends to be Netscape pretends to be Mosaic pretends to be god only knows.

Actually asking via JS instead of guessing is a massive improvement.

wyager• 4 years ago

Good. I would rather incur costs for browser detection than make it easy.

kevin_thibedeau2• 4 years ago

results in a browser detection excalation arms race

Countries should start enforcing their laws with regard to equal access for disabled users. Invoke hefty fines for denying service to people using assistive software that doesn't masquerade as a mainstream browser and the problem will disappear.

TheBrokenRail• 4 years ago

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!

heavyset_go3• 4 years ago

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.

1vuio0pswjnm7• 4 years ago

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.

judge2020• 4 years ago

so I am not concerned with "responsive design", which is arguably one legit use for the UA header.

Responsive is specifically designed to work without client hints/detection, so you'd be good there anyways. Specific mobile-only versions of websites is what breaks, and a large part of that is (some?) Wordpress sites.

willnonya• 4 years ago

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.

Xelynega4• 4 years ago

I don't think their suggestion was "just do what chrome does", it was "make your browser indistinguishable from chrome so that Google trying to create a seperate browser standard breaks websites for other browsers".

If a website can't tell my browser apart from chrome, it can't attempt to support chrome-specitic features based on the user agent string.

paranoidrobot• 4 years ago

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.

andirk3• 4 years ago

User agent sniffing is poor practice anyways. Try to use the feature and react according to the browser's abilities. Analytics and similar can sniff all day though.

To push browsers to get rid of UA string, we should all use a UA string extension that uses the same string like "DOG-SHIT". That way it'll start showing up in analytics.

And if you're trying to date the "data science" girl, spam the app/website with UA string like "hi-amy-will-you-go-out-with-me--sincerely-jack-who-sits-behind-you."

altdataseller• 4 years ago

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

jeroenhd2• 4 years ago

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!

xyzzy_plugh• 4 years ago

Nah, you're both wrong. What you really want is social security numbers.

wkat4242• 4 years ago

Log4j would also be an interesting one there

gregmac• 4 years ago

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?

oefrha2• 4 years ago

User agent sniffing is still a very typical way to determine whether to send the mobile or desktop version of a site.

rikschennink• 4 years ago

I do.

Lots of `isIOS` and `isSafari` tests in my code. Safari 15 for example cannot correctly apply orientation metadata, and will choke on very big images when using `createImageBitmap` in a thread. No way to find out.

I could probably detect the orientation issue with a small dataURI of an image, but the big image issue is more difficult.

tgv3• 4 years ago

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.

Pathogen-David• 4 years ago

Yup, the "test for feature availability" attitude doesn't properly account for features which are available yet buggy.

I recently ran into an issue where a media-heavy blog post of mine would sporadically crash iOS Safari. I ended up narrowing it down to my use of ImageBitmap to accelerate rendering images into 2D canvases on the page.

My fix ended up being to modify my ImageBitmap feature check to pretend it wasn't supported on Safari.

sebazzz• 4 years ago

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.

andirk3• 4 years ago

_cough cough_ MediaSource. Mobile Safari is now completely the new IE. It's so sad.

WirelessGigabit• 4 years ago

overpriced MacBook Pro that has a sticky letter s today

This joke flew right over me. Can someone elaborate?

masswerk7• 4 years ago

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/

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

Related Stories