Function Groups: Permissions in a Usable Interface

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 [19]. (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.

Strongly Recommend: Use function groups in your user interface—during installation, in user prompts (runtime security warnings and security errors), and when the user can set permission levels. In other words, use them where ever the user will encounter security.

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:

• Network- and cost-related groups:

  Net Access: permissions for functions that result in an active network data connection
  
  

  Messaging: permissions for functions that allow sending or receiving messages
  
  

  app Auto-Invocation: permissions for functions that allow a MIDlet to be invoked automatically by the push or alarm functionality
  
  

  Local Connectivity: permissions for functions that activate a local port to establish a connection
  
  

• Privacy-related groups: This covers multimedia recording, which represents permissions for functions that capture still images, tape video, or record audio clips.

MIDP Implementors

Strongly Recommend: Whenever the user is shown a prompt or permission request, instead of showing them the actual API call or using a technical term, consider using a function group to present the concept. Use terms familiar to the user.

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. Screenshot shows a mock-up of a request.

Screenshot Permission Request for the User

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.)