Any Android user will be familiar with the problem: you decide you need an app, do a search for it, pick one you like, maybe look at the screenshots and read the reviews, and finally press “install” to be greeted by this:
Well, maybe a flashlight which requires “Device & app history” and “Device ID & call information” sounds a bit suspect to you, so you backtrack and find a better one which won’t obviously sell your personal information to advertisers. Or maybe you’re not entirely happy with the permission request, but by this stage you just want to start using your flashlight, so you go ahead and install it anyway.
In either of these cases, the problem is that the permissions request is positioned right at the end of the app-install flow, which runs something like this:
- Launch store
- Search for app
- Select desired app from list
- Press “Install” (if it’s free) or the displayed cost (if it’s paid)
- Press “Accept” on the permissions request
By the time you get to permissions, you’ve made a mental commitment to the particular app, and reversing the process costs time and mental energy. Admittedly, these costs are very small, but they don’t have to be large — they only have to be more work than the alternative (going ahead with the install) to cause some people, some of the time, to give permissions to apps which they are not, in general, comfortable giving.
Three possible solutions come to mind, but they are all dreadful.
Bad option 1: Allow the device user to choose which permissions they are happy with for a particular search. So for example you may never want to give your flashlight app access to your precise location, you indicate this to the store somehow, and you never see apps which request that particular permission. This is great in that it gives people control, bad in that most people won’t bother and that it would seem to discourage innovative apps which do interesting things but require more permissions to do them.
Bad option 2: The store itself ranks apps within a category according to their permission requests, and uses the rank to indicate positioning in search results. This removes the burden of permission-curation from the user, but gives it to a third party, which may not be beneficial. It also has the same innovation-stifling problem as option 1.
Bad option 3: The store displays a permission summary on, for example, the search results page. This could be very high-level, using (for example) icons to indicate access to personally-identifying information, device location, social graph, etc. This seems a little better than the first two options, but it’s hard to see how much useful information could be conveyed in a search result without overwhelming people.
Ultimately, there is no good solution here because the entire concept of application permissions is flawed and somewhat useless. People don’t (or shouldn’t) care that an app has access to their data, they should care what the app does with it — the focus should be on data in motion rather than on data at rest. Nothing yet (as far as I know) does this. More thoughts on it in the next post.