4 ms·

Can we please just freeze the user-agent string all browsers use? (I'd prefer if we could remove it, but we all know that isn't ever happening due to all the ol

Can we please just freeze the user-agent string all browsers use? (I'd prefer if we could remove it, but we all know that isn't ever happening due to all the old websites.) It's silly that it's almost 2023 and web browsers are still sending legacy-infested nonsense like "(KHTML, like Gecko)" and websites actually change behavior based on it! We have proper APIs for feature detection nowadays, websites shouldn't need to change behavior based on the browser anymore.

khiqxj 4y ago
literally this. user agents are an obsolete feature (i considered it obsolete around 10-15 years ago) and whenever a new protocol includes it you already know its made by backseat networking "engineers". all user agents do is break more shit because people think they're smart or clever for modulating their machine behavior based on them (blocking, working around broken standards, etc) "there exists a use case that wouldn't be possible to implement without user agents" is not an argument. it's not philosophically valid. its dead obvious that you do not consider the whole picture if you make this argument. why does that 0.1% use case matter? especially given that it's not officially supported. especially given that for the last 10 years, the likes of google have shoved everything _straight_ into the web specs when they started considering it an official supported use case? if you are doing something that's not an official supported use case, why do we need to have hacks to support it? obviously the least ecologically harmful solution is for your use case to not be supported. of course we are talking web here, where scope creep is infinite and the protocols do nothing well instead of one thing well. this is the very problem with the web, that "it doesnt have a concrete use case maaaaan", "ill just add and take what i want as i go", "the web is just the web maaaan you need to think on my wavelength to get it". these people embedded in web actually unironically just make shit up as they go along. they literally operate on an oscillating wave where today feature set 1 is good, tomorrow feature set 2 is good, and the day after, (what is essentially) feature set 1 is good. arguing to have a user agent string is the same idea. this is in strict contrast to a well designed product that actually solves a specific problem, like Standard ML, or a good SQL implementation (disregarding the specification conundrum) or JSON or VGA or TCP.
laudecum 4y ago
That’s weird. Didn’t Chrome plan to freeze that already years ago? Did they walk back?
- bluesmoon 4y ago
  Nope, this is already happened in Chrome. Client Hints are the way forward.
vikingerik 4y ago
Browsers still have weird behavior cases that aren't covered by feature detection. Here's an example from this year where I needed to change behavior based on the browser. We have a single-page app with lots of dynamically created elements. We discovered a case where Chrome kept input focus on an element that was deleted and recreated, while Firefox didn't, resulting in different behavior if the user pressed Enter next after clicking on that element. (I don't know which of those is the bug, if either. We wanted the Firefox behavior so I hacked in a .blur() in the event handler for Chrome.)
- Klonoar 4y ago
  You would not use the UA for this - there are plenty of other safer detection techniques.
- TheBrokenRail 4y ago
  To me, that just sounds like an pretty good argument to improve feature detection. Freezing user-agents and improving feature-detection aren't mutually-exclusive.
- viraptor 4y ago
  But that doesn't require you to check the browser. You can force the same behaviour in every case, as you did with .blur() Neither feature detection nor user agent string matter here.
- toast0 4y ago
  Feature detection doesn't work well for some bugs either. How do you feature detect a crash bug? Or a leak? If you run the code that crashes, you've crashed the page and can't then run alternative code.
ezfe 4y ago
Safari froze OS version, but they received a lot of pushback so they didn't freeze the browser version
- cpeterso 4y ago
  Firefox and Chrome froze the macOS version in their User-Agent strings, too, because jumping from “Mac OS X 10.15” to “Max OS X 11.0” broke quite a few websites’ UA parsing code that never expected a value other than 10.
bluesmoon 4y ago
Already happening. Client Hints are the way forward.
Joker_vD 4y ago
On the one hand, I absolutely agree, UA-dependent behaviour is generally a huge PITA. Some sites even refuse to return content if you don't set UA header in request, WTF is with that? Last time I checked, only Host header was absolutely required. But on the other hand, there are certainly some cases where you want to know actual browser version to work around the critical bugs: e.g., Safari 13 (I think?) had broken their implementation of WebSocket compression for about a year: the byte stream becomes garbled after about 64 KiB of data transmitted, and the WebSocket connection breaks down. How do you work around that without UA string? And on the third hand, we may have proper APIs for feature detection nowadays but — how many webdevs actually have heard of them? And willing to update their legacy codebases? I personally haven't although I'm not a webdev by any stretch. And when one tries to google how to e.g. support some feature in different browsers, there are lots of older pages/resources/answers telling how to do it with contents of the UA header.

khiqxj 4y ago

literally this. user agents are an obsolete feature (i considered it obsolete around 10-15 years ago) and whenever a new protocol includes it you already know its made by backseat networking "engineers". all user agents do is break more shit because people think they're smart or clever for modulating their machine behavior based on them (blocking, working around broken standards, etc) "there exists a use case that wouldn't be possible to implement without user agents" is not an argument. it's not philosophically valid. its dead obvious that you do not consider the whole picture if you make this argument. why does that 0.1% use case matter? especially given that it's not officially supported. especially given that for the last 10 years, the likes of google have shoved everything _straight_ into the web specs when they started considering it an official supported use case? if you are doing something that's not an official supported use case, why do we need to have hacks to support it? obviously the least ecologically harmful solution is for your use case to not be supported. of course we are talking web here, where scope creep is infinite and the protocols do nothing well instead of one thing well. this is the very problem with the web, that "it doesnt have a concrete use case maaaaan", "ill just add and take what i want as i go", "the web is just the web maaaan you need to think on my wavelength to get it". these people embedded in web actually unironically just make shit up as they go along. they literally operate on an oscillating wave where today feature set 1 is good, tomorrow feature set 2 is good, and the day after, (what is essentially) feature set 1 is good. arguing to have a user agent string is the same idea. this is in strict contrast to a well designed product that actually solves a specific problem, like Standard ML, or a good SQL implementation (disregarding the specification conundrum) or JSON or VGA or TCP.

laudecum 4y ago

That’s weird. Didn’t Chrome plan to freeze that already years ago? Did they walk back?

bluesmoon 4y ago
Nope, this is already happened in Chrome. Client Hints are the way forward.

vikingerik 4y ago

Browsers still have weird behavior cases that aren't covered by feature detection. Here's an example from this year where I needed to change behavior based on the browser. We have a single-page app with lots of dynamically created elements. We discovered a case where Chrome kept input focus on an element that was deleted and recreated, while Firefox didn't, resulting in different behavior if the user pressed Enter next after clicking on that element. (I don't know which of those is the bug, if either. We wanted the Firefox behavior so I hacked in a .blur() in the event handler for Chrome.)

Klonoar 4y ago
You would not use the UA for this - there are plenty of other safer detection techniques.
TheBrokenRail 4y ago
To me, that just sounds like an pretty good argument to improve feature detection. Freezing user-agents and improving feature-detection aren't mutually-exclusive.
viraptor 4y ago
But that doesn't require you to check the browser. You can force the same behaviour in every case, as you did with .blur() Neither feature detection nor user agent string matter here.
toast0 4y ago
Feature detection doesn't work well for some bugs either. How do you feature detect a crash bug? Or a leak? If you run the code that crashes, you've crashed the page and can't then run alternative code.

ezfe 4y ago

Safari froze OS version, but they received a lot of pushback so they didn't freeze the browser version

cpeterso 4y ago
Firefox and Chrome froze the macOS version in their User-Agent strings, too, because jumping from “Mac OS X 10.15” to “Max OS X 11.0” broke quite a few websites’ UA parsing code that never expected a value other than 10.

bluesmoon 4y ago

Already happening. Client Hints are the way forward.

Joker_vD 4y ago

On the one hand, I absolutely agree, UA-dependent behaviour is generally a huge PITA. Some sites even refuse to return content if you don't set UA header in request, WTF is with that? Last time I checked, only Host header was absolutely required. But on the other hand, there are certainly some cases where you want to know actual browser version to work around the critical bugs: e.g., Safari 13 (I think?) had broken their implementation of WebSocket compression for about a year: the byte stream becomes garbled after about 64 KiB of data transmitted, and the WebSocket connection breaks down. How do you work around that without UA string? And on the third hand, we may have proper APIs for feature detection nowadays but — how many webdevs actually have heard of them? And willing to update their legacy codebases? I personally haven't although I'm not a webdev by any stretch. And when one tries to google how to e.g. support some feature in different browsers, there are lots of older pages/resources/answers telling how to do it with contents of the UA header.