Changing Permission Settings

MIDP implementors need to give users a way to edit the permission settings for MIDlet suites. As Screenshot shows, the settings are usually most relevant for untrusted MIDlets but the security setting for the auto-invoke function group impacts trusted MIDlets as well. (See "Security for Push Functionality" on page 228 for more information.) This section covers two approaches to giving users access to permission settings: accessing permission settings from the operating environment and accessing permission settings from inside a running MIDlet. (There are likely to be other alternatives too, depending on your device and operating environment.) In addition, this section covers an issue that has been difficult for users: understanding Oneshot and Session interaction levels.

MIDP Implementors

Strongly Recommend: Provide a way for users to change permission settings for MIDlet suites. (A MIDlet in a suite cannot have its own security settings.) Do usability studies to make sure the mechanism is straight-forward and understandable.

Accessing Permission Settings From the Operating Environment

If a device already has a standard way to handle app settings from its operating environment, it should be possible to extend it to include security settings. Security settings would then be consistent with the operating environment of the device. For example, Screenshot shows an operating environment, which has a standard menu, that includes an app Settings command. Integrating the security settings into the existing app settings leverages the native user interface to make the security settings user interface more familiar to the user.

Screenshot Access to Security Settings

MIDP Implementors

Consider: Enable users to access permission settings from the operating environment if it is consistent with the behavior of your device, and you use native app-management functionality to manage MIDlet suites. (See for information on app management.) If your device integrates MIDP and native apps, then going to the device settings may be more natural than looking for them elsewhere.

Accessing Permission Settings From Inside a MIDlet

If a device already has a standard way to handle app settings from within its apps, users will most likely also look for them within MIDlets. The MIDP implementation could enable the user to access security settings from within the running MIDlet by adding a command to the system menu, or whatever mechanism works for the device. Giving users the ability to set security settings within a running MIDlet makes the task faster if they are already running the MIDlet. For example, there is no need for the user to exit the MIDlet to gain access to the settings user interface. However, if the user needs to change the settings for a MIDlet they are not running, this approach can be slower and more cumbersome.

MIDP Implementors

Consider: Enable users to access permission settings from inside a MIDlet if it is consistent with the behavior of the device. If users expect to find these kinds of settings inside an app, they will most likely look for them inside a MIDlet too.

If you use put access to permission settings inside the MIDlet, you must take extra care to let the user know that security settings apply to the entire MIDlet suite. This will be easier if your device exposes users to the concept of a MIDlet suite (for example, if your device has users launch a MIDlet suite and then presents an intermediate screen of choices if the suite has more than one MIDlet, as described in "Launching and Exiting MIDlet Suites" on page 190). In this case, users will be better equipped to understand that a MIDlet is part of a "package" and that security settings affect the entire package. However, if your device does not expose users to the concept of a MIDlet suite, you should let users know exactly which MIDlets would be affected by a change in the setting.

Consider: When changing settings on MIDlet suites with multiple MIDlets, consider informing users that the settings apply to all MIDlets in the suite.

Oneshot and Session Permissions

Usability studies have shown that users have a difficult time understanding the oneshot and session interaction modes even when these terms are translated into something less technical. Because oneshot must ask the user for permission every time a protected API is accessed, it can easily result in extremely annoying behavior in which the user is bombarded with multiple permission requests. In usability testing, users rarely understood the correlation between what they were doing on the screen and the prompts coming up, so it was difficult for them to figure out how to make them stop. When users did figure out Oneshot behavior, they, understandably, didn't like it. The session interaction level was confusing because users had no concept of a session. Once again, they did not correlate what they did on their device when they started an app with the idea that a "session" had started. The term session is technical jargon. One way to present these terms to users is to use phrases such as "Ask me every time." Screenshot shows a user interface for setting permission levels.

Screenshot Permission Settings User Interface