Prompting the User for Permission

When a MIDlet tries to call a protected API, use protected functions, or, in some cases, be automatically launched, the MIDP implementation checks whether the MIDlet has been granted permission. If it must, the MIDP implementation queries the user about whether to grant the permission. If the MIDlet is successfully authorized, the MIDP implementation runs the protected code. If the MIDlet has not been granted access, the MIDP implementation throws a SecurityException. (See Programming Wireless Devices with the Java 2 Platform, Micro version [17] for information on the exception.) Permissions that have user interaction levels can cause the MIDP implementation to query the user. For example, if the MIDlet is running and the user has set the permission's interaction level to oneshot, the MIDP implementation will have to ask the user for permission to run the protected function. Querying the user for permission should ask only one straightforward question and use every-day language.

MIDP Implementors

Strongly Recommend: Java graphics bulb1_icon.gif Keep the permission request simple and straightforward: ask users only for permission. Do not combine the permission request with other tasks, such as changing the MIDlet's interaction level. With the simple request, such as the one shown in Screenshot, a reply of Yes means they grant permission, No means they deny permission.

Screenshot Straightforward, Yes-or-No Permission Request

Java graphics 15fig05.gif

Asking for permission assumes the user can understand the prompt and make an intelligent decision. It also assumes that the user has some knowledge about security concepts, which is not necessarily a valid assumption to make. Don't compound the complexity by asking even more of the user. If your implementation tries to do more than ask for permission, for example by also offering the ability to change the interaction level, the interaction will not be simple and straightforward. Users will not be able to get through the runtime warning as quickly, and could become seriously confused. In user studies on the MIDP 2.0 Reference Implementation where permission level options were combined with the permission question, some consumers were unable to figure out what to do. (Screenshot shows a mock-up of such a screen.) The result was a security nightmare—in some cases, users just selected anything and did not understand the implications of their choice. They just wanted the prompt to go away.

Screenshot Not Recommended: Combined Permission Request and Level-Setting

Java graphics 15fig06.gif

Instead of combining the permission request with the ability to set the permission level, have the user do the two tasks separately. Make sure the user has access to a security-settings user interface where permission levels can be presented in a more understandable and less stressful context. Screenshot shows screens that provide such settings.

Screenshot MIDP Reference Implementation's Settings User Interface

Java graphics 15fig07.gif

MIDP Implementors

Strongly Recommend: Java graphics bulb1_icon.gif If you do decide to allow users to change or set permissions as part of a permissions prompt, as well as with a security-setting user interface, synchronize the two user interfaces. Have them use similar words and, if the user changes or sets the interaction level with one method, make sure the change is shown the next time the user sees the permission.

Strongly Recommend: Java graphics bulb1_icon.gif When you ask users for permissions, translate technical terms into more common ones. For example, instead of asking whether the MIDlet can "use a datagram receiver API," ask whether it can use airtime. Screenshot shows a question from the MIDP Reference Implementation that uses ordinary instead of technical language.