- People who have recently run into an issue that required browser sniffing
- People who haven’t and feel sure that “things are better now” and the practice is no longer needed.
I’ve gotten into these kinds of scrapes many times, and I can assure you all that philosophical arguments about browser-detection-vs-feature-detection don’t work very well when you’re trying to explain to a client why their web app that worked a week ago doesn’t work today (due to a WebRTC bug in Chrome, for instance) and won’t be fixed until the next Chrome version comes out in six weeks.
To folks advocating “ripping off the bandage” as a solution, I’d note that the wound underneath has not stopped bleeding.
Some of our video test grid machines are Ubuntu, so from our end Twitch video should work pretty well on Linux :-)
The browser also included a built-in user agent compatibility list and the user could manually add sites to use a specific UA string.
Most sites would work fine in Opera with the correct UA. Many did not work when using the default UA with the word "Opera" in it.
A recent success story: Mozilla recently added a UA tweak to work around Slack's Chrome-only check for video calls. Slack engineers reached out to Mozilla and, just a few days later, Slack removed their Chrome check and now support video calls in Firefox without a UA tweak. :)
I wouldn't call that a success.
Welp, better spend a few minutes downloading the same thing but in a Chrome sandbox.
random article about it: https://catchjs.com/Blog/SameSiteCookies
https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...
It returns a boolean for whether a codec is supported or not.
Great. You should be calling for the death of UAs too if you want the situation to improve.
However, I also browse the web on Linux, and there are also situations where sites just kind of decide that they do or don't support me based on whether or not I'm in an allow-list that was lazily cobbled together and that hasn't been updated in over a year. This seems to me to be the same category of problem; it should be better, sites should know not to do that, but they don't. And sure, I can solve the problem specifically for myself by going though an annoying process to lie about my user-header, but it's a big damper on all of the other "users" (ie, random family members/friends) that I support who aren't able to do that. And it defeats the primary purpose of the user-agent if I'm lying to sites about it because they block off capabilities for no good reason from agents that they don't recognize. If I'm constantly lying about my browser as the "solution" to that problem, I'm already kind of breaking user-agents in the exact way you're worried about.
And there are also obviously the privacy problems that come along with user-agents, which I'm not going to get into, but they're substantial and there is no way to solve them without making user-agents much less useful for website operators.
So I don't know what the solution is, or even if there is a better solution available than what we currently have, but there are real downsides to the current setup. I think it's silly to pretend that browser vendors won't ever have quirks that make user-agents necessary. But I also think it's equally silly to pretend that website operators will ever use them responsibly, and equally silly to pretend that people won't get locked out of sites for no reason because of them.
There is definitely some naivete in getting rid of user-agents, but there's also some naivete in keeping them, and the arguments for "well, they're still necessary" sometimes ignore just how much wasted effort and hacky crud goes into making the web work with them. At the same time though, there are bugs I've fixed in my day-job that could not be fixed without them. It's just, that doesn't mean the downsides aren't also there and that they don't also matter.
I'm personally interested in how client hints progress. They're not perfect, but they seem to be decent, and for all of my criticism of Chrome's Privacy Sandbox concept, I think this is an area where it makes a lot of sense -- make certain hints possible to check, but have a cost associated. It's still not the exact browser version though, there are still bugs that I wouldn't be able to fix with that system. But there are some bugs that I use user-agents for that this system would work for, and I'm willing to make my job slightly harder if it makes a bunch of other things better. Or at least, I'm willing to see how client hints play out and see how much harder they do or don't make my job.
For example, the "canPlayType" API for whether a codec is supported returns "probably" or "maybe". So we sometimes need to hardcode which browsers support which new codecs.
Also, there are several bugs in past and present versions of decoder implementations, which are only discovered though manual testing, or by observing quality of service metrics split by browser version (Firefox does not handle bad audio packets as well as Chrome, for example). In IE and old Edge, the video readyState would always be "4" after playback beings, even during buffering, which is a blatant violation of the spec Microsoft refused to fix (as stated in their bugtracker).
Browsers like Safari have subtly different event orders from the HTMLVideoElement which requires a burdensome workaround that us working in video just like to keep to Safari instead of poisoning other implementations.
A final fun quirk is that not all browsers gave accurate HTTP timing information until recently (notably, Safari < 14) which make download timing for the purpose of determining bandwidth very inaccurate. This is why Twitch only recently supported low-latency playback for Safari. There is no other way to ask "do you support accurate timing" other than for an engineer to test it and hardcode an exception.