Hacker News Reader

I feel like these arguments always break down along the same lines:

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

Counterpoint: As a user, often the only way to get a video to play in any browser on linux is to modify the user agent. And then, when you do spoof the user agent, it works just fine.

This is probably due to DRM which is poorly supported by Linux (lazy devs will probably just exile Linux completely). But I do remember some linux-only decoder issues in the past. Decoder and codec support is just poorly signaled overall, even if an API says it supports it, it may not support a specific profile or even support it well.

Some of our video test grid machines are Ubuntu, so from our end Twitch video should work pretty well on Linux :-)

This was so common in Opera 12 that there was a dedicated button in the UI to change the user agent for a page.

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.

Firefox has a built-in list of websites that need UA tweaks to work in Firefox. (In fact, Firefox's UA override feature was designed by ex-Opera engineers at Mozilla.) You can review the list (and toggle them) in Firefox's about:compat page.

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

Except if your UA reports Firefox on Linux, where calls and huddles remain unavailable to this day.

I wouldn't call that a success.

A very curious case is that huddles for me work in wayland (under sway), and don't work in X11 (under i3), for the exact same configuration otherwise. I have not investigated what exactly the browser sends.

Do the calls and huddles work in Chrome on Linux? Do they work in Firefox if you use a UA that doesn't mention Linux?

Yes and yes.

Thanks for testing. I'll ping Mozilla's web compat team about this Slack Linux problem. (I work at Mozilla.)

I was told Slack has some Linux-specific issues that they're working on with the Firefox team, such as some complications around screen sharing depending on the window manager (as mentioned in some other comments below about Wayland vs X11).

I couldn't use those through Safari on a Mac either. Nothing really tells you that it's unsupported. I could search or figure it out but I don't wear my programmer/software tester hat all the time.

Welp, better spend a few minutes downloading the same thing but in a Chrome sandbox.

Can't say I've seen that often, but there was a short period of time when Twitch refused to play on a FreeBSD user-agent. Spoofing as Linux or Windows worked. They did fix it.

I really not have the need to do that. Perhaps on a few weird sites. But it's far from being the usual thing to see a video on a browser.

Not too long ago browser vendors decided to fuck up cookie backwards compatibility with "samesite" attribute so badly that you are literally forced to do browser sniffing to have your site work in both modern browsers and older versions of safari

random article about it: https://catchjs.com/Blog/SameSiteCookies

FWIW, MediaCapabilities is the new way to ask the "can I play this" question:

https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...

It returns a boolean for whether a codec is supported or not.

In all an insignificant price to pay. And maybe it would highlight browser vendors to fix it instead and become more standards aware.

Getting a browser vendor to fix something takes a lot of effort, and doesn't immediately alleviate any impact on users. "if (browser.name === 'safari' && browser.version < 14)" does.

> For example, the "canPlayType" API for whether a codec is supported returns "probably" or "maybe".

Great. You should be calling for the death of UAs too if you want the situation to improve.

I spoof my UA anyway because of the sites that don't like my browser and insist on Chrome.

I go back and forth. I do web development, and I do occasionally rely on the user agent, I completely agree that there are some situations where there isn't really an alternative we can use. It's not necessarily just a problem of specification, sometimes there are browser-version specific bugs that just have to be accommodated, and there is no way to test for those bugs and there is no way to get a signal for those bugs because they're not specified behavior.

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.