Working with a Security Policy

The level of trust in a MIDlet suite is determined by the security policy on the device. A security policy associates MIDlet suites with protection domains. Each MIDlet suite belongs to one, and only one, protection domain. Protection domains list the protected APIs or functions that the device may allow the associated MIDlet suites to access. Protection domains also specify the maximum amount of access to the protected functions that its MIDlet suites can be given. For example, the protection domain could specify that its MIDlet suites will be granted access to some protected services only after getting approval from the user. A device will most likely have at least two protection domains: trusted and untrusted. However, there may be more domains. For example, an operator domain may be required to allow the operator to install trusted MIDlets associated with their service. Domains can be created for other classes of apps as well.

MIDP Implementors

Recommend: Java graphics bulb2_icon.gif Work with operators to create a set of protection domains.

Strongly Recommend: Java graphics bulb1_icon.gif Protect the security policy and protection domain information on the device so that unauthorized entities cannot see or change it.


A protection domain lists the protected APIs or functions to which it might grant access by listing the corresponding permissions. If a permission does not appear in a protection domain, then the MIDlet suites associated with the domain are denied access to those protected functions. The name of a permission indicates the API or function it is protecting. For example, the name of the permission associated with the HTTP protocol is (See the MIDP 2.0 Specification [19] for a list of the permissions it defines.) Devices with advanced capabilities, such as multimedia recording or certain kinds of messaging, may have additional protected APIs, and therefore additional permissions. For example, the ability to record audio or video data may be protected.

MIDP Implementors

Strongly Recommend: Java graphics bulb1_icon.gif Use your security policy to appropriately restrict access to protected APIs.

Note that not all APIs are protected. The MIDP 2.0 Specification identifies APIs that MIDlets must be able to run freely, without requiring permission from the user. These include APIs such as the user-interface and game functionality. (See the MIDP 2.0 Specification [19] for the full list.)

Permissions and Interaction Modes

In addition to permissions, a protection domain specifies the maximum amount of access to protected functions that a MIDlet in its domain can be granted. If the MIDlets can use the functionality without getting explicit user permission, they have an allowed permission-type. If the MIDlets must get explicit user permission before using the functionality, they have a user permission-type. The user permission type is further divided into interaction modes. The MIDP 2.0 Specification [19] defines these permissions and interaction modes:

  • Allowed permission: MIDlet suites in the protection domain can use the API or function without involving the user. The name for this interaction mode is Allowed.
  • User permission: MIDlet suites in the protection domain can use the API or function only after the user explicitly grants permission. The user is asked for permission when the MIDlet attempts to use the protected API. If the user denies permission, the MIDlet cannot make calls to the protected interfaces. Users can grant permission with one of the following interaction modes:
    Blanket: Permission is granted for every invocation of the API by a MIDlet suite until it is uninstalled or the user changes the permission.

    Session: The user is prompted when the MIDlet first attempts to use the protected API. If the user then grants permission, permission is granted until the user exits the MIDlet suite. If the user restarts the MIDlet suite, the permission request is repeated the first time the MIDlet attempts to access the protected API.

    Oneshot: Permission is granted for one and only one immediately preceding function call. Each time the MIDlet calls the protected API, the permission request is repeated.

In addition to these interaction modes, users must be given the opportunity to deny permission when they are prompted.

MIDP Implementors

Recommend: Java graphics bulb2_icon.gif Work with operators to determine which permissions and interaction modes a protection domain should contain. For example, permissions in an operator domain may have only the allowed interaction mode, and permissions in the untrusted domain may have only the user interaction modes.

Recommend: Java graphics bulb2_icon.gif Limit your use of the Oneshot interaction mode. When users have to be interrupted before every single call to a protected function, they can become very impatient.

Strongly Recommend: Java graphics bulb1_icon.gif The MIDP 2.0 Specification [19] requires that an untrusted MIDlet be allowed to use the HTTP and HTTPS protocols if the user gives permission. That is, the untrusted domain must give a user interaction mode to the permissions for HTTP and HTTPS.

app Developers

Recommend: Java graphics bulb2_icon.gif If your MIDlet is untrusted and uses protected functions, consider how often you are accessing those APIs. In certain situations, the number of prompts that the user is given could become very annoying. For example, if the permission level is set to oneshot, every access will result in a prompt to the user to ask permission to use that protected interface.