Windows Mobile 6.5 Widget Manifest Permissions

Windows Mobile 6.5 introduced support for installable web widgets built on web standards using the W3C Widgets specification. Security and permission models for these widgets were governed entirely by the widget's packaging and its configuration document, the config.xml manifest file. This article outlines the specific XML elements, security attributes, and signing requirements that dictated how a Windows Mobile 6.5 web widget gained network access and system privileges.

The Configuration Manifest: config.xml

Every Windows Mobile 6.5 widget required a config.xml file located at the root of the .wgt archive. This document used the W3C Widget 1.0 namespace (http://www.w3.org/ns/widgets) to establish metadata, runtime behaviors, and access parameters. Without a valid config.xml, Windows Mobile 6.5 treated the package as invalid and refused installation.

Network Permissions: The <access> Element

By default, the Windows Mobile 6.5 widget runtime restricted external network communication to protect the user from unauthorized data transmission. To communicate with external servers, developers had to explicitly define outbound connectivity rules using the <access> element.

  • Network Activation: To grant a widget network communication privileges, the manifest included the <access> tag with specific URI targets.
  • Domain Whitelisting: Using the subdomains attribute, developers could restrict access to exact hostnames or broaden access across an entire domain structure. For example: 
    <access origin="http://example.com" subdomains="true" />
  • Full Network Access: Wildcard access (origin="*") allowed unrestricted HTTP and HTTPS traffic, but this required appropriate security capabilities depending on device security policies.

Hardware and API Permissions: The <feature> Element

Access to native device components, underlying mobile services, and specialized Microsoft APIs required the <feature> element inside config.xml.

  • Feature Identification: Each capability was identified by a unique URI via the name attribute.
  • Requirement Flag: The required attribute specified whether the widget could function without the requested capability: 
    <feature name="http://api.example.org/device/system" required="true" />
    If required="true" was set and the host device could not grant the permission due to security policies or hardware limitations, the widget would fail to install or initialize.

Digital Signatures and Security Roles

The manifest alone was not always sufficient to unlock sensitive privileges. Windows Mobile 6.5 enforced a multi-tiered security model where permissions declared in config.xml interacted directly with code signing:

  1. Unsigned Widgets: Ran in the most restricted sandbox. Even if the manifest requested privileged features or broad network access, the operating system blocked capabilities that could affect system integrity or personal data.
  2. Signed Widgets: Widgets signed with an Authenticode certificate recognized by the device's certificate store could access privileged APIs declared via <feature> and unrestricted network endpoints declared via <access>.

Security policy managers on Windows Mobile 6.5 cross-referenced the declarations in config.xml with the certificate's trust level (such as Privileged vs. Unprivileged certificates) at installation time, presenting users with permission prompts or silently rejecting installation if the declared permissions exceeded the signature's authorization.