Live data from Hacker News

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

miketaylr.com

101–110 of 143 posts

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

#101
post #59

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 s…

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?

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

#102
post #56

Earlier quoted context omitted.

what are better methods?

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.

The problem being that browser vendors tend to implement Web APIs early, before the API and the respective specifications are frozen and are still likely to vary. They may even implement a certain (still valid) interpretation of the specs, which then turns out to be not exactly what everybody else eventually implements, but may stick to this for some time. (There are examples for about every browser vendor on the planet for this. Without this, if everybody had waited for finalized specs, we wouldn't have web sockets, web databases, or Web RTC for years now.) How do you handle this without version numbers?

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

#103

> overpriced MacBook Pro that has a sticky letter s today This joke flew right over me. Can someone elaborate?

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/

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

#104
post #33

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.

[deleted]

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

#105
post #83

Earlier quoted context omitted.

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

The case may have been with Sega and I misremembered, but there was a similar system in place on Gameboy.

There definitely was a case involving the GB logo in ROM. The internet seems to have forgotten it, though. Whenever I've tried to look it up in the past the results always point to the unrelated Game Genie lawsuit.

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

#106

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 ?

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 achie…

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

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

#107

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?

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

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

#108
post #51

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 sof…

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

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

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

#109
post #34
post #3

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

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

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)

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

#110
post #79
post #76

Earlier quoted context omitted.

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 dev…

It does work correctly once you change useragent string though.

yes, I said it's standard webdev laziness.

Many aeons ago I worked on webkit, and the first step for a great many site compatibility bugs is "does it work with a Firefox ua string".

Because it is always easiest to just check ie/new-ie and then useragent gate everything else, that is what happens. Which is why we keep getting sites requiring chrome (new ie) or ie (old ie) - it doesn't matter if the site is broken due to reliance on chrome behavior vs spec, what matters is devs coding to a single browser and considering any deviation to be a bug in anything else.

Post reply on HN