That would break more than it would fix. Video is hard (not all devices or browsers support the same codecs, bitrates, frame rates, etc), and YouTube has to use the User Agent to try to serve videos that the client can actually play. A random User Agent would mean that all those browsers that need a special video format wouldn't get the type of video they need, which sounds like a crappy world to live in (compared to the crappy world we already live in with meaningful User Agents).

> YouTube has to use the User Agent to try to serve videos that the client can actually play.

Why? We have JavaScript feature detection for video tags: http://diveinto.html5doctor.com/detect.html#video-formats

"Probably" and "maybe" values are, uh, probably not good enough.

I thought you were being facetious. Sigh. Damn, but that's broken.

I've worked with video format streaming, though, and encountered a situation where there was a driver on a certain Android device manufactured by a major hardware vendor that you've certainly heard of, and their driver silently corrupted video that was using low-latency streaming options. And by "corrupted" I mean that, while a few of the pixels looked almost right, sometimes, it was mostly just garbage and blank grey screens.

I gave them a sample stream that failed, and they verified that yes, it's their fault. And that no, they weren't going to ship an update for it. Sorry. Device had been out for two years. Apparently no one thought to actually test the various standard options in that video codec. It works with the "normal" options? Ship it!

So I totally understand the need to look at UA strings. I had to look for that particular device hardware profile and disable the low-latency streaming options in order for our product to work on that device.

That sort of feature detection is likely not sufficient for detecting if a video will play well or correctly. There's been a number of bugs in MSE in the past which means that YouTube has to fall back on browser version checks to avoid a bad user experience.

To be fair, a certain school of thought would say that those bugs are the browser's to fix, and that websites should deliver the browser whichever video it claims to support. If the browser advertises support for something it doesn't support, then it is up to browser developers (not web developers) to fix either the support or the advertisement thereof.

Edit: Not saying that's always correct, but there does seem to be a tension between: "make sure your code can work well, even in a bad environment" and "don't mask bugs, instead fix them where it makes the most sense to do so" (in this case: in the dozens of browsers instead of in millions of websites).

Another school of thought is that it doesn't matter if it's the responsibility of the browser because the customer perception will be that your website does not work for them.

If a mechanism exists to prevent your customer from perceiving this, as a business the smart decision is going to be to use it.

Partly true, because if they try with another browser and get a good result they'll blame the browser and not the website. In this case, they'll probably say the the new Firefox broke YouTube. See one of the comments at www.pclinuxos.com/forum/index.php?topic=135323.0

"i'm getting a lot of corrupt unsupported browser when accessing video on other sites, so i'm using chrome. i can't figure out if it's flash or firefox but i'm tired of opening the hood, i'm done with FF for now"

Most of them looked for a workaround and spoofed the user agent, but they are the kind of people that fiddle with settings. Normal users probably either don't notice or change browser.

YouTube's compatibility hacks are against buggy versions of browsers. Regardless of whether a bug is eventually fixed, once it is released, there is some segment of the user base that has it. If that segment is large enough, and the bug easy enough to hack around, then YouTube will provide a workaround rather than lose revenue.

Sounds like the ultimate solution here is to just give browsers a killswitch, so they'll eventually just stop working if you don't keep them up-to-date. (I'm not sure whether I'm joking.)

While you're right that it's up to the browser to fix, that can be a very time consuming process (especially for something as tricky as video). YouTube doesn't want to wait around for browser vendors to fix things, so they work around it themselves (just like happened in the opposite direction for this bug).

Finding workarounds for browser bugs is a common theme for the work that web developers do. Yes, browser vendors should fix the bugs, but in the meantime, there's no reason to have a bad user experience.

> (compared to the crappy world we already live in with meaningful User Agents).

> Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

Google Chrome tells us it is: a Mozilla, it is AppleWebkit, it is KHTML, it is Gecko, it is Safari, and it is Chrome.

"Meaningful" is something different.

It's meaningful. It communicates exactly what the browser is to anyone who is capable of receiving the intended communication. (It also communicates other things to people who are not, but "Google Chrome 41.0.2228.0" would be absolutely meaningless to these listeners, so that doesn't seem like an objection with merit.)

You might object to the form of the communication, but that doesn't render the communication inexact. Just think of it as browser slang.

> It communicates exactly what the browser is

This is true, which is not particularly useful when deciding if a feature is available. Using the user agent to make this decision incorrectly assumes that all user agents of a particular browser+version all support exactly the same set of features. This is obviously not true.

The user agent may be meaningful[1], but the meaning that it communicates isn't feature data.

[1] If you take the header at it's word; as the bug being discussed demonstrates, user ages may be lying.

> [...] the meaning that it communicates isn't feature data.

But it kind of is (to some degree, at least). VP9 was recently added to Firefox 28. If the User Agent says the browser is Firefox 27, then you probably shouldn't try serving VP9 to that browser.

Obviously the User Agent doesn't communicate the complete feature set. But some useful inferences regarding features can be derived from it.

The user agent header is not the place to look for those.

It shouldn't be the only input signal for determining those things, but it can definitely be useful (i.e. "this codec is only supported in vX.Y+ of this browser", or "vX.Y of this browser has a bug handling this type of video", etc.).

It's not like YouTube is a company of full of nothing but dopy idiots. I don't think they'd be using the User Agent if there was a better alternative.

If this is your goal, wouldn't it make more sense to just stop sending the User-Agent header?

Various websites break if you don't send the User-Agent header. So, in the short term, no, in the long term, yes.

Are there really a substantial number of sites that break if you don't send the header but work if you send a random 10-character string?

Many sites behind Cloudflare.

If I don't have this line in my .wgetrc, I get 403's sometimes from sites using Cloudflare.

user_agent=Mozilla/5.0 (compatible; CloudFlare-AlwaysOnline/1.0; +https://www.cloudflare.com/always-online)

Wget uses its own user-agent by default (Wget/x.y.z (linux-gnu)), not no header, so that's more likely cloudflare or sites specifically blocking wget.

Actually for the longest time, I had in my .wgetrc, user_agent="Mozilla/5.0 (etc etc etc)". It was a valid user agent. And Cloudflare was blocking that. Turns out if you wrap the actual user agent in quotes in your .wgetrc, wget doesn't strip them off, so cloudflare was seeing User-Agent: "Mozilla/5.0 (etc etc etc)", ie. with the quotes. And it was rejecting that.

Fair enough - but if it rejects that it would probably reject 10 random characters too

Note: the specific user-agent doesn't matter, I just think it's funny to steal Cloudflare's one.

I do the same whenever a site requests personal info from me and I don't want to give it.

Find the corresponding info from the company or their CEO, use that.

And whenever some site wants me to register for a newsletter, I enter their own "critical support" mail address.

I hope at some point these sites learn that mandatory anything just hives you useless data.

Haha, I usually put root@localhost, or www-data@localhost. It accepts it fairly often too. Sometimes I need to open up the Chrome Dev Tools and delete the input's type attribute (<input type="email"> to just <input>) because there's some client-side thing that tries to stop you inputting invalid emails.

Yes. Most of them give a HTTP 403 error, meaning they check for the header. Others crash with HTTP 500 errors or similar.

They could always remove it and add an option for users to switch it back on temporarily for the session if they really need it. Sometimes it's best to break things to get rid of cumbersome cruft.

Wouldn't that result in even-uglier hacks for finding user agent becoming standard?

Because the days of browsers having bugs that need workarounds are over?

Hopefully the days of websites having (or being able) to work around all browser bugs of the past 20 years are over.

Or cycle through all those lists of the top n used, and put some conditionals in /mozilla-central/netwerk/protocol/http/nsHttpHandler.cpp to avoid all those breaking effects (to some degree).

Added benefit of getting alot of "not recognized computers" or whatever emails from google lol

Could this be done with an extension?

Yes. https://github.com/muzuiget/user_agent_overrider

As far as I am aware, no extension currently offers the option of a random user agent, but many (including the one linked) allows user supplied use agents, and there is no reason you could not make one support random user agents.

There is in fact already an extension which will randomly change the browser user agent.

https://github.com/dillbyrne/random-agent-spoofer

Also, uMatrix can randomly switch user agent strings (among many other things).

With an extension to this extension, yes:

http://chrispederick.com/work/user-agent-switcher/

Why send one at all?