The Windows Phone Capabilities Model
Microsoft recognizes that making the user experience on the phone the best it can be helps to secure greater adoption of the platform. To this end, users should never regret installing an app, and one way to ensure this is by using a security model that requires users to opt-in to certain functionality within the app, called capabilities.
A capability is a phone resource that when used by your app may bring with it privacy or security concerns, or it may incur a cost that the user should be made aware of. Examples of capabilities include the camera, geographic location services, microphone, and SMS.
Capabilities are a way of disclosing to the user what an app is potentially able to do. Your app’s capabilities are displayed to potential users, those considering downloading the app from the Windows Phone Marketplace. It is at the user’s discretion whether to download your app; if a user does not want an app to have access to, for example, the phone’s camera, the user may decide not to download that app.
You define your app’s capabilities in its WMAppManifest.xml file. When a new Windows Phone application is created, a subset of the available capabilities is included by default in the manifest file. The Windows Phone operating system grants security permissions to the application according to the capabilities listed in the manifest file. See http://bit.ly/Pj2YgE for a list of these capabilities.
When an app is submitted to the Windows Phone Marketplace, the XAP file is decompressed, validated, and repackaged. During this process the security capabilities of the app are discovered and written back to the WMAppManifest.xml file. As a result, if the manifest does not contain capabilities that are used by your app, these capabilities are inserted as part of the submission process.
Note
The capabilities specified in the WMAppManifest.xml file before submission are relevant only while debugging your app. By removing unnecessary capabilities from the manifest you ensure that no unintended capabilities have crept in during development.
Two capabilities, however, are exceptions to this process: ID_CAP_NETWORKING and ID_HW_FFCCAMERA.
If the ID_CAP_NETWORKING (networking) capability is removed from your app’s manifest, it will not be reinserted during the submission process; this enables you to prevent all network activity from your app if you want.
If the ID_HW_FFCCAMERA (front facing camera) capability is specified in your manifest file, it is not automatically removed during the submission process.
Note
After submission to the Windows Phone Marketplace, and during the capability discovery process, the Microsoft Intermediate Language (MSIL) of the assemblies located in your XAP file are analyzed. If a phone API that requires a particular capability is detected, the capability is added to the WMAppManifest.xml file. This occurs even if your app never calls the code at runtime. It is therefore important to be mindful that referencing another assembly can inadvertently add security capabilities to your app if the other assembly uses an API that requires capabilities. The security capability detection mechanism is not clever enough to walk your MSIL to discover whether it is actually used; it merely identifies the presence of the API.
Note
To pass Windows Phone Marketplace certification, apps are not allowed to use P/Invoke or COM Interop.