Security threats in Android! ..or not.

So you’ve been hearing lately about how some Android applications are going rogue and being used to steal users’ data and infiltrate their phones, to sit idly by only to wreak havoc when the user least expects it (ok, so maybe I exaggerated a little there). But there has been a lot of buzz lately about certain apps not playing by the rules, or including certain calls to leach user information. A lot of this buzz has been spun as backlash against Google for allowing these types of applications to exist (instead of having some asininely draconian filtering process like some ‘other’ phone provider).

Well, to help defend Google (which they’ve done a decent job of doing themselves), this one falls back on the users. If you’re an Android user, you’ve most definitely seen a screen similar to this.

This screen tells you exactly (mostly) [kinda] what the application you’re installing has access to, and how far it can reach. It’s your (the user’s) obligation to agree with this and install, or not agree, and cancel out. See those two buttons at the bottom? If you don’t agree and see something that has “Cost Money” in this section and you presumed it was a completely free (as in beer) app, then you’d better click the right (Cancel) button.

Now, the real concern here is what exactly do these actually mean.  If you see a label for “Phone Calls,” should you freak out and immediately think the app is going to start calling your friends, or start making unauthorized long distance phone calls? No (though it might).

This is one area where I think Android needs to step it up. It’s great that they tell you what permission groups are affected by this application. But to be honest, there are quite a few scenarios that could exist in each group. The given example for Phone Calls really only monitors the state of the telephony portion of the OS e.g.: An application could automatically monitor the state of the phone and reject any incoming calls if this happened to be some sort of navigation app, and felt that receiving calls while driving was too much of a distraction. – That’s a fairly obscure example, but it just goes to show what lengths these permission groups can go to. Obviously this same app would most likely pop up the Location group in this section as well as it would be requiring access to the course or fine GPS data.

So what determines which permission groups show up here, and how can you be sure that the developer wasn’t trying to be sly and hide the fact that their application is using the GPS data? Well, the people at Google thought of that. When developing an application, you need to specifically state which permissions groups your application needs in the AndroidManifest.xml file.

<manifest xlmns:android...>
...
<uses-permission android:name="android.permission.LOCATION"></uses-permission>
</manifest>

If this is not included in the manifest, you’re not even allowed to make calls to the classes that implement the functionality located within that permission group. The code simply won’t compile until the manifest file is edited accordingly.

So it seems Google has covered their end fairly well. It’s just up to the users to keep an eye on what they’re installing. Though as stated, I do think they could increase the level of detail that is displayed for each group.

Included below is a table showing all the permission groups. Also if you’d like to have a deeper look at what’s inside each group, have a look at the Android developer site for a full list of all the constants that would indicate what features are being used.

Android Permission Class