12 ms·

The average user would just click "Yes, please" without reading it (I'm even doing that myself from time to time). This is happening most of the times anyway.

by ge0rg 15y ago

The average user would just click "Yes, please" without reading it (I'm even doing that myself from time to time). This is happening most of the times anyway. There is no way to see from the installer screen, why an app requests a certain permission. One example: most launcher replacements require the CALL_PHONE permission, which comes with a big warning. This is technically required if you want to place a contact shortcut on your desktop. A better, security-wise, solution would have been to ask on-demand, when the app actually performs a permissions-requiring action, like it is done in J2ME. I suppose this was not done in Android either for software patent or for convenience reasons. Or maybe it would have gone against the usability of ad networks if you could deny the virtual Golf app access to GPS and internet...

fpgeek 15y ago
Asking on-demand for everything lands you in the usability mess that is Vista's UAC. There are plenty of places where permissions should be more fine-grained, but doing that in a usable way is not easy. Personally, I'd like to see a distinction between "required" and "optional" permissions (with always deny, prompt and always grant alternatives for optional ones). Of course, there would still be a lot of tricky issues to sort out (e.g. how do you encourage developers to expose some permissions as optional not required?), but I think that exposing more permissions for direct user management, while trying to minimize the effort required might might strike a better balance over the long run.
- 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 ago
    Oh, 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.
TazeTSchnitzel 15y ago
>ask on-demand, when the app actually performs a permissions-requiring action, like it is done in J2ME. I own a cheap feature phone with MIDP app support. (J2ME) I don't think that's a wise choice. In Opera Mini I press through the "allow network access" screen every single time I use it, because, presumably for security reasons, I can't choose "always allow" (maybe because app isn't signed by carrier certificate??) It's even worse than asking once as you train yourself to click/tap/press through the prompt whenever you use the app, so if it suddenly changed from "access internet" to "make phone calls", I might not notice.

by ge0rg 15y ago

fpgeek 15y ago

Asking on-demand for everything lands you in the usability mess that is Vista's UAC. There are plenty of places where permissions should be more fine-grained, but doing that in a usable way is not easy. Personally, I'd like to see a distinction between "required" and "optional" permissions (with always deny, prompt and always grant alternatives for optional ones). Of course, there would still be a lot of tricky issues to sort out (e.g. how do you encourage developers to expose some permissions as optional not required?), but I think that exposing more permissions for direct user management, while trying to minimize the effort required might might strike a better balance over the long run.

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 ago
  Oh, 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.

TazeTSchnitzel 15y ago

>ask on-demand, when the app actually performs a permissions-requiring action, like it is done in J2ME. I own a cheap feature phone with MIDP app support. (J2ME) I don't think that's a wise choice. In Opera Mini I press through the "allow network access" screen every single time I use it, because, presumably for security reasons, I can't choose "always allow" (maybe because app isn't signed by carrier certificate??) It's even worse than asking once as you train yourself to click/tap/press through the prompt whenever you use the app, so if it suddenly changed from "access internet" to "make phone calls", I might not notice.