UA-sniffing, Feature Detection and Device Detection

UA-sniffing, Feature Detection and Device Detection

A mistake is to commit a misunderstanding.

-Bob Dylan

In a fast moving industry like mobile, new terms, words and abbreviations constantly pop up. Over time, those terms may change their meanings as more people start to use (and sometimes abuse) them.  The concepts themselves sometimes mutate.

When developers and other mobile stakeholders want to know more about the nature of browsers and devices accessing their services, there are a few different approaches to this task. You have probably heard of one or more of the following expressions:

  1. User-Agent Sniffing
  2. Feature Detection
  3. Device Detection

Some confuse these at times. Yet each of these approaches to discovering properties of the HTTP client works differently and, above all, they often play different roles in the technology stack.

Lets explore each term.

User-Agent sniffing

So-called “User-Agent Sniffing” (or “UA Sniffing for short”) is the quickest approach to the problem. One can derive properties of the client by looking at the User-Agent header in the HTTP request. UA Sniffing usually involves searching for a specific string or pattern in the UA string and basing choices on the result of that search. A popular example from real life is:

var isiPhone = /iPhone/i.test(navigator.userAgent);

The code should be self explanatory to anyone with a smattering of programming: detect whether we are looking at an iPhone. There may be a few false positives with this test, but let’s not digress.

While UA Sniffing can be done with JavaScript on the client itself, nothing prevents people from performing UA Sniffing on the server in Java, PHP, .NET, Perl, Ruby or whatever other language they fancy.

UA Sniffing may seem like the solution to many problems, but, like most quick solutions, it has hidden long-term costs. One cost is the going down the slippery slope of constantly updating your sites and services to follow the never-ending evolution of the browser and device market. Newer devices may not say ‘iPhone” in the UA string, while other devices may say “iPhone” for the purpose of “extorting” the iPhone version of a web site without guarantee that they deserve it. A user-agent that contained the “Tiphone” string made my day a few years back.

Feature detection

Feature Detection is the approach where we don’t test the User-Agent, but rather, we test for features that a browser claims to support. The most common tool for Feature Detection is Modernizr, but there are many methods, including simply adding a few lines of JavaScript that perform the specific test you need.

Feature detection is about checking for certain functions or features of the browser using JavaScript. For example by checking if a given function or object exists:

var appCache= function() {
  return !!window.applicationCache;
}();

or by playing around with the Document Object Model (DOM) to then measure what the result of our manipulation is:

var inlineSVGworks = function() {
    var div = createElement('div');
    div.innerHTML = '<svg/>';
    return (div.firstChild && div.firstChild.namespaceURI) == 'http://www.w3.org/2000/svg';
  }();

A clear advantage of Feature Detection over UA Sniffing is that this is fairly maintainable since we are not basing our rendering/analysis choices on the status of the current browser market, but rather on the availability of widely adopted standards (or the de facto standards, but I won’t go there…).

Feature Detection also has downsides. The most deadly one are so-called “false positives”.  For example, your test of the browser tells you “yes, I support this feature! Fire away!”, only to discover that the ability to upload a file from that particular device or browser does not actually work, or that Geolocation is not really supported, or that Canvas support is simply too “sucky” for your needs.

What makes false positives particularly nasty is that there is no defense against them, with the notable exception of device and browser detection (more later).

But that’s not all.  Some of the tests are also expensive in terms of time and resources involved to run them every time the page needs to be rendered. This is made worse by the indiscriminate use of Modernizr particularly for mobile devices.

Device Detection

Device Detection is about having a framework that maps HTTP requests to the full profile of  mobile device properties(or, as we refer to them at ScientiaMoble, “capabilities”), including properties that relate to browsers and OSes.

An example taken from our own WURFL Cloud would look something like this:


// Use the capabilities
if ($client->getDeviceCapability('ux_full_desktop')) {
echo "This is a desktop browser";
} else {
echo "This is not a fully fledged desktop browser";
}

Device Detection happens on the server typically. This has the added advantage of sending only content and formats that the client can easily parse and use to the browser. The net result is a reduced payload and faster performance.

As a quick aside, we have recently introduced WURFL.js to expose Device Detection to front end programmers. http://wurfl.io has the whole story. End of the aside.

Some tend to confuse UA-Sniffing with Device Detection. In fairness to those, Device Detection does exploit analysis of the HTTP request (and the User-Agent string particularly) to operate. But the overlap ends there. A fully-fledged device detection framework, such as WURFL, will go out of its way to avoid false positives (the Tiphone is NOT an iPhone), and, above all, it will return device properties and capabilties that cannot be derived by UA analysis. These properties are available because someone invested the time and resources in creating and maintaining the repository of capabilities. In fact, if anything can be said about the relation between UA Sniffing and Device Detection, it is that Device Detection has been introduced to overcome the limitations of UA Sniffing.

Compared to Feature Detection, Device Detection also gives information about the actual device, such as form factor, device class and other physical traits. Such information is increasingly important for analytics purposes.  

Conclusion

Someone argued on Twitter that WURFL is the same as UA Sniffing. I objected to that. And the information in this post should make the reason for that clear: It’s like saying that a bicycle and a motorcycle are essentially the same thing. Harley-Davidson would disagree vehemently. And so do we.

  • E.Casais

    A nice post — muddled terminology is, alas, a long-standing problem in IT, so clearing things up is useful.

    Two remarks:

    1) Regarding the downsides of feature detection: it is not just that sometimes the client software lies about capabilities, or that there are bugs in their implementation. Frequently, the capability is implemented, and does work in the terminals under use — except in different ways, because of slightly varying interpretations of a standard, or because relying upon different versions of a standard, or different standards altogether. Think about how touch and mouse input events are handled, or the order in which DOM elements are notified, or what “handset” and “screen” mean in CSS media types.

    Sometimes, it is too difficult to detect and apprehend the differences via a local script on the terminal, so one has to rely upon an external entity to provide the information to compensate such device discrepancies.

    2) There is a fourth approach to knowing the properties of a client: capability negotiation. The two major techniques are Accept HTTP header fields and UAProf (including dynamic UAProf), where the terminal explicitly advertises what it is capable of, and which are both long-established norms. In principle, no detective work is required. The problems are also known: UAProf is heavy, some manufacturers (such as Apple) absolutely hate it, and is increasingly falling into disuse. As for HTTP Accept header fields, some proxies have been well-known to mess up with them.

    It would be correct to state that device detection actually builds upon and extends not just UA sniffing, but also capability negotiation.

  • Luca Passani

    Great comment Eduardo. Yes, UA prof and Accept headers certainly deserve a mention. As you correctly write, Apple and others have ignored an approach that had great potential.