I think there is enough evidence that asking permission at time of need doesn't generally work -- see the MIDP experience, Windows Vista/7 security, etc. There is a fundamental problem that at the point you ask the permission, the user is wanting to accomplish some task at hand, and all you are doing is bugging them.
And it gets much worse when you consider applications being able to run in the background. Do permission requests pop up on users from the background? Does a notification get posted that they respond (or not respond) to at their leisure? If you have a wall of permissions, the first thing I would suggest is looking at those and seeing if you can trim it down. In fact, doing things that make it easier for apps to make use of lots of permissions are to me counter-productive -- it is a good thing to make lots of permission use a harder road. I just had a look through the apps installed on my phone, and the *vast* majority of them only require a couple permissions. So someone who is using a large number of permissions is going to stand out from what user's normally see, as well they should. >From the platform side, we also need to avoid making it easy to have lots of permissions. We need to be continuing to design the platform to reduce the permissions that apps need. For example, the window flag to keep the screen on avoids the need of the power manager permission for most applications; we should beef up our intent interactions with the contacts app so applications can work with the user to select and modify applications through that without using permissions; etc. On Fri, Aug 27, 2010 at 3:09 PM, Greg Giacovelli <[email protected]>wrote: > I think I see where you are coming from to a point however honestly I > dislike the global statement. I mean a wall of permissions is going to > turn into white noise to users (in which case the permission could be > for Brick for all they care leading to spam) or paranoid users (in > which case your platform dies from no use, but is perceived as lack of > creativity from developers). I am just saying it would be nice, from a > user perspective and from a developer perspective if I could > optionally request a permission and/or upgrade to a permission via > user interaction (through a system UI that could persist a No or a > Yes). I mean if it's at install time, how do you explain to a user why > the permission is needed (They aren't engineers remember, and it's > only like 256 characters in the market description field). > > Just my two cents. > > On Aug 27, 9:45 am, Dianne Hackborn <[email protected]> wrote: > > No it must be done at install time. Honestly, this is better than > prompting > > the user all over the place when they are actually trying to do some > other > > task -- they are more likely to look at permissions (and as a whole) when > > the task at hand is installing an app. > > > > You can't intercept URIs without going through a system UI where the user > > decides what to do. Also at that point the task they are doing is "look > at > > this thing I selected," so the decision they are making (pick which will > > show the thing they are wanting to look at) is relevant to their task at > > hand. > > > > On Fri, Aug 27, 2010 at 9:34 AM, Greg Giacovelli <[email protected] > >wrote: > > > > > > > > > > > > > I suspect there has to be. I mean I saw for bluetooth there is. I was > > > wondering why it is not as easy for the other permissions. I mean heck > > > we can intercept urls without even asking a user for the most part, so > > > I would have to suspect that permissions have to have this ability. > > > > > -Greg > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to > [email protected] > > > To unsubscribe from this group, send email to > > > [email protected]<android-developers%[email protected]><android-developers%2Bunsubs > [email protected]> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
