BlackBerry Developer's Blog

[#1]

 

In part one of our three-part series on BlackBerry® security, we discussed the nuances of enterprise IT policy. Today, we'll discuss application control. 

In contrast to IT policy, which IT administrators use to manage and control employee use of BlackBerry smartphones, application control refers to a security setting that can be managed by the end-user and/or the IT administrator (if the user is connected to a BlackBerry Enterprise Server) that defines application behavior on BlackBerry® smartphones. Specifically, application control allows IT administrators to define whether or not applications can make network connections, play media, access the BlackBerry® Calendar… etc.

These settings are configurable by either the end user or the BlackBerry Enterprise Server admin. It’s important to note this subtle difference: because application control can be configured by the user, the BlackBerry smartphone does not need to be connected to a BlackBerry Enterprise Server to use them (whereas for IT policy to be applied the BlackBerry smartphone has to be connected to a BlackBerry Enterprise Server).

BlackBerry smartphone users with experience installing applications are likely familiar with application control. In BlackBerry® Device Software 4.6 (first introduced with the BlackBerry® Bold™ smartphone) and above, users encounter application control as soon as the installed application is first executed:

"Would you like to grant [Application Name] Trusted Application status?"

If the user selects "Yes", then your application will be given all the permissions commonly needed for normal execution, i.e. all permissions will be set to “Allow” with the exception of:

• Prompt - Recording, Security Timer Reset
• Deny - Input Simulation, Browser Filtering, Display Information While Locked

Alternatively, if the user selects "No", it's not the end of the world; it just means that your application will be given the default set of permissions. For BlackBerry smartphones that are connected to a BlackBerry Enterprise Server, all permissions are set to “Allow” with the exception of:

• Prompt - Recording, Phone, Location Data, Server Network, Internet
• Deny - Browser Filtering, Input Simulation, Security Timer Reset, Display Information While Locked

For smartphones that are not connected to a BlackBerry Enterprise Server, all permissions are set to “Allow” with the exception of:

• Prompt - Recording, Phone, Location Data
• Deny - Browser Filtering, Input Simulation, Security Timer Reset, Display Information While Locked

Regardless of what the user selects, on first run of your application, it's a good idea to check what permissions are assigned to your application, using ApplicationPermissionsManager.getApplicationPermissions(). All application permissions have a setting of “Allow” and “Deny”, and some have a tertiary setting:  “Prompt”. If a permission is set to “Prompt”, the user will receive a dialog like the one below when you use an API that triggers it:

"The application [Application Name] has requested a http connection to [domain X]"

At this point, the user is given the choice to “Allow” or “Deny” the request. If they select “Allow” (and check the box to not be asked again), the value of the permission will be changed from “Prompt” to “Allow” and your API call will succeed.  However, if the user selects “Deny”, then your application will receive either a ControlledAccessException or a SecurityException, depending on the method definition.

It is probably best to avoid these prompts in the first place. Since there's no magic formula that will allow you to eliminate all these prompts, your best bet is to group them into a single request, using ApplicationPermissionsManager.invokePermissionRequest (ApplicationPermissions requestedPermissions) for the permission values your application will require. Calling this method will first present the user with a dialog indicating to the user that your application is attempting to change permissions, and then display a screen with all requested permissions, which requires the user to save the settings presented to them. Since developers don't have the ability to control the user interface for either of these screens, it's recommended that you inform the user what your application is about to do before blindly launching into the permission request. 

Lastly, if despite all your best efforts, the user still hasn't granted you permission access beyond “Prompt”, you do have the ability to provide more information to the user explaining your reasoning for leveraging a certain function. To explain, let's return to the http message we got:

"Would you like to grant [Application Name] Trusted Application status?"

Using the ReasonProvider API, you can attach your own message to this dialog prompt, contained within a link for "Details...". If the user clicks this link, your message will be displayed to the user, allowing you to explain why your application needs this permission:

"My application needs to open a network connection so that it can download pictures from your favorite website." 

 

This approach eases the minds of your users by providing them all the information they need to make confident decisions about your application. 

For more information on the various application control settings that can be applied to your application, see the Javadoc for the ApplicationPermissions class, which defines constants for each permission. 

In part three of this series, we'll address the topic of code signing. Stay tuned!

Message Edited by bzubert on 09-28-2009 05:39 PM