Phones and permissions

The Android permission system for applications ("apps" these days) is an all-or-nothing affair; one can either grant all the permissions that the app asks for, or deny them and not install it. While it is useful to know what permissions are being granted, it would be even more useful for security and privacy conscious users to be able to selectively deny certain permissions—especially those that have no clear connection to the proper functioning of the app. The CyanogenMod (CM) alternate Android firmware has had this ability in its tree since mid-May, but a newer patch that builds on that functionality has been met with resistance from a somewhat surprising direction.

The original patch from Plamen K. Kosseff to add permission revoking was accepted after working out some difficulties with apps that crashed when they didn't have the permissions they expected. In addition, enabling permission revocation involves a setting in the "Performance Settings" menu of CM configuration, which means that the project is free to ignore any bug reports generated from the feature. Kosseff then went on to post a patch for review building on that earlier work, and allowing users to allow certain permissions in a "spoofed" mode. The specific example he used was to spoof the phone's International Mobile Equipment Identity (IMEI) number, rather than allow an app access to the real IMEI—that didn't sit well with some CM developers, including CM founder Steve Kondik.

The choice to start by spoofing the IMEI was perhaps unfortunate, as Kosseff has ideas for other, probably less-controversial privacy features. For example, in the comments on the patch he describes other possible uses, including restricting what information in the contacts list gets handed to apps, or only showing a portion of the SD card contents to apps. Either of those are obvious improvements to privacy, and ones that shouldn't cause any problems for app developers.

The main objection to returning a bogus IMEI value (or the related idea of returning a bogus SIM ID and phone number) is that app developers use that information for data-gathering purposes. While that data gathering might be used for malicious purposes, the clear sense from the comments on the patch is that most app developers are using it for demographic and usage information that is, at least relatively, benign. Kondik and others are concerned that creating a "hostile environment" for app developers will lead to problems for CM, either from the app developers themselves or from larger organizations like Google, handset makers, and cellular service providers.

But, as Kosseff asks, shouldn't the user be able to make the decision about what information they share with apps? For IMEI and related information, the answer from the CM developers seems to be "no". It seems somewhat counter-intuitive that a phone distribution with the goal of unlocking the full potential of the hardware would draw that particular line. Others, perhaps the Guardian project for example, are likely to take a different stance.

Part of the issue is that it is unclear what is "owed" to the app developers for use of their code. For paid apps, the line is a little less blurry, as one can expect that those developers aren't owed any more than was paid. For gratis apps, things get a little more hazy. If one grants permission to see the contact list to latest bouncing cow game, is it reasonable to revoke that permission, or to provide an empty list? In addition, many gratis apps use the network permission to grab advertisements to show within the app. That is part of the revenue model the developer is using to fund app development, so is it fair to turn that off? On the flip side, should the app refuse to run if it can't call home for ads?

There aren't necessarily any easy answers to some of those questions. Avoiding apps that request more permissions than they really need is certainly one way around the problem, but the permissions aren't really fine-grained enough to prevent abuse. If one grants an ebook reading app permission to use the SD card (presumably to store any books that are being read), does that mean it should be able to go poke around and see what other ebook apps are being used? It will also presumably need network permissions to grab content from various places, can it also use them to phone home with a copy of one's reading habits?

This is yet another area where free (as in freedom) software can help. There are certainly plenty of users who will be happy to play an ad-supported bouncing cows game, without disabling the network out from under it, if they are sure that the game isn't using its permissions for ill. Likewise, there are plenty of legitimate reasons that an app might need to access the contact list, so long as one can be sure that it isn't sending the contents to spammers (of the voice, SMS, IM, or email kind).

For most consumers, any of these safeguards are essentially pointless. As we have seen in the consumer PC world, users will install almost anything, from anywhere, even overriding security warnings from the OS, if it will get them the latest game, mouse cursor, or video content. There's not much hope of changing that, but for the rest of us, who might just care about the data we store on our phones, having more control over the permissions we grant to apps will go a long way toward solving these kinds of problems. A rich ecosystem of free software apps would go even further.