Share via


Windows phone capabilities security model

Today, Microsoft released the Windows Phone Developer Tools CTP- April Refresh.  You can find most of the details on the new features for this release at the Windows Phone developer blog.

One of these new features is the capabilities-driven security model.

What are capabilities?
A Capability is defined as a resource for which privacy, security, cost or business concerns exist.  Examples of capabilities include GPS, camera, microphone, SMS or sensors. 

As of April Refresh, the following capabilities have been disclosed:

Capability Id/Name Description
ID_CAP_NETWORKING Apps with access to network services. Disclosed because services could incur cost when roaming.
ID_CAP_LOCATION Apps with access to location services.
ID_CAP_MICROPHONE Apps that access the microphone; can record without visual indication that recording is taking place.
ID_CAP_MEDIALIB Apps that can access media library.
ID_CAP_GAMERSERVICES Apps that interact with XBOX live APIs.  Disclosed due to privacy since data is shared with XBOX.
ID_CAP_PHONEDIALER Apps that place phone calls; possibly without visual indication to end-user.
ID_CAP_PUSH_NOTIFICATION Apps can receive push notifications from internet service; disclosed because services could incur cost when roaming.
ID_CAP_WEBBROWSERCOMPONENT Apps that will use the webbrowser component; if script is turned on, this can have security risks.

*Note: I am only listing the ones publicly disclosed; there are more capabilities, but some are specific to mobile operators and OEMs, others I have not seen publicly disclosed so I am not comfortable sharing.

Why do we have/need capabilities?
Windows Phone leverages capabilities to:

  • Decrease the attack surface.  Capabilities are used by the package loader at install-time to create a security chamber within which the application will execute. This chamber is created once at install-time and used from there-on.
  • Ensure proper disclosure happens to the end-user. Each application discloses its capabilities.
    Pending the capabilities used (and maybe the marketplace) there will be several types of disclosures:
    • Disclosure on the application details page in the marketplace  - is the least
    • Disclosure with a prompt at purchase time, for those capabilities that have legal requirements
    • Disclosure with-in the app, when a capability is about to be used.

As a developer, how do I code or prepare for capabilities?
It is very simple, your application includes the list of capabilities it needs in WMAppManifest.xml.
Starting with the April CTP Refresh, when you create a new Windows Phone Application,  the tools automatically include the following capabilities declaration in the WMAppManifest.xml file:

<App xmlns="" … >
      <Capabilities>
     <Capability Name="ID_CAP_NETWORKING" />
     <Capability Name="ID_CAP_LOCATION" />
     <Capability Name="ID_CAP_SENSORS" />
     <Capability Name="ID_CAP_MICROPHONE" />
     <Capability Name="ID_CAP_MEDIALIB" />
     <Capability Name="ID_CAP_GAMERSERVICES" />
     <Capability Name="ID_CAP_PHONEDIALER" />
     <Capability Name="ID_CAP_PUSH_NOTIFICATION" />
     <Capability Name="ID_CAP_WEBBROWSERCOMPONENT" />
   </Capabilities>

This manifest is requesting all capabilities.  If you do not need a specific capability, you can just remove or comment out the capability within the manifest.

If you do not request a capability in your manifest, and try to use a feature restricted by this capability, you will get an
UnauthorizedAccessException  with an “Access denied” message. The exception will not happen until you try to use the capability. So your app will load and run fine, up to the point when you try to use the capability and then kaboom! busted!

There is no developer API to check if you have a capability. The assumption is if your application is installed, you got the capabilities you requested, and you should party. If you did not request the right ones, you will then meet the UnauthorizedAccessException we met in the last paragraph.

 

Any extra tips?
For now, as you are developing and likely don’t have a phone, I recommend you stick to the default capabilities (all).  There are still some scenarios that require a capability and is not obvious from the descriptions I have seen. Here is the ones I have seen so far: 

Capability class or namespace that requires it
ID_CAP_MEDIALIB MediaStreamSource, Microsoft.Devices.Radio, Microsoft.Xna.Framework.Media.MediaLibrary and MediaSource, Microsoft.Devices.MediaHistory
ID_CAP_NETWORKING System.Net, Microsoft.Xna.Framework.GamerServices.GamerServicesComponent, WebBrowser class, Smooth Streaming Media Element (SSME) ID_CAP_PUSH_NOTIFICATION
ID_CAP_SENSORS Microsoft.Devices.Sensors
ID_CAP_MICROPHONE Microsoft.Xna.Framework.Audio.Microphone
ID_CAP_PHONEDIALER Microsoft.Phone.Tasks
ID_CAP_PUSH_NOTIFICATION Microsoft.Phone.Notification
ID_CAP_WEBBROWSERCOMPONENT WebBrowser class
ID_CAP_LOCATION System.Device.Location

 

 

Stay tuned for more.  Please let me know via comments or email if you find one I missed.