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:

*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: 

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