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!

So you’ve had your stroke of genius, you’ve developed the BlackBerry® smartphone application that’s going to sell a million copies on BlackBerry App World™, and you’re ready for your final end-to-end testing on a live device.  You put the application up on your web server, enter the URL into the BlackBerry® Browser, choose the option to download, and then half way through, the download comes to a halt with this message:

“This application does not contain a signature. It might not be from a trusted source. Do you want to proceed?”

Your mind starts racing.  “How are my users going to react?  How do I make this message go away?”

This is the first of a three-part series of blog posts that will outline how consumer applications are handled from a security perspective in the enterprise with BlackBerry Enterprise® Server.  First and foremost, it is important to understand that there are two categories of security to consider: IT policy and application control. In part one of this series, we’ll cover IT policy; in part two, we’ll cover application control; in part three, we’ll talk about code signing and how that affects application development regarding these two categories.

IT policy is a security setting in BlackBerry Enterprise Server that IT administrators in medium-to-large sized organizations use to manage and control employee use of BlackBerry smartphones.  For example, an IT administrator could set an IT policy that allows or prevents use of the camera, phone service, the browser, etc.  IT policy only applies to users who are connected to a BlackBerry® Enterprise Server.

When are you most likely to encounter IT policy? Typically only in organizations that require some level of security.  As an application developer, if you don’t have the time to learn about all of the various IT policy settings that can affect the use of your applicaton within these organizations, then at least take note of the big one: Disallow Third Party Application Download.  How will you know if you’ve run into this setting?  When downloading an application via over-the-air download, users will get the following error:

“Download Failed: 910 Application authorization failure.”

In order to get your application on this user’s BlackBerry smartphone, you’ll need to convince the BES administrator to either relax this setting or white list your application.  The good news is that smartphone users are not likely to encounter this setting very often at all; most administrators will use the default IT policy settings that are set in BlackBerry Enterprise Server, and these settings are application friendly.

For more information on IT policy settings for BlackBerry smartphones connected to a BlackBerry Enterprise Server, please see the BlackBerry Enterprise Server Policy Reference Guide.  Note:  Should you wish to query any IT policy values from within your application, see the javadoc for the ITPolicy class.

Stay tuned for part two of this series!