There's been a lot of news lately about a lapse in either security or judgment -- both, really -- at Apple that allows iOS applications to borrow your contact data and send it off to parts unknown without your consent. Apple has addressed the issue to members of the U.S. Congress, and will take steps to hold tighter control in a future iOS update. That's good news, and we're glad to see it happening.
But what about Android? During all this focus on apps doing things without explicit user permission, you see people referring to the Android permissions model. We're going to break it all down for you. It's not perfect, but it works pretty well -- and it's certainly better than no permission system at all.
Let's walk you through permissions on Android, and how you need to be sure to do you part.
By design, no Android application has permission to perform any operation that would "adversely impact other applications, the operating system, or the user." For an app to have access to things like private contact data, another application's data, network access, or even something as mundane as writing its own data to the device storage, the app must declare that it will have permissions to do so, and then you must accept that permission before you can install the app. When you install an app, you're presented with a list of permissions that application is declaring.
And note that we say applications are "declaring" permissions, and not necessarily "requesting" them. Semantics, we suppose, but there's no box that says "Hey, Jerry! I'm an app, and I'd love for you to let me have a look at your contact information. That OK?" Instead, Android apps are more direct, saying "Yo, Jerry. I'm an app. Here's a list of what I can do, just sos ya know. Take it or leave it."
Android apps declare which permissions they have access to, and thus which sandboxes they can play in. And you can either choose to accept them and install the app, or not. Make sense?
Permissions - upfront and personal in the Android Market
Here's how it looks if you install, say, Path. You get the macro list of permissions that Path is declaring. Tap one, and it explains that permission in a little greater detail.
That's how it looks if you install any application from the Android Market. You'll need to scroll through the list to see them all. A little ways down is the one that's gotten Path (and others) in all sorts of trouble on iOS. In its Android form, you can clearly see that Path declares the permission for "Your personal data - read contact data." Tap that permission, and you get more detail:
"Allows an application to read all of the contact (address) data stored on your phone. Malicious applications can use this to send your data to other people."
So Path has told you it has access to your contact data. It doesn't necessarily tell you what it's going to do with it (if we hadn't just brought it up, would you really want to know?), but it does tell you it can read it.
Apps outside the Android Market
But what if you sideload an app? Or use the Amazon Appstore? Applications are still supposed to declare which permissions they use, and you see that permissions list when you install the app. (Remember that the Amazon Appstore sideloads apps, so what you see is exactly the same as if you installed an app from an e-mail or download.)
Here's what sideloading Gmail would look like. The only real difference between sideloading and installing from the Android Market, insofar as permissions go, is that when you sideload, you don't get the more detailed permissions descriptions.
Why all this? Android applications are "sandboxed" -- they play in their own space and have their own data files within that sandbox. They can only share play in someone else's sandbox after explicitly asking for permission, and that's done via the screens you see above. When you accept those permissions and install the app, you're giving that app permission to play in the sandboxes the app says it wants to play in.
On the developer side ... and how consumers must do their part
Behind the scenes, app developers declare these permissions in the AndroidManifest.xml file, which is a required part of the source code for an Android app. These declarations are static, and every one of them is presented to the user as we've seen above. Android has no way for granting permissions dynamically at run-time, because according to the Android OS developers "it complicates the user experience to the detriment of security." Forcing an app to tell you what it wants to do, upfront, and never being able to change -- that's the utmost security model.
The flip side? It's also the easiest for users to ignore.
We know all about what happened with Path on iOS. Like many other iOS apps, it used the contact without permission. Not for nefarious purposes, but nonetheless, without any up-front permission, and without asking later. Path for Android sent all sorts of data to its servers, just like it did on iOS. But as we've showed in this post, in Android, Path has to declare the permission first. Or, more precisely, it declares permission, and you either accept or reject it.
The problem is when you install an app, most likely you're going to breeze right past the permissions section. You really shouldn't, but we all do it. The fact that the permissions aren't written in plain language is part of the problem. But even if they were, most of us would click right past anyway. That's juts how it is, on every platform. On the other hand, there are those who freak out over permissions because they don't understand them. Again, more user-friendly language would help here.
One of the alternatives to this is to have the application ask for permissions at run-time, when it wants to do something it can't do normally. We've already read that the Android team thinks this is inconvenient and insecure, so it's not likely to happen.
Another alternative is to allow selected permissions, much like RIM does with BlackBerry. The you end up with applications that only half work because you denied permissions, just like BlackBerry. There's no real foolproof method, other than reading it all when you install that app and trying to understand what it's asking to do and why it's asking it.
That's where we all come in. Some of us understand application permissions more than others, and when an app does something it shouldn't ought to be doing, you hear the outcry. Read the permissions. Read the Market comments. Read Android Central. When something goes awry, you'll hear about it.
And one last thing ...
A special note needs to go here about security vulnerabilities. Every computer program -- and that means every mobile operating system, too -- is chock full of them. When a vulnerability is found that allows an application to bypass the security model, Google will patch it quickly. This happens, and it's always going to happen. How quickly this update gets rolled out to you depends on the people who make your phone. They deserve the credit when they do it the right way, and the scorn when they take too long and do it wrong. That's not something that is going to go away any time soon, and we're right there with you to call out an OEM who doesn't keep things as safe and secure as they should be.
If you've looking to dive even deeper into Android permissions, check out the Google developer page on them.
Have you listened to this week's Android Central Podcast?
Every week, the Android Central Podcast brings you the latest tech news, analysis and hot takes, with familiar co-hosts and special guests.
