Neowin recently reported that Microsoft’s new browser for Windows 10, Spartan, uses the Chrome UA string, “Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36 Edge/12.0”. That is done on purpose.

You’ll also notice that the entire string ends with “Edge/12.0”, which Chrome does not.

UPDATE: I should point out, that this isn’t a radical departure from what Microsoft did with IE 11, which on Windows 8 reads:  Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko, as explained in this post.

What is User Agent sniffing?

Often, web developers will UA sniffing for browser detection. Mozilla explains it well on their blog:

Serving different Web pages or services to different browsers is usually a bad idea. The Web is meant to be accessible to everyone, regardless of which browser or device they’re using. There are ways to develop your web site to progressively enhance itself based on the availability of features rather than by targeting specific browsers.

Here’s a great article explaining the history of the User Agent.

Often, lazy developers will just sniff for the UA string and disable content on their website based on which browser they believe the viewer is using. Internet Explorer 8 is a common point of frustration for developers, so they will frequently check if a user is using ANY version of IE, and disable features. By presenting the Chrome UA string, we can work around the hacks these developers are using, to present the best experience to users.

Why do developers do it?

UA sniffing isn’t always bad, but it does have its edge cases. For example, I was recently writing a cordova application, and I had to do UA sniffing to detect if a user was using the latest version of iOS. In iOS8, the header needed to be bumped down 20px so that my links could still be visible. On previous verisons of iOS, it displayed fine.

In this case, feature detection (see below) wouldn’t be useful, so I had to check for this specific version of the browser, and if it was detected, I could bump the header down.

What developers will often do is check for a certain browser, then enable/disable features based on that. That’s lazy. It’s also a poor experience for your users.

What happens if a browser suddenly adds a new feature (say, WebGL) and the site developer was checking for that browser’s UA string, and turns off any WebGL features by default. So the user COULD use WebGL, but you decided not to let them use it. Poor experience.

Even better, what if a browser adds a feature, but then later removes it due to a bug? Uh oh. You’re testing for a browser instead of a feature, so that’s also going to be a poor experience.

What can I do instead?

UA sniffing is generally a bad practice. Instead, developers should use feature detection. There’s a great javascript library called Modernizer, which you can include in projects to easily detect for features.

From their site:

Taking advantage of cool new web technologies is great fun, until you have to support browsers that lag behind. Modernizr makes it easy for you to write conditional JavaScript and CSS to handle each situation, whether a browser supports a feature or not. It’s perfect for doing progressive enhancement easily.

This article from the jQuery team explains it in greater detail, as well as how to implement it.

Future proofing

You can alwayas check modern.ie to look for the latest features we are adding to IE, and vote for the ones that are most important to you. Even more, if you want to see which browsers support which feature (and when they were added), you can hea to CanIUse.com to check for features.

As I suggest above, consider using Modernizer, and checking for features, instead of UA sniffing. 

If you have any questions, feel free to reach out to me.

-----------------------
@DaveVoyles

Subscribe to my startup, tech, and game dev newsletter