1

I'm looking to restrict the use of my webapp for handheld devices only, and completely disable for desktop.

There're a ton of libraries available for device detection, but all of the sniff User-Agent which can easily be faked. Is there any library that goes beyond UA and uses other checks to make sure the device is indeed a handheld?

eozzy
  • 66,048
  • 104
  • 272
  • 428
  • I think you need to start by defining what you mean by 'handheld' –  Jun 29 '15 at 23:38
  • 3
    what would be the consequences if someone faked the UA? they simply get a mobile version of the the webapp? - if that's the only consequence, do you care much? – blurfus Jun 29 '15 at 23:38
  • @HoboSapiens devices with "touch-based" input, and screen size not larger than 10" ? – eozzy Jun 29 '15 at 23:39
  • @3zzy that can also be faked. What is the *real problem* you're trying to solve with this? – zerkms Jun 29 '15 at 23:41
  • @ochi Its a simple javascript based app for mobile use only, and with source code visible it would be easily copied. Yes, it can still be copied but I want to make it as difficult as possible. The target audience is not developers so hopefully that should be enough for now. – eozzy Jun 29 '15 at 23:42
  • Just detect the screen size instead. Here is an [SO link][1] describing how [1]: http://stackoverflow.com/questions/2242086/how-to-detect-the-screen-resolution-with-javascript – cade galt Jun 29 '15 at 23:42
  • 1
    "but I want to make it as difficult as possible" --- what is the real reason for that? – zerkms Jun 29 '15 at 23:42
  • @zerkms Source Code. The app loads data from a json, if they get hold of it, all of the images (hundreds) can be downloaded. – eozzy Jun 29 '15 at 23:43
  • 1
    @3zzy you cannot protect from that, at all. – zerkms Jun 29 '15 at 23:44
  • @zerkms Hmm.. no way at all? even if I wrap it up in a node.js app? – eozzy Jun 29 '15 at 23:46
  • You _could_ make it more difficult by encrypting your JSON server-side, decrypt it client-side with obfuscated code: http://www.jsobfuscate.com/ But it would still be possible to do it. @zerkms Sure, but it does make it somewhat _more difficult_, as we cannot make it _impossible_. – blex Jun 29 '15 at 23:46
  • @3zzy how changing server-side would make anything different? Something that is available from one client is available to another as well. – zerkms Jun 29 '15 at 23:46
  • @blex seriously? It will take less than 5 minutes to "decrypt" it. Don't rely on obscurity. – zerkms Jun 29 '15 at 23:46
  • @3zzy I see - I am afraid you may have to obfuscate the calls as much as possible and decipher some paths yourself in a back-end service. Not impossible to 'hack' but hard enough to be a deterrent for most non-motivated-enough people – blurfus Jun 29 '15 at 23:48
  • @ochi come on - just start fiddler and you have all the "obfuscated" calls. – zerkms Jun 29 '15 at 23:48
  • 1
    @zerkms the goal is nearly impossible. It takes less than 5 min for the knowledgeable and determined. For the rest, it could be a hassle big enough to not bother - some would say tht's good enough... – blurfus Jun 29 '15 at 23:50
  • @zerkms I agree but most people I know (non-coders) think of a violin player when I mention fiddler... I guess it really depends on the audience for the webapp... – blurfus Jun 29 '15 at 23:52
  • @ochi Exactly, the target audience is not people with web development experience so its fine I guess, just anything that deters them from getting hold of the source code easily. So if not device detection, can you please point me to the guide for obfuscating the calls? Thanks. – eozzy Jun 29 '15 at 23:54
  • @blex already mentioned http://www.jsobfuscate.com/ - you could start there... – blurfus Jun 30 '15 at 00:11
  • Oh thats a joke, jsbeautifier can decode it in less than a second. – eozzy Jun 30 '15 at 00:15
  • @3zzy WHAT A SURPRISE! /me spent 15 minutes of their time for no good reason, :-( – zerkms Jun 30 '15 at 00:15
  • You could wrap the entire webapp in a webview and distribute it through the respective app stores. I think it's pretty safe to say those that use it are probably going to be on handheld devices. – Huey Jul 03 '15 at 16:15
  • You want an app that can be downloaded from respective app stores or an application that will run in browser in mobiles? – Nikhil Aggarwal Jul 03 '15 at 16:26

3 Answers3

6

Not sure if it would be helpful, but I would like to address your question in two sections:

I'm looking to restrict the use of my webapp for handheld devices only, and completely disable for desktop.

Well, that is technically not feasible because of the reasons mentioned by @guest271314 (and other comments). Moreover, there are many software applications whose only task is to simulate a mobile environment on desktop devices and almost all of them make use of UA sniffing. Moving back to your second query,

Is there any library that goes beyond UA and uses other checks to make sure the device is indeed a handheld?

If you want to know about the nature of browsers and devices accessing your services, there are a few different approaches to this task:

  • User-Agent Sniffing
  • Feature Detection
  • Device Detection

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

User-Agent Sniffing

With "User-Agent Sniffing" (UA Sniffing), 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. While UA Sniffing can be done with JavaScript on the client itself, nothing prevents people from performing UA Sniffing on the server. UA sniffing also have some downfalls. First one is: going down the slippery slope of constantly updating your sites and services to follow the never-ending evolution of the browser and device market. Secondly, UA can also be faked(as you mentioned in your post).

Feature Detection

Its the approach where we don’t test the User-Agent string but rather, we test for features that a browser claims to support. Feature detection is about checking for certain functions or features of the browser using JavaScript. Seeing the context of your query, this is what you might be looking for.

Feature Detection also has downsides. The most deadly one is called “false positives”. For example, your test of the browser tells you “yes, I support this feature! Fire away!”, only to discover that Geolocation is not really supported.

The most common tool for Feature Detection is Modernizr.

Device Detection

Device Detection is about having a framework that maps HTTP requests to the full profile of mobile device properties, including properties that relate to browsers and OSes. It happens on the server typically and has the added advantage of sending only content and formats that client can easily parse and use to the browser.

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 similarity ends there. A fully-fledged device detection framework, such as WURFL, will go out of its way to avoid false positives and above all, it will return device properties and capabilties that cannot be derived by UA analysis.

Hope it helps

nalinc
  • 7,375
  • 24
  • 33
1

I'm looking to restrict the use of my webapp for handheld devices only, and completely disable for desktop.

Abandon all hope. This is not possible. For example, an RDF application at the "handheld" could be accessed by separate "desktop" computer. Even if access were successfully restricted to "handheld devices" access to the device hardware , software may, or may not be simultaneously restricted, allowing the "handheld" operating system , browsers, display, etc. to be viewed at a local or remote "desktop".

adb , or similar interfaces for non-android platforms could also access "real-time", or saved html ,js viewed at "handheld" device - at "desktop".

guest271314
  • 1
  • 15
  • 104
  • 177
0

In brief - there's no reliable way for a server to tell which devices initiates communication with it. Everything in the HTTP headers/content can be spoofed with the simplest script.

In the client side things are even more open so - naturally any client side code can be viewed, extracted, manipulated, changed and used in any way a skilled developer would like.

But you can try to make life a bit harder for the hacker, my best shot in client side would be to use a few checks using Javascript and Modernizr to detect touch devices and then try to distinguish between these and desktop devices that support touch.

So:

1) Detect only touch devices through Modernizr.touch, docs here: http://modernizr.com/docs/ It's a client side javascript to detect touch devices.

2) To rule out desktops I would test if the device width is smaller than 1024 (javascript: screen.width) . Most handheld devices width are such.

3) Maybe the only popular exception for that exception for this would be iPads. They have 1024px device width, just like some desktops with touch support. In this case you could use user agent check in client side (that's a little harder to spoof than the user agent sent to the server in HTTP but still possible)

isiPad = navigator.userAgent.match(/iPad/i) != null;

Then I'd minimize everything to make it somewhat harder to manipulate and hack, so the average user hopefully won't bother, or won't have the skills to break this, and hope for the best.

asiop
  • 707
  • 4
  • 11