IzzyOnDroid

• Intro
• App-Lists
• Articles
• Books
• Downloads
• App-Repo
• Imprint

Why do some apps request too many permissions?

In most cases, permissions requested by an app do make sense: it might need Internet to access your data in the cloud, Vibrate to get your attention, even location access when it has to deal with it. But sometimes things look really weird – and either you cannot explain to yourself why an apps requires that permission, or you cannot even see what „that permission“ is supposed to mean at all. The latter even worse when you cannot find it in IzzyOnDroid’s permissions list. What’s going on there? What could be the reasons for this?

As for the app lists IzzyOnDroid collects the apps’s Metadata (such as permissions requested), I was able to get a closer look at some context. Especially in those cases where permissions could not be matched against those recorded in afore-mentioned „permissions list“ – and I wanted to know what those are. Researching for and creating the list of „permissions explained“ added to the background. So this article tries to shed some light on possible causes.

Ad modules

The number one of usual suspects when it comes to „permissions not needed for functionality“ are definitely modules for advertisements. As many users are not willing to pay even the little sum of „one buck“ for an app, we can’t blame developers they revert to this to get at least a little reward for their hard work – and in most cases we can get rid of those unwanted modules with bying the „pro“ version of the app in question. But we don’t want to discuss this part of the equation now.

One permission always involved with ad modules is INTERNET, as that’s where the ads are loaded from. While few ad modules are satisfied with that alone, most want more¹. A more recent article at EtonDigital sums it up. From the top 400 free and paid apps a.o.:

• 82% free and 49% paid apps track user location
• 30% free and 14% paid apps access user address books
• 88% free and 65% paid apps access IMEI/UDIDs

Though that’s not all due to ad modules, most of them do want to access your location (ACCESS_COARSE_LOCATION). For some modules it even is required to include access to contacts (READ_CONTACTS), call logs (READ_CALL_LOG), your browser bookmarks and history (READ_HISTORY_BOOKMARKS), and more. Being part of the app, they additionally inherit all permissions the app declares for itself. It is not rare that even the app developers are unsuspecting of what those ad networks do (especially what they do with the data gathered), so pointing that out to them might result in them replacing the ad module used by one requesting less permissions.

To find out in how far you are affected by this, be welcome to take a look at my app-list for Ad-Modules and Privacy Checker – where I’ve even marked those I recommend. Lookout’s Ad-Network Scanner & Detector for example gives a lot of background information on the networks behind the ad modules, and AppBrain Ad Detector also lists Social SDKs and developer toolkits – which brings us to the next chapter:

Other libraries / implementations

Why reinvent the wheel? For many functionalities, there’s already some library having them implemented. But you’ve already guessed it: usually a library offers more than the one or few functions you need, and thus might require permissions the app itself does not need. We could call that „collateral damage“, and it’s not always avoidable. Luckily, in most cases this doesn’t draw in to many dependencies (more often even none at all).

While libraries are one thing, implentations are another issue. Especially developers new to Android check for what’s „best practice” – and get answers of what’s „most used” or „recommended by Google”. A classical example: How to make sure your app doesn’t conflict with incoming phone calls (e.g. to pause your game, audio playback, or whatever activity in such cases)? Google recommends registering a listener to onCallStateChanged, which requires the READ_PHONE_STATE permission² – one that looks suspicious as it also gives access to unique identifiers such as IMEI, IMSI, your phone number, and phone numbers you are „connected to”³. But that’s not the only way – though the best known and most used. As Arno Wetzel points out, there’s a more decent and privacy-friendly way to achieve the same, which doesn’t require a single permission: it uses the fact that, on incoming calls, the ringer is triggered – which „switches the audio focus”⁴. So the app simply registers to that event instead.

This is just one example – I’m sure there are more. The screenshot shows what details are accessible via the READ_PHONE_STATE permission – or rather, it does not, as I withdraw that permission from the app displayed. So watch out for the „blank spaces“.⁵ As you can see clearly, CallState can be accessed even without that permission, which is what Arno’s approach makes use of.

Insufficient and even erraneous documentation

I can tell you a thing or two from my own experience when setting up the permissions list: the official reference doesn’t even list them all, not to speak of explanations. Running a „Google Search” on a permission often just brings a ton of Manifest files from apps declaring them used. Getting an idea of what they are used for? Dead loss, nil return. So how to figure which permissions your app needs? I wonder how developers find out. In many cases I assume „good guessing” being one of the methods. One time I’ve even seen a comment in the source code: „Not sure what we really need here, so we request them all“. Any questions left on this? Side-effects are wrong implications and laziness, see below.

Not clearly belonging here, but somehow related are permissions which do no longer exist – like ACCESS_LOCATION and ACCESS_GPS (both being pre-1.0 permissions long obsoleted⁶, and should be reported to the resp. developers for removal. This is no question of „backward compatibility“ anymore, as it’s pretty unlikely anyone uses such an ancient Android version today (especially as pre-1.0 never „hit the wild“). You won’t find those „ancient candidates“ listed here at IzzyOnDroid, neither in the list of permissions nor with the apps themselves: no longer being recognized by Android, they won’t have any effect on you anyhow.

A very interesting source on the Android permission system in general (and „insufficient / erraneous documentation“ in special) is Android Permissions Demystified⁷. Despite of being written in 2011 for Android 2.2 „Froyo“ – when it comes to incomplete, insufficient, missing, or wrong documentation, it still hits home in 2015. From the document:

We study Android applications to determine whether Android developers follow least privilege with their permission requests. We built Stowaway, a tool that detects overprivilege in compiled Android applications. Stowaway determines the set of API calls that an application uses and then maps those API calls to permissions. We used automated testing tools on the Android API in order to build the permission map that is necessary for detecting overprivilege. We apply Stowaway to a set of 940 applications and find that about one-third are overprivileged. We investigate the causes of overprivilege and find evidence that developers are trying to follow least privilege but sometimes fail due to insufficient API documentation.

[ … ]

Android provides developer documentation, but its permission information is limited. The lack of reliable permission information may cause developer error. The documentation lists permission requirements for only 78 methods, whereas our testing reveals permission requirements for 1, 259 methods (a sixteen-fold improvement over the documentation). Additionally, we identify 6 errors in the Android permission documentation. This imprecision leaves developers to supplement reference material with guesses and message boards. Developer confusion can lead to overprivileged applications, as the developer adds unnecessary permissions in an attempt to make the application work correctly.

[ … ]

Of the 78 permission-protected API calls in the documentation, our testing indicates that the documentation for 6 API calls is incorrect. It is unknown to us whether the documentation or implementation is wrong; if the documentation is correct, then these discrepancies may be security errors.

Three of the documentation errors list a different permission than was found through testing. In one place, the documentation claims an API call is protected by the Dangerous permission MANAGE_ACCOUNTS, when it actually can be accessed with the lower-privilege Normal permission GET_ACCOUNTS. Another error claims an API call requires the ACCESS_COARSE_UPDATES permission, which does not exist⁸. As a result, 5 of the 900 applications that we study in §6.2 request this non-existent permission. A third error states that a method is protected with the BLUETOOTH permission, when the method is in fact protected with BLUETOOTH_ADMIN.

[ … ]

We found that some permissions are defined by the platform but never used within the API. For example, the BRICK permission is never used, despite being oft-cited as an example of a particularly dire permission [26]. The only use of the BRICK permission is in dead code that is incapable of causing harm to the device. Our testing found that 15 of the 134 Android-defined permissions are unused.

The document also confirms my assumption of „good guessing“ being part of how developers sometimes have to figure the permissions required: deducing „from the sound of it“ – e.g. requesting MOUNT_UNMOUNT_FILESYSTEMS to receive the MEDIA_MOUNTED intent. And there we have an example of an unnecessary permission, as that’s not needed.

Besides: some of those documentation errors have been reported to the corresponding bug tracker back in 2011. They are still there – in the documentation as well as in the bug tracker …

Wrong implications

Often going along with insufficient documentation are wrong implications. One frequent example: there is a permission called WRITE_EXTERNAL_STORAGE. I cannot find the equivalent, but there must be one – so let’s declare we need WRITE_INTERNAL_STORAGE. No such thing⁹, but still a bunch of apps list that in their Manifest files. This just throws a warning when you install the app (W/PackageManager( 782): Unknown permission android.permission.READ_INTERNAL_STORAGE in package …), but that’s it. It doesn’t do the app any harm – but neither any good. Still being in the Manifest when the app is released either means the app wasn’t really tested – or it didn’t really need such a permission at all (which again points to lazyness on the developer’s end). Even worse, you get such recommendations even in developer communities and blogs.¹⁰

On AppBrain, you find such permissions on the „Permissions & Concerns” tab as „Extra“ (see screenshot). Note that this section holds all „rather rare or unknown” permissions – not only those which don’t exist. Still, it doesn’t hurt to ask the dev about them, especially when he didn’t explain their use in the app description.

Lazyness

I already mentioned this under insufficient documentation („Not sure what we really need here, so we request them all“), but this point can combine all of the above: copy-pasted code (not necessarily from different locations), summing up all the errors made. Attempting to „fix things“, this one might simply add more permission-requirements. More requirements doesn’t necessarily implicate more features, so in many cases the kind of apps resulting from this are, hrm, not „simply the best“. If an entire app is constructed that way, one might surmise the only reason was to make some money via advertisement. For sure, quality was not one of the goals to be reached. Plus, these kind of apps are not what we need: they rather „clutter the lists”. Which is why they are usually „fall between the cracks“ and are not included in the app lists here at IzzyOnDroid.

Conclusion

Now we know some of the reasons for „redundant permissions“ – does this do us any good? Is there anything we can do about it? In fact, there is: contact the developer for clarification. Pointing out the concerns, this can lead to improvements in the app. As I already indicated when discussing the ad modules, some developers are not even aware of several implications¹¹ – so they might (and should!) even be thankful for the pointers. Same applies to non-existing or wrong documented permissions requested – as to those who know, that makes the app look a bit „dirty“ or „nonprofessional“. You probably cannot do anything about lazyness – but for those apps, you better find the better originals anyway