Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

miketaylr.com

Post reply on HN
Print view View original

61–70 of 143 posts

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

#61

Post by TheBrokenRail »

Hizonner wrote: post #48

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…

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!

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

#62

Post by andirk »

MBCook wrote: post #56
logicallee wrote: post #36

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.

This is the correct answer. Allow 3rd party analytics or whatever to do as they choose, but your javascript should pretty much never believe a UA string.

`if (someFeature && someFeature.someSpecificMethod)...`

Or you can try/catch if you are less sympathetic to inferior tech.

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

#63

Post by howinteresting »

MBCook wrote: post #55
metadat wrote: post #51

Earlier quoted context omitted.

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

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…

Problem is some versions of some browsers have bugs in some parts of doodle2, and the largest websites tend to care about things like that.

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

#64

Post by heavyset_go »

Hizonner wrote: post #48

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…

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.

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

#65

Post by woojoo666 »

masswerk wrote: post #39
MBCook wrote: 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.

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…

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

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

#66

Post by heavyset_go »

codetrotter wrote: post #54
metadat wrote: post #51

Earlier quoted context omitted.

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

> Won't this likely result in browser detection to be pushed to JavaScript and create an arms escalation race? NoScript. https://noscript.net/

There are plenty of services that won't serve you data, neither web app nor data from API calls, if you aren't running a JS engine.

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

#67

Post by 1vuio0pswjnm7 »

Hizonner wrote: post #48

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…

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.

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

#68

Post by eyelidlessness »

pbhjpbhj wrote: post #45
eyelidlessness wrote: post #29

Earlier quoted context omitted.

I’m on mobile so kinda limited search capacity, but it looks like IE was using “Mozilla” in its UA string for a couple years before the trademark was published (granted it was filed a few months prior to that IE release, and granted I have no idea how to read uspto.gov with any confidence that I understand it, and also granted I have no idea how much prior usage of trademarks overlaps with concepts like prior art for…

It could be passing-off which is an unregistered right (in UK at least) as they were using that mark to pretend to be another product.

I get that. I’m just questioning (with some admitted ignorance) whether that matters if the pretense predates the trademark registration. At least for related copyright and patent law, and at least in the US (which influences a lot of IP law), prior usage can carve out exemptions, limit or even invalidate the claimed IP.

I just don’t know how much of this applies to trademark because, well, I never got curious about it until now. But I would assume it’s been reviewed by people far more qualified than myself, given the very litigious context around IE in the intervening period. My bet is it’s moot for trademark because it would’ve been unenforceable at the time of registration, or that it’s such low stakes that no one cared, or that it’s such high stakes that technical leadership fought to retain the status quo.

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

#69

Post by wyager »

metadat wrote: post #51
Hizonner wrote: post #48

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

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

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

#70

Post by willnonya »

Hizonner wrote: post #48

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…

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.

Post reply on HN