I had this idea a while back, but after giving it a lot of thought, I decided it was not entirely the correct approach. The reason is that the app installer is one of the fundamental protections that the user has against malware. As such, the user must be confident in believing every piece of information it presents to them. If an application developer chooses to lie about the reasons for requesting a particular permission, and this phony information is displayed as part of the installation process, it will either reduce the trust users have in the installer, or they will not doubt it. Neither is a good outcome.
If the information was used for display elsewhere, eg. on a separate info screen provided by the market, then I wouldn't have the same degree of concern. About 6 months ago (when I was last giving this some thought) I made a suggestion for what I felt was a good middleground solution for the problem of applications requesting lots permissions but I can't recall where I posted it, so I'll repeat it here. Its almost inevitable that, as applications grow and attempt to distinguish themselves, they will accrue the need for permissions; often permissions that are need very rarely. I think that the archetypal example is a simple application that displays information from the web (INTERNET permission needed) that wants to offer a 'tell a friend feature' (READ_CONTACTS permission needed). The combination of these always makes me hesitate since a malicious application could harvest all of my contact details. The argument against allowing users to choose which permissions they want to grant is complexity, for both the user and the developer (I'm still not convinced that the complexity for the developer is particularly great, but others are). My solution is to allow the developer to mark particular uses-permissions as optional. So a developer who can't handle (due to complexity, ability or timescales) permission associated failures can just leave them as required. Naturally, optional permissions can be refused by a user but the market could choose not to present the option on more trivial permissions (like vibrating the phone). This approach has the benefit that applications can contribute in sensibly narrowing the choices for the user (eg. in the archetype above, only READ_CONTACTS would be optional). Tom. 2009/2/6 Christoph Studer <[email protected]> > > The application developer could specify a reason for each > <uses-permission> in the manifest. The Market and the APK installer > could then somehow make this information available to the user. > > I know the permissions screen is one of the very few don't-touch UIs > in Android and should not be watered down with developer provided > content. The UI really would've to make sure that users know which > information can be trusted and which can't. > So this would probably require a new screen just showing the > explanations or having the user click on some sort of button to reveal > the developer's explanation. > > Or maybe that's all just too complicated for the average user and we > have to stick with explanations in the user guide (which unfortunately > user's most of the time won't see before they install). > > Christoph > > > On Fri, Feb 6, 2009 at 4:00 PM, Nanard <[email protected]> wrote: > > > > I suppose many application creator, had fun creating great app during > > 1 year (for ADC1) on their PC using the emulator. > > > > And playing with all Android API. > > > > During this great coding time they didn't really care about > > authorizations : they just have to add it in a xml file. > > > > Once 'real' users, and 'real' phone arrived, well... this popup > > informing the user of the required permission arrives, and... not all > > application developper though about that ! > > > > I am in this case. > > > > I think google should keep this permission check by phone owner, and > > that application developer should explain in their User Guide the > > reasons why those permissions are required. > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
