Android's permissions model doesn't work at all. Every app asks for a ton of permissions at install time. You can't install the app without saying yes, and every app asks for far more than it needs.
In theory, it is good, but in practice, it's broken.
The iOS way installs the app, but denies access to the resource.
That's a bit hyperbolic. My android apps don't ask for permissions they don't need nor do many others.
I think the android permission system is sane and reasonably functional. It's the users responsibility to read the requested permissions at install time and make a call.
There could be improvements here of course. I'd like to see a two tiered approach where developers could mark which permissions are optional and users could decide which to grant the on the first or each time these permissions are used in addition to the current method. I'd also like to see a requirement for devs to provide an explination of what each requested permission is needed for that could display on the market.
Hopefully these types of controls will continue to evolve on all platforms.
While showing which permissions are used is great, it's not a cure-all because they're all or nothing permissions. My background is in network security, I consider myself a security-conscious person, but I am continually guilty of tapping INSTALL immediately without expanding the permissions list.
The SMS permission in Android seems the most egregious to me. For example, an Android app you install requires SMS permission. However, in Android as it stands right now, the app does not need to notify a user when it sends an SMS - there's no requirement (nay, not even a widget to pop open and require the user to "Send" the way you see on other platforms like iOS--you've got to build this into your client yourself) to do this. So, you install a third party SMS client thinking you'll use it to send SMSes, but the app can send SMSes on its own, without you even seeing them. See also: http://www.cs.ncsu.edu/faculty/jiang/RogueSPPush/
Personally, while not perfect, I like Blackberry's model here (Cyanogenmod has implemented something similar) - the user can block out certain functions, knowing full well that the app will break - but can then decide to re-enable them if needed or once their trust level is raised.
I definitely agree that many of the permissions are far too broad. I'd like to see send SMS silently separate from send SMS with user approval.
I guess what I'm advocating here is a combined approach
- up front permission notification of android, but more fine grained
- activity alert approve/deny from ios
- selective permission blocks from bb except the developer can specify which permissions are optional so the apps don't crash when you disable random permissions, they just refuse to start with a clear message.
- parameters for some permissions to further narrow the scope like URL masks that you'll access over the internet instead of asking for full net access, etc.
> I'd like to see a two tiered approach where developers could mark which permissions are optional and users could decide which to grant the on the first or each time these permissions are used in addition to the current method.
This would be SO useful!
I have an app that I want to be able to collect crash reports for. This means I need the "READ_LOG" permission. Thing is, the log CAN have other potentially private information in it, so there's a scary warning for that permission.
If I could ask for READ_LOG permission at run-time, and Android would pop up a box saying "This app is requesting access to the log to: 'create a complete crash report and send it to the developer'" or some such, then only the very few people who are actually sending me a crash report would ever have to "reveal" their log data to my app.
While I agree this would often be useful, I think READ_LOG permission for a crash report is a bad example. That's the sort of thing that could be dealt with using an OS-level crash handler (with a prompt about whether or not you want to send logs to the developer of the app).
Funny that's one of the cases where I'd envisioned using such a feature. I wrote a private logging mechanism into my apps to capture the data I write to log seperatly so my support request option can include some just-for-this-app logs without a scary permission req but I'd much rather do it the way you suggest.
Another situation I've got is I'd like to use the the permission to act as your Google account to optionally grab some user detail from <some Google service>, but I don't want to scare off users with this permission.
The other feature on my permission wish list is some permission specific options like internet access to [urlmask1,urlmask2,...] or log read access to logs from my app only, errors and warnings.
> I'd like to use the the permission to act as your Google account
Oddly; even when you (the dev) ask for this; Google prompts you (the user) at access-time to approve/deny account access permissions (similar to Google's OAuth prompts on the web). Seems that would remove the need to ask for the permission at install time as well.
I am not familiar with Android, but can you launch a 'send log app' stored inside you app that has its own security declarations? Or would that trigger a dialog asking for permission at install time?
On iOS if you want to use Facebook but don’t want to grant it permission to access your location, you can still install and use the app and just deny it when the permission is requested.
Side question about ios I wonder about. If you buy an app and install it, but then find it needs to use some permission you're not comfortable with can you get your money back or are you just out of.luck?
Apple tends to err on the side of the user for refund requests, so most likely. You might have a hard time arguing that you didn't understand that the app would need those permissions, though, as any app that requires either location or address book permissions is likely to be fairly obvious.
In theory, it is good, but in practice, it's broken.
The iOS way installs the app, but denies access to the resource.