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
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.
to post comments)