April 19, 2011, 10:08 p.m.
posted by evil
MIDP implementations with security policies that incorporate more than one permission domain are likely to have long lists of protected APIs. If a prompt had to be presented for every permission, consumers would be overwhelmed and probably confused. They would not be likely to use that device or service again.
Extensive user studies on the use of certificates and security in web browsers have shown that most users have little patience for reading long tomes explaining why they need to approve a security request. They are also easily confused by the technical terms used, the many dialogs that can appear, and so on. These problems are compounded when the device being targeted has a small display and has different primary tasks than a browser.
The function groups model can be used to simplify permission requests. Function groups were first proposed in the Recommended Security Policy for GSM/UMTS Compliant Devices, which is an addendum to the MIDP 2.0 Specification . (Note that because security is an evolving area, this addendum is only a recommended practice, not a specification requirement.)
Function groups simplify the presentation of permissions by creating sets of related permissions. The user then interacts with the function group instead of with individual permissions. Any time a user changes the permission level for the function group, it affects all of the group's individual permissions.
The following list is the minimum recommended set of function groups, which set covers most of the basic functions expected to be on MIDP 2.0 devices:
For example, the Network Access function group could be referred to as airtime. The user could then be asked if they are willing to give a MIDlet permission to use airtime. Airtime, in the United States, is the common term used by carriers to refer to the minutes the user pays for. The text of the permission request should reinforce any potential side effects like cost. Figure shows a mock-up of a request.
Instead of being confusing to the user, having the permission request use the common term "airtime" reminds the user that granting permission to the MIDlet could result in charges on their next bill. In addition, because the user grants the MIDlet permission to access functionality in the function group, the number of permission prompts might also be reduced. (For example, the user would not have to grant separate permissions for the MIDlet to use HTTP and HTTPS if they were both in the Network Access function group.)