UA spoofers have feelings too!

There's been a lot of noise recently in the web dev world regarding UA sniffing vs. feature detection. It all started when Alex Russell wrote out a post suggesting that there are cases where feature detection UA sniffing can be used, and where feature detection wastes precious time asking questions we already know the answer to. As he predicted, that stirred up a lot of controversy. Nicolas Zakas backed him up (more or less), Faruk Ates gave a history lecture, and the entire comment thread on Alex's post is very entertaining.

I agree with many of the points Alex makes, and detecting the UA on the server side has a *huge* advantage: We can avoid sending useless JS and image data to browsers/devices that will never use them. But, a couple of issues make good counter-arguments:
  • Writing *correct* UA sniffing code is hard
  • UA spoofers are left in the dark here. We would serve them content according to what they're pretending to be, rather then content according to their actual browser

The first problem can be solved by a reference project that does the actual detection for major server side languages. The second problem is more complicated. UA spoofing is a practice that came to be in order to circumvent badly written UA sniffing & UA based blocking. While unfortunate, this technique is necessary for minority browser users, as well as in other cases. I for one have to use it when I'm using my phone for 3G tethering. My operator's network only allows phone UAs to go through the phone APN, so I fake it. And when I'm getting mobile sites on my desktop browser, that is... well, let's say it's unfortunate.

What we have so far is:
  • Feature detection *all the time* slows down things
  • UA sniffing kills UA spoofing

So, there must be a third way.
What if we could count on UA sniffing for major browsers UNLESS we detect spoofing is in place?
I thought thoroughly regarding a generic solution here, but failed miserably. We can't trust UA strings (neither sent over the wire nor window properties). We can't trust other window properties (such as vendor) as 100% accurate since they as well may be spoofed.
So, do we raise a big white flag? Give up on the idea that a reliable method can be used to detect browsers and avoid feature detection for every single feature we want to use?
Unless...
We can cover the most common use cases for UA spoofing and avoid messing them up. These cases are:
  • Browsers that pretend to be IE so they won't be blocked by backwards sites
  • Browsers that pretend to be mobile devices so they won't be blocked by DPI on their network
If anyone ever reads this and finds other use cases for UA spoofing, please leave a comment.

With these use cases in mind we can do the following:
  • Detect UAs on the server side
  • If spoofing is suspected, add appropriate code snippet to the page's top
  • If UA unknown or spoofing detected, feature detect
  • Otherwise (UA is known), send JSON with known features
That way, if IE UA is seen on server side, we add a conditional comment to the page's top. If a recent mobile device UA is seen (iOS, Android) we can detect it by checking for touch events. There might still be cases we haven't thought about that will still be delivering content according to their advertized UA, but hey, that's a risk you take on when spoofing. In most cases, that makes the UA string reliable. We can then serve a JSON feature set for everything we're absolutely sure the browser supports, and leave feature detect for everything else.

So, thoughts? Ideas? Irrational emotional responses?
Bring it on...:)
Written by Yoav Weiss

Comments

blog comments powered by Disqus

Later article : Putting IE to sleep

Older article : First post ever