July 1, 2011, 5:56 p.m.
posted by evil
MIDP implementors need to give users a way to edit the permission settings for MIDlet suites. As Figure 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.
1 Accessing Permission Settings From the Operating Environment
If a device already has a standard way to handle application 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, Figure shows an operating environment, which has a standard menu, that includes an Application Settings command. Integrating the security settings into the existing application settings leverages the native user interface to make the security settings user interface more familiar to the user.
2 Accessing Permission Settings From Inside a MIDlet
If a device already has a standard way to handle application settings from within its applications, 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.
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.
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 application 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." Figure shows a user interface for setting permission levels.