This goes to show that security and privacy conscious users should always prefer the web version, if the choice is available, as the browser is a better sandbox, even in the context of these tightly controlled mobile platforms and app stores.
However, I feel that these default permissions are really not that awful. There's always a balance between giving fine-grained control to the user over permissions and ease of use and these are not orthogonal issues, as the user suddenly ends up with more choices to make. What the user really wants to know ... is this mallware? Is this going to delete my files? Is this going to violate my privacy? ... and that's about it.
If Android required separate permissions for absolutely everything you could do in an app, you know what the average user would do if presented with a list of 30 permissions requested, amongst which there would be phrases like "allow the app to open the web browser"?
The average user would just click "Yes, please" without reading it (I'm even doing that myself from time to time). And that seems better for technical inclined folks like us, but it really isn't for average users, because it trains them to blindly accept anything while giving the impression of security - and I feel that's worse than no security at all.
The average user would just click "Yes, please" without reading it (I'm even doing that myself from time to time).
This is happening most of the times anyway. There is no way to see from the installer screen, why an app requests a certain permission. One example: most launcher replacements require the CALL_PHONE permission, which comes with a big warning. This is technically required if you want to place a contact shortcut on your desktop.
A better, security-wise, solution would have been to ask on-demand, when the app actually performs a permissions-requiring action, like it is done in J2ME. I suppose this was not done in Android either for software patent or for convenience reasons. Or maybe it would have gone against the usability of ad networks if you could deny the virtual Golf app access to GPS and internet...
Asking on-demand for everything lands you in the usability mess that is Vista's UAC.
There are plenty of places where permissions should be more fine-grained, but doing that in a usable way is not easy. Personally, I'd like to see a distinction between "required" and "optional" permissions (with always deny, prompt and always grant alternatives for optional ones). Of course, there would still be a lot of tricky issues to sort out (e.g. how do you encourage developers to expose some permissions as optional not required?), but I think that exposing more permissions for direct user management, while trying to minimize the effort required might might strike a better balance over the long run.
Asking on-demand for everything lands you in the usability mess that is Vista's UAC.
Please let me clarify: a properly designed system should allow the user to "always grant" that one permission to that one app, so the total number of permissions dialog goes from 1 per app to N per app with N=number of required permissions. The advantage would be, that opposed to Windows (where you only grant one rather opaque "Administrator" permission) you will see how your current action caused the permission request.
To come back to my example: you tap on the contact shortcut on your desktop, and Android asks you:
"Launcher requests the permission to perform a (possibly billed) phone call. [Grant] [Grant always] [Deny] [Deny always]"
Of course this model does not work for all possible permissions and applications, but it is still a vast improvement over what we have now.
That's pretty much the model I was trying to suggest as well, with the extra detail that users only get that prompt for "optional" permissions. "required" permissions (e.g. a browser accessing the Internet) would still be take-it-or-leave-it at installation.
Though, thinking back to a Google+ post by a member of the Android team that I don't have at hand right now, there's also a place for self-certifying UI elements. IIRC, their example was a system-provided Contacts widget (where if you selected a contact using that widget from within an app, you were clearly giving the app access to that contact data). My favorite example is the crash reporter. If click the "Send Crash Report" button, you're clearly giving permission to share some, potentially private, data about the crash (and sharing even more if you also check off sending the crash log). When you can pull off those sorts of UI elements, it is ideal, but they're not general enough for everything.
>ask on-demand, when the app actually performs a permissions-requiring action, like it is done in J2ME.
I own a cheap feature phone with MIDP app support. (J2ME)
I don't think that's a wise choice. In Opera Mini I press through the "allow network access" screen every single time I use it, because, presumably for security reasons, I can't choose "always allow" (maybe because app isn't signed by carrier certificate??)
It's even worse than asking once as you train yourself to click/tap/press through the prompt whenever you use the app, so if it suddenly changed from "access internet" to "make phone calls", I might not notice.
>What the user really wants to know ... is this malware?
Yes. And unfortunately the permissions don't do anything, at all, to help you with that.
Permissions for a really useful, non-malware app: access address book, internet, blah-blah.
Permissions for a really terrible, malware app: access address book, internet, blah-blah.
Permissions are security theatre. The app store management may continue to use them but they should be hidden from the user - they are completely useless to the end user.
I wouldn't say that. They aren't just there just to be there, they do restrict access. It allows me to choose if I want an app based on what the app wants to know about me. Yes, it can't tell me if an app is malware, but it does tell me if some photo editing app needs to see my address book.
They are not completely useless. If a user doesn't want an app to send or receive SMS or make calls this can be prevented by permissions. This is true for several other permissions.
They are useless for a very large class of users - it can be argued that those users should educate themselves more if they want to be safer, but it doesn't seem escapable that hardware vendors (and others, including ISVs and network providers) have some incentive to promote solutions that have [what they consider to be] a better rate of solving the problem satisfactorily.
No, the selling point is that the user is in control (or at least gets more control than on other platforms). Clear and visible permissions are a part of that.
To follow up - the OP shows that the permissions are far from clear and visible.
Would people reasonably expect that the contents of their SD card and a list of all their purchases could be silently uploaded by an app they'd given no permissions to?
If not, this is clearly not delivering control to the user.
Wow, I did not realize that "no-permission" apps can read any file on the SD Card, I thought they at least needed the standard SD Card permission which I now realize is just SD Card write. I think that Android should implement some path-based security on the SD Card, although I guess that might be hard with their current model where I don't think any of the permissions have any arguments.
Problem with the SD Card is, AFAIK (might be wrong here) it's FAT formatted, so unless Android adds a security layer on top, there's no file permissions system.
Big horking one missing from the list: run native code.
From here you can pretty much do anything, since the average handset is shipped with an ancient buggy kernel.
The short answer remains: treat software on Play with the same distrustful contempt you would treat random no-name desktop software found in the dark corners of the Internet.
Can you qualify this? Native code is sandboxed just as managed code is (of course it is). Ancient buggy kernel? Most handsets have very contemporary kernels.
But surely you will provide some compelling citations.
Well, as an example, if you are using 4.0.0-3 you probably have a kernel susceptible to mempodipper (although that's "buggy", not "ancient", and it is not possible to exploit that bug from an app: you have to do it over adb).
Regardless, it is true: most of the exploits that have been used (Rage Against the Cage, GingerBreak, zergRush) have been in user-land components (adbd, vold, libsysutils), not in the kernel. On Android 1.x, though: kernel bugs FTW.
Basically every device for which some kind of rooting tool exists is vulnerable.
It is not too hard to leverage the same exploit used by rooting tools to circumvent the UID based sandbox and to access the data of other applications, including the phone book, security tokens / passwords stored in SharedPreferences etc.
However, with a buggy kernel, you don't necessarily need native code to perform the exploit: you just need access to whatever part of the kernel that has the bug (which is often something innocuous). If there is a bug in the filesystem driver where attempting to open file descriptor to paths larger than 1024 bytes long will cause a buffer overflow, I can exploit that just as easily from Java as I could from C.
Basically every device for which some kind of rooting tool exists is vulnerable.
Most if not all rooting tools work via the debug interface. One rather clever app -- if you have USB debugging turned on -- would essentially do a localhost debug connection to exploit this, but generally these are ADB exploits. This has nothing to do with native versus managed, and native provides no additional opportunity than managed.
I replied to the original post because there is a pretty prolific belief that native=crazy dangerous. Yet of course the iPhone has entirely native apps, and we've had native sandboxing and rights restrictions since...what...the creation of UNIX?
From these two it is fairly easy to tell how current the kernel is for any rev of android out there. A quick cross comparison shows that it was more or less current at time of release but isn't updated afterwards. This means there are quite a few three or four year old kernels out there since most devices are in the 2.x range. I am not sure what qualifies as ancient, but I never really had a problem with the 2.6 kernel line.
There is another way to transfer the data off the device. You can make another app, that has the same sharedUserId and that app has the internet permission. That app can see the data of the non-permission app and send the collected data via its internet permission anywhere. Apps with a sharedUserId have the super set of permissions of all apps they share the user id with. The user does not see that when installing either app.
> What can be done with the data once it’s collected? Without the INTERNET permission, how can it be sent anywhere? While it's true that most network access is restricted, there is one network call that can be made without any permissions: the URI ACTION_VIEW Intent opens a browser. By passing data via GET parameters in a URI, the browser will exfiltrate any collected data. In my tests, I found that the app is able to launch the browser even after it has lost focus, allowing for transmission of large amounts of data by creating successive browser calls.
Your desktop/laptop has survived without anally granular sandboxing since the day you started using computers, and you've been using apps from all sorts of places (web browsers, plugins, text editors, games) without serious concern. Yes: you shouldn't install apps from people whom you don't feel some reason to trust, but that's always been the case (and seemingly always will, as no one has so far managed to build a sandbox that a teenager hasn't been able to break out of in a few days; Chrome's sandbox, for example, had two unrelated escapes come to light during the recent Pwnium contest).
Well I had serious concern for my desktop. Games are on an extra computer, and the OS tends to be Linux (preferred) or OS X (grudgingly). Most people's desktops are in fact completely overrun by malware, too. Just look at your relatives computers the next holiday.
Those people also tend to get phished, or open email attachments with .exe extensions. If you buy a game from Best Buy and there is malware in it, someone will have some hell to pay. Lumping together "software I buy from people I've heard of" into the same category as "people get lots of malware" is just fear mongering.
Did you bother to read the article before commenting? Sentences six and seven:
"Some previous work had been demonstrated by Thomas Cannon of viaForensics. I wanted to develop that work further through a discussion backed by source code."
There's a point to be made about expectations, though. On a desktop by default you know that apps can do whatever they want, but on an OS with a built-in sandbox and permissions like "internet", you expect it to not be able to access the internet. That may lead to changes in your behavior, like installing any random app with no permissions instead of carefully evaluating them beforehand.
Also, I'd like to add that saying the ability to list packages on the device is a security risk is just silly. That's like saying a Linux box is vulnerable because I can list /usr.
Reminds me of directory traversal on regular systems[1]. Zip up what ever you find, base64 encode it and send it to some shady server for later harvesting.
While it's true that most network access is restricted, there is one network call that can be made without any permissions: the URI ACTION_VIEW Intent opens a browser.
However, I feel that these default permissions are really not that awful. There's always a balance between giving fine-grained control to the user over permissions and ease of use and these are not orthogonal issues, as the user suddenly ends up with more choices to make. What the user really wants to know ... is this mallware? Is this going to delete my files? Is this going to violate my privacy? ... and that's about it.
If Android required separate permissions for absolutely everything you could do in an app, you know what the average user would do if presented with a list of 30 permissions requested, amongst which there would be phrases like "allow the app to open the web browser"?
The average user would just click "Yes, please" without reading it (I'm even doing that myself from time to time). And that seems better for technical inclined folks like us, but it really isn't for average users, because it trains them to blindly accept anything while giving the impression of security - and I feel that's worse than no security at all.