Note: This post was written PRIOR to Android 6.0 “Marshmallow” – please see the updates below for more details. “Marshmallow”, by and large CORRECTLY handles app permissions.
When you download an Android app, you are presented with a list of permissions that the application requires in order to run.
You can either accept all of the permissions as stated, or cancel the installation – there is no middle ground.
This approach makes Android generally untrustworthy, but there is a simple way to fix it.
Update: 5/2016: So apparently, apps written for Android 6 already implement flexible permissions.
In settings…apps, click on an app, and then click “permissions” to turn individual permissions on or off.
Well… that pretty much addresses my concerns.
After using “Marshmallow” for almost a month now, I’m quite happy with it. With pure glee, I neutered many of the “bundled” apps by revoking all of their permissions.
There are still THREE improvements that could be made:
- I’m paying a ton of money for the device, and ostensibly, I own it. I should be able to remove ANY bundleware app that I choose, even if it’s built in to the ROM image. If you “root” your phone (run 3rd-party scripts to obtain “root” privileged access to the device), you can remove all of the bundleware, but why should I have to go through the hassle, and put myself at risk in the process? “Rooted” devices are much more likely to get infected with a virus or nasty malware.
- The whole permissions scheme is somewhat silent to the uninitiated. If you install a written-for-6 app on to a Marshmallow device, you get NO permissions prompt – you get a pop-up stating that permissions can be individually granted when the app requests them. It does NOT explain how to go in and edit individual permissions, nor does it prevent an app from being installed with too many permissions – the user must go in and modify permissions AFTER installation. A better approach is to have an “advanced” permissions button where the user can access a dialog in order to edit permissions BEFORE the app is installed. Although apps don’t typically launch automatically, if a malicious app wants to snarf up your contacts or other personal data, there’s ample opportunity to accidentally allow that to happen before you can yank its permissions.
- Some permissions can’t be disabled. For example, some apps launch or require the “google games” app – it would be nice to completely disable these annoying pop-ups, or to completely disable in-app purchases, for example, on a child’s phone. Every permission should be able to be individually disabled. In addition, it would be nice to be able to set a global device policy that disables (or enables) a permission for all apps – for example, globally disabling access to contacts, and then individually granting permissions for specific apps would be my preference, rather than having to go in and perpetually disable this permission for every new app that wants it.
Update: 4/2016: It appears that Marshmallow, released in October, 2015 PARTIALLY addresses my concern.
Marshmallow (Android 6.0) allows you to revoke specific permissions for each application – the residual risk is that a malicious app could do harm AFTER it’s installed, but BEFORE you can revoke its permissions. So, there is still validity to the concern that I’ve outlined below.
Furthermore, after upgrading my LG G3 from Kit Kat (4.4) to Marshmallow (6.0) today, I’m shocked at the mandatory crapware pushed down with the LG image, who then sends it off to the carrier (AT&T, in my case), who then adds more crapware.
In Kit Kat, I could disable the “LG Health Tracker” app – no such luck! It’s on, and can’t be uninstalled or disabled. Fortunately, I stumbled upon the permissions hack, and simply neutered it by removing all of its permissions.
On top of LG blatantly spying on me, AT&T installed “AT&T Remote Assistant”, Wild Tangent gaming, and a bunch of other crapware, above and beyond the crapware that was installed with Kit Kat. All of this has to be disabled or neutered so that it doesn’t soak up my data and send it “in to the cloud”.
The ever-increasing trend toward “mandatory” spyware deployed by the manufacturers and carriers, competing to steal your personal information, makes the permissions debate ever-increasingly important.
1. The Android Permissions Framework
Today, when you install an application from Google Play, you get a prompt listing the permissions needed by the application, and you’re provided the opportunity to accept the permissions (in total) or cancel the installation.
When an application is updated, you are prompted to accept any changes to those permissions.
Without enumerating every single permission, each typically allows the application in question to access or manipulate a specific piece of hardware on the phone, such as the camera or microphone, or a specific set of data, such as contacts, text messages, or the ability to write files to the storage card.
2. The Problems With Android Permissions
The Android Permissions Framework has some serious problems.
2.1. All or Nothing
As discussed, permissions are an all-or-nothing proposition. Because of this, the user is forced in to a complex trade-off scenario, where he or she may not understand the full impact of accepting the proposition.
On the one hand, the application might be fun or beneficial.
On the other hand:
- It could be insecure, meaning that the app itself could be hacked, and then the permissions already granted to it could be subverted for malicious use.
- The app could be quasi-ethical “spyware”, designed to copy your personal data “in to the cloud”, where it can subsequently be sold, stolen, or exploited by a malicious third party.
- The app itself could be written by a malicious developer, specifically to create malicious hooks intended to compromise the device or send personal data directly to the attacker.
The user has no frame of reference to use, to actually determine if the application can be trusted.
Some common questionable scenarios include:
- Version x of the application is free, and requires no permissions. An update, version y comes out, is now ad-supported, and requires access to device information, contacts, browser history, and all sorts of potentially-sensitive information. At best, the ad company is building a more accurate profile using aggregate data, but anything that exists in the cloud can be hacked and stolen from the cloud.
- Really Cool Game requires access to your camera and microphone as part of the game’s functionality. Hopefully, the developer is legitimate, and the code only uses its access for the specified purpose, but in theory, a malicious app could be listening and watching all the time, once granted permissions to do so.
- Useful App requires ALL permissions. The developer could be naive or simply inexperienced, and may be asking for more permissions than are really required. On the down side, crappy coding and surplus permissions means that the app could be hacked and used as an attack vector.
- Awesome Keyboard allows you to type much faster, and it has all sorts of emojis. It also has access to every keystroke you type. Every time you text your wife or log in to e-mail, you get a slight twinge of anxiety, because you know that Awesome Keyboard could have been written by criminals, and could be silently siphoning everything you type to an offshore server where someone will attempt to use it against you later.
The all-or-nothing permissions framework obscures the trade-off as well as the true value proposition offered by the application, and is skewed against the user.
2.2. Not All Permissions are Created Equal
Some permissions are very straightforward, for example, use of the camera means exactly that – the application can use the phone’s camera hardware for several specific purposes. Or “send a text message”, which literally gives the application the ability to send a text message.
However, if the application has to write files outside of its private application folders, it needs the “External Storage” permission. This pretty much gives the application free reign to read the “gallery” (photos and videos), private audio recordings, and literally anything stored on the SD card, without restriction.
Some applications request permission to read the phone’s log files – as stated above, this could be a simple developer mistake, HOWEVER, those log files contain tons of information about the phone, what applications are launched when, and could contain personal information as well.
Either through poor development, questionable ethics, malicious intent, or legitimate functionality, asking for more permissions than are required means that the application could have access to a lot more than either the developer or the user intends.
2.3. Every Permission Could Be Exploited
Every permission granted to the application could be used as an attack vector:
- If the application itself is malicious, the attacker has direct access once the user accepts the permissions. More permissions means more access to the device, as well as the user’s personal information.
- Poorly-written applications could be exploited, and then the attacker can leverage all of the application’s permissions to steal information or further compromise the device.
- Ad software often asks for some fairly dubious permissions – in some cases, the adware may be using that information to create a profile of the user (ethically-questionable), or it could be blatantly copying gigabytes of your personal data in to the “cloud” where they intend to sell it, but someone else could hack in and steal it. Or, it could be misconfigured permissions within the application – let’s face it, Marketing people are not the most competent software developers, and you’re going to have to scrape the very bottom of the barrel to find developers whose ethics are questionable enough that they are willing to write adware or spyware..
- Hardware permissions, on the one hand, can support useful application functions, or on the other hand, can be used to monitor the user without their knowledge.
- Data permissions can often be exploited to gain access to more information than either the Developer or User intends.
- Device roles allow the application to interact with the device in certain ways, such as starting services that run in the background whenever the device is turned on. On the one hand, a service like this could provide useful reminders and automatically update information. On the other hand, it could be used to monitor every activity the user performs on their phone.
More permissions means a greater likelihood that a malicious application or attacker could compromise the device or the user’s personal information.
3. The Current Permission Framework Erodes Trust
Both the carriers and the handset manufacturers are paid by developers to include certain applications in their base image – these applications are “locked” and can’t be uninstalled. In some cases, they can’t even be stopped or disabled!
If one of these applications happens to snarf up your personal information without your consent, so be it.
Likewise, selling YOUR personal information is big business for both the carriers and the handset manufacturers…
There have been recent incidents in the laptop world where this practice has directly resulted in spyware being pre-installed – Lenovo has been caught 3 times pre-installing spyware.
In the phone world, the handset manufacturers take a base Google image, and heavily customize it. The first thing to go is the “stock” user interface – replaced by home screens, keyboards, and other UI elements that are proprietary to the manufacturer, yet they see every application you launch, and every keystroke you type, and there is no real way to determine what information is being collected by the manufacturer under the guise of “usage data” designed to “help developers” “better understand” their “target user base”.
Once the carrier gets its hands on the device, they install more crapware, and in some cases, they even install spyware. Some carriers have their own messaging apps, or address book plugins that are designed to “sync with the cloud” – again, anything that exists “in the cloud” can be deleted or stolen, and YOUR “anonymous usage data” can be collected and sold.
None of this is speculation – all of these practices are in full swing as we speak, and there are no laws and no ethical barriers to protect the user. All of this happens legitimately within Android’s permissions framework because the permissions were put there as part of the handset image, which gets loaded to every device before it leaves the manufacturer or carrier facility.
Given all of these factors, how can you possibly enter a credit card number or your online banking password?
The simple answer is that you shouldn’t! I don’t!
As a matter of fact, I’ve had some very sketchy incidents occur with Android:
- I picked up my first Android device in 2011. I’ve been a long time LinkedIn user, so I immediately downloaded the LinkedIn app. The permissions included access to my contacts, which I just happened to synchronize through the Mail application with my e-mail contacts. This effectively gave LinkedIn access to all of my e-mail contacts, which it immediately snarfed up, and uploaded to “the cloud”. A few days later, I started seeing “Do you know this person?” prompts for my personal contacts. It turns out, I uninstalled the LinkedIn app, I was able to sever LinkedIn’s access to my contacts and summarily delete everything LinkedIn had snarfed up, but we all know that nothing in the cloud is ever really deleted. LinkedIn thought it was being helpful, as its developers had designed it to do, but it did things that I didn’t want it to do, and I didn’t have the ability to stop it.
- The only two times that I suspected my e-mail had been hacked, I saw suspicious behavior just after installing some sketchy application on my phone – who knows whether those incidents were coincidence or not, but I changed my e-mail password immediately, and uninstalled any app that I though might be capable of accessing my e-mail. I checked the list of devices that had accessed my e-mail, and of course, one of those was my phone – I sync my personal e-mail to my personal phone, so that makes sense. However, who is to say that some well-intentioned or possibly even nefarious program “tickled” my e-mail to see what was out there, running right from my phone.
- I’ve had situations where my contacts get annihilated or duplicated because everything tries to get access to your contacts, and some poorly-written piece of carrier-installed crapware didn’t synchronize them properly.
With so little trust for the Android platform, how do you get anything done?
The answer is that I only leverage relationships that were established on a trusted laptop, and then carry those relationships over to the handset.
- The only stuff I buy online from my phone is stuff where the website already has my credit card number.
- I do not bank from my phone.
- I use an e-mail anonymizer, to make my e-mail harder to hack, and so that I’m not using the same username and password for every website.
But that’s not the real problem.
The real problem is that there is no “Google Approved” seal of approval, no vetting system (Google Play does automatically scan for “malicious looking” code), and no peer review to ensure that security and quality standards are upheld.
When presented with a new application, the user can look at how many times the app has been downloaded, and its rating, and that’s about it.
As a developer, the only thing you’re required to provide to Google when you publish an app is your e-mail address. That literally means that anyone with an e-mail address can publish anything they want.
The problem is that there might be a great app out there, that works well, it’s fun to use, and oh, by the way, it also includes a malicious spyware module. In this situation, you can’t tell that it’s malicious, because the deception isn’t obvious, and no one has really checked. So, if this hypothetical app gets a few downloads and a couple of 4-star ratings, then as a potential user of the app, you would never know that it’s malicious.
As a matter of fact, one of the problems with Google Play that has recently come to light, is that criminals are downloading a legitimate app with few permissions, adding their own malicious code, and simply re-publishing the EXACT SAME APP under a slightly different name. If I see two apps that are similar, and both LOOK the same, I might click on either one… One of them is loaded with malware, and the other is legitimate, and there’s no way to tell the difference.
What this boils down to, is that you never know what you’re going to get. Your brand new phone could be loaded with spyware before you even open the box. You could download an app at any time that ends up compromising your information, and maybe even leads to someone stealing your identity and personal information.
So, although the Android permissions framework absolutely does create transparency about what the application can do, and what information it can access, the framework itself can’t convey the developer’s intent, nor provide assurance to the user that those permissions will be used appropriately.
3.1. It’s Only Going to Get Worse
Fitness trackers are all the rage…
They constantly measure your heartbeat, blood pressure, and other biometrics “so that you can be more healthy”.
Imagine a scenario where ad companies have access to that data – they can literally start to record which images and activities get your blood pumping faster, and they can create dynamic advertising that’s tailor-made to manipulate YOU, personally, based on what they know gets you excited.
This isn’t even close to ethical, and as phones roll out with new features and capabilities, the possibility for abuse only increases.
The rate at which personal data is flying off of these devices puts the FBI vs. Apple case in to a new perspective – who cares if the device itself is encrypted, because most of the data you actually need is probably accessible from “the cloud”, uploaded there, possibly without the user’s knowledge, consent, or input.
4. A Better Approach
As we’ve discussed, the current permission framework requires the user to wholly accept and grant ALL permissions, or cancel the installation – all-or-nothing.
A better approach is to allow users to grant individual permissions for each application.
At first this appears chaotic, and possibly even ineffective, but let’s delve in to this approach a bit deeper.
4.1. It Could Be Confusing or Annoying
To some users, this approach might be annoying – having to review each permission for each application.
Remember that the application itself can request whatever permissions the developer intended, and the user still has the option to “blindly accept” them.
For the subset of users who might find this approach confusing or annoying, they can simply click-and-accept the proposed permissions as stated by the developer, which is the same experience they have today.
4.2. It Could Break the Application
Removing permissions means that the application as written will fail or crash when it attempts to perform certain functions.
The applications must be written with alternate code blocks to accommodate the lack of each specific permission.
For example, if the user denies access to contacts, the application should prompt for a phone number or e-mail address. If the user finds this annoying, the trade-off is that they can elect to allow the application to access contacts, and now the application allows the user to select from the contacts instead of being presented with a simple dialog box.
Each permission should be implemented as two separate code blocks, allowing the entire application to be minimally installed and effective with zero permissions.
Each application should have a policy outlining each requested permission, and the functionality unlocked when each permission is enabled.
For example, a photo indexing app might be completely useless without access to external storage (SD card). The app should at least be installable WITHOUT SD card permissions. The user interface could simply prompt the user for access to the SD card, which would then trigger a permission change. If the user opts NOT to allow access to the SD card, the application simply sits there. The user then has the option at some point, to either allow access or uninstall the application.
4.3. Reputational Impact
As a developer, you want a high rating for your application.
Users who install the application, yet decline all the permissions might be left with minimum functionality, and therefore rate the application lower than expected.
This type of reputational impact can be mitigated by associating a permission matrix with the rating itself – this ties the user experience directly to the permissions the user enabled.
A potential user can then see, for example, that users who enabled fewer permissions rated the application lower, and users who enabled more permissions had a more positive user experience.
In this approach, a “1 star” rating has much less impact, and provides potential users with more information about how permissions affect the app’s user experience.
4.4. Intransigent Developers
Although a stubborn developer could simply refuse to enable any functionality unless ALL minimum permissions are granted, there will always be a competitor who is willing to provide the same functionality with fewer permissions.
This effectively turns trust in to a commodity – users can choose which apps they trust, which in turn, will drive popularity.
Likewise, stingy developers will be difficult to trust, and therefore, there apps will be less popular.
5. A Return to Trusted Computing
For Android to be useful, it must be trusted.
The current, messy state of affairs makes it impossible to trust anything you download, and even to trust the applications that come pre-loaded by the manufacturers and carriers.
I do my banking and online transactions from a Windows 7 or Debian laptop running virus protection and a modern, secure browser. I scan my systems periodically for spyware, and I keep their patches up to date.
Neither Windows 7 nor Debian is going to anonymously collect data about me, and send it to “the cloud” where it’s supposedly securely stored “for my benefit”.
I KNOW I can trust these machines.
What’s sad is that I can’t trust my own cell phone.
As the user community wants to move toward better security, such as new ways to perform secure payment transactions, and better privacy to prevent identity theft, these goals are simply undermined by Android’s current permission scheme and app ecosystem.
A better approach is to give users the ability to remove ANY application, or at least remove all of the permissions for every application, and to trade functionality for individual permissions, which offers a clearer value proposition to the user.
For a computing device to be useful, it has to be trusted. Rebuilding that trust starts with changing Android’s permission framework.