4 ms·
Asking on-demand for everything lands you in the usability mess that is Vista's UAC. Please let me clarify: a properly designed system should allow the user to
by ge0rg 15y ago
Asking on-demand for everything lands you in the usability mess that is Vista's UAC.
Please let me clarify: a properly designed system should allow the user to "always grant" that one permission to that one app, so the total number of permissions dialog goes from 1 per app to N per app with N=number of required permissions. The advantage would be, that opposed to Windows (where you only grant one rather opaque "Administrator" permission) you will see how your current action caused the permission request.
To come back to my example: you tap on the contact shortcut on your desktop, and Android asks you:
"Launcher requests the permission to perform a (possibly billed) phone call. [Grant] [Grant always] [Deny] [Deny always]"
Of course this model does not work for all possible permissions and applications, but it is still a vast improvement over what we have now.
- fpgeek 15y agoOh, absolutely. That's pretty much the model I was trying to suggest as well, with the extra detail that users only get that prompt for "optional" permissions. "required" permissions (e.g. a browser accessing the Internet) would still be take-it-or-leave-it at installation. Though, thinking back to a Google+ post by a member of the Android team that I don't have at hand right now, there's also a place for self-certifying UI elements. IIRC, their example was a system-provided Contacts widget (where if you selected a contact using that widget from within an app, you were clearly giving the app access to that contact data). My favorite example is the crash reporter. If click the "Send Crash Report" button, you're clearly giving permission to share some, potentially private, data about the crash (and sharing even more if you also check off sending the crash log). When you can pull off those sorts of UI elements, it is ideal, but they're not general enough for everything.