No screening process is going to be foolproof, but we can all take steps to make our devices safer.
Computerworld - I truly hate to say it, but it was inevitable that we'd see some maliciously inclined apps get introduced to the public through the Android Market or the Apple App Store.
As I described in my August 2010 column, it is exceedingly difficult to ensure the security of apps in a public store. As consumers, we seem to expect perfection, but that's just not realistic.
The recent spate of malware-infested apps found in the Android Marketillustrates the point. Mistakes are going to happen, even if our app providers undertake reasonable precautions in guarding their stores.
And I should make it clear that I'm referring here to deliberate malicious behavior in the app software, not inadvertent mistakes made by application developers. Some of those inadvertent mistakes can be found via static code review of the apps themselves, and the store provider in its screening process may well detect some as well.
The question that we should be asking, then, is this: What do we have to protect us from apps containing deliberate malicious "features" such as Trojan horses that seek to steal sensitive information from us.
Let's consider both the store processes and the underlying security architectures briefly here. And let's compare Android and iOS in these considerations.
As for the stores, Apple of course is famous for having an app screening and approval process for all the apps in its App Store. Although not much is publicly known about that process, Apple does publish a set of guidelines for application developers to conform to (Note: You must be logged into the Apple Developer site to access the linked URL). Every iOS developer should read and be deeply familiar with those guidelines, of course, but they are hardly specific to security. In fact, the term "security" does not appear even once in the guidelines.
Still, a team of reviewers reviews all apps in the Apple App Store. Presumably, they verify many or all of the guidelines described in the above document. They verify that only published APIs are used, that the app doesn't crash and so on. Yet nothing is said about verifying that no undocumented features are present. Indeed, we have seen examples of approved apps containing "Easter eggs" and other undocumented features. (These apps were quickly pulled from the store, however, and Apple does famously have the ability to hit a software "kill switch," disabling such apps when discovered.)
By contrast, the Android Market is far less rigorous in its review processes. That's being charitable. The truth is that the market's operators pride themselves on being light on reviews. On the other hand, all apps must be signed, so in theory there is at least some accountability.
And then there's the security architectures themselves. Android's sandboxing has some great features to it. Each app, for example, gets a unique User Identifier (UID), and all the apps are thus sandboxed from one another by way of the underlying Linux file access controls. That's the good news.
The bad news is that each app has a set of resources it can access and corresponding permissions that are statically declared by the developer. This application sandboxing is hugely similar to Java's Authentication and Authorization Service (JAAS) policy sandbox. The problem is that applications routinely declare more permissions than they need, and the user can only accept/decline all permissions per app.
But at least they have the opportunity to accept/decline things, as opposed to iOS apps. Under iOS, all apps run with root privileges, and the operating system's application frameworks manage the sandboxing. The user has little visibility or control of this, with a few notable exceptions.
The exceptions include apps that request access to certain sensitive services, such as geolocation. Since the apps are required to use published APIs, Apple can control these services -- and it does. When an app requests to know the device's location, the user has the ability to accept/decline that request on a per-app basis.
Additionally, apps are largely restricted from reading/writing information from other applications and data stores. These restrictions go a long way toward limiting what an app can do, maliciously or otherwise.
With that high-level overview in mind, let's consider the question again. What do we have to protect us from apps containing deliberate malicious features?
Neither Android nor iOS is perfect in this regard, and we simply have to understand that mistakes in the process and defects in the underlying architectures are going to happen.
So, what is a consumer to do? My answer is that we must exercise caution. Here's a few simple things to consider, in no particular order:
" Be careful about the information we place on our devices. If it's really that important, perhaps it shouldn't be on a mobile device at all.
" Use only reputable apps from reputable vendors, especially for handling sensitive data. It is possible to write an app on Android or iOS that does a reasonable job at protecting a user's private information. The "big guys," like large financial services firms, know this and train their software developers accordingly.
" Don't just jump on a new app when it arrives in the store, no matter how enticing it may seem. Give it a few days and watch the customer reviews carefully.
" If you notice an app behaving peculiarly, like performing geolocation when you don't expect it to, halt the app and remove it from your device.
Of course, this is far from a comprehensive list. The main point is to question things and apply a layer of judgment.
Our mobile apps are great tools and toys. The mobile phone world today is vastly different from even five years ago, thanks to innovations like the Android and iOS platforms. But if we expect perfection, we're doomed to be disappointed.
Posts
