On Sat, Aug 28, 2010 at 4:00 PM, Dianne Hackborn <[email protected]> wrote: > My focus right now is on simplifying permissions, giving apps other ways to > do things that are safe without requiring permissions, etc. Making things > more complex for users is not desired.
Let's take the case of Evernote, since I happened to blog about this very topic a little while ago: http://commonsware.com/blog/2010/08/12/evernote-why-you-need-think-about-permissions.html Evernote's options are: 1. Keep READ_CONTACTS. Lose some percentage of prospective users as a result (don't trust apps with both INTERNET and READ_CONTACTS). Those who elect to install Evernote anyway will be more prone to "tune out" the actual permissions in lieu of trusting brands. Those who do will be more prone to malware masquerading as trusted brands. 2. Drop READ_CONTACTS and the resulting functionality. Lose some percentage of prospective users as a result (weaker note-sharing options). 3. Move READ_CONTACTS into some sort of plug-in/add-on APK, so the main Evernote app lacks the permission, but those who also install the add-on get the additional feature. Now some percentage of the users have 2x the upgrades to deal with and Evernote has 2x the apps to deal with. What I'd like to see is: 4. Evernote makes READ_CONTACTS optional. Users see that READ_CONTACTS is optional, and those who are concerned about it can go toggle it off. Evernote adds an if() statement somewhere in its code to detect whether the optional permission was granted and uses that to determine whether to enable/disable the button/menu choice/whatever that requires READ_CONTACTS. For security-unconscious users, the flow would be totally unchanged. Other than "(optional)" appearing as part of the permission description, they would experience no differences from what they get today. This is about as "minimally invasive" as you can get. For security-conscious users, there is one change to the application details screen (or whatever the official name is for Settings > Applications > Manage Applications > (list of apps) > (application details screen)). A button is added to the "Permissions" category, labeled "Configure" or something, which is enabled if there are 1+ optional permissions declared for the app. Clicking that button leads to a preference screen with CheckboxPreferences for each optional permission. This does not seem particularly complex for users, and only those specifically interested in security would ever go down this path. Developers would: -- add android:required="false" to the <uses-permission> element for any they feel is optional -- call checkSelfPermission() (method added to Context) to see if they hold the permission at runtime and use that to control application flow -- have a way of getting an Intent to start the "configure" activity, to lead users to the screen to toggle on/off optional permissions for their app (not required, but probably handy for usability, just like we can steer people to the settings screen to enable GPS) This is not as powerful as truly asking for permissions on the fly, but I don't see how to do that without adding significant UX issues. OTOH, I think that what I have described here can handle a good chunk of the concerns developers have cited in this thread, without (IMHO) materially increasing complexity for most users. In fact, I'd argue it is less complex than the add-on APK strategy (#3 above) that we're probably going to have to use to deal with this problem in the absence of some better solution. It also has the advantage of being backwards-compatible, since existing permissions would have android:required="true" by default. Thoughts? -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9 Available! -- 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
