The permission model on smart phones is all wrong, and everybody knows it. I’ll use Android as an example, mainly because I’m more familiar with it, but I don’t imagine iOS is much different.
When you install an app on your phone (or tablet – which is just an oversized phone after all), it asks you whether you will allow the app to have various permissions on the device — can it see your location? Access your contacts? Your camera? The network? The set of possible answers is, unfortunately, very limited: yes or no. No means you can’t install the app, yes means you accept whatever it says.
There are two problems with this model:
(a) You have no idea *why* the app wants each permission. There is only an assertion that it does, but not what it will do with that access. Often, the reason is quite legitimate and benign, but it’s entirely up to the phone’s owner’s imagination to figure out why the heck app A needs permission B.
(b) The set of possible responses is too limited. It’s either accept the app, with all the permissions it wants, or do not install it at all.
These problems lead to a third problem, which is habituation. Since the reason for apps to demand permissions is opaque and the only option is to not install the app which, presumably, the user actually wants, users stop reading the warnings and just blindly accept all apps with all permissions, no matter how bizarre.
I’d like to suggest a slightly more nuanced model, one that could easily be implemented by the phone OS vendors, that would improve the situation a great deal:
(1) Require app vendors to provide a bit of text next to each permission, that explains what they will do with the access they require. Users don’t have to read this – perhaps just click through on the permission to see what it’s all about.
(2) Provide a forum for interested users to complain to the OS vendors, in the context of their app markets, when they detect (through debugging, network diagnostics, etc.) that app vendors actually use permissions in ways that they did not initially indicate. Basically catch out liars. If an app vendor is caught lying about what they need permissions for, and the OS vendor confirms that, then add a warning to the app installer saying “but the vendor is lying here.” I bet there would be very few lies very quickly!
(3) Enhance the OS to be able to send simulated data to apps, in place of the permissions they seek, under user control. For example, if I install an app that wants access to my camera, and I do want to run the app but don’t really want to give it camera access, I should be able to feed the app fake/random images. Same goes for network access – let the app think it’s hitting the networking API, but connect it to a loopback interface only. App wants to see my contacts? Feed it random contacts. This way, I can have more fine grained control over permissions, not just “yes, everything / no, no app” without breaking the app’s code.
As an app vendor, I’d be perfectly happy to live within these constraints. We publish apps that do want access to contacts, cameras, the network, etc. We have perfectly good reasons for these permissions and would love to be able to explain those to users at installation time. If users want to feed our app simulated data, that’s fine – they will lose some functionality, but gain some comfort. That’s totally fine.
As a phone user, I’d also love to have this kind of control. Install the apps I want but limit what permissions they get based on my personal preferences.
So how about it, Google and Apple? These are technically minor enhancements with a major, positive impact on the security of your app ecosystems.