Widget Anatomy – Security Insights

Widget Anatomy – Security Insights:
Previous post: Widget Anatomy – Performance and battery life
This is part four of my Widget Anatomy series which which will explain the ins and outs of the Widget Framework that is shipping as part of Windows Mobile 6.5.  In this installment I will discuss the Widget Framework’s security model..

Inside the sandbox – The Widget Framework security model

It is true, Widgets are executed inside a sandbox, and because of this, there are bounded to a rather strict security policy but can be summarized as follows:

1. Widgets can’t read files from the device nor can access the registry directly.  A notable exception are all files that are part of the Widget package itself.
2. Cookies can be used as temporary storage but developers are encouraged to use the persistent storage API instead.   Cookies, browser history and local cache are  isolated per widget and completely separated from the browser.
3. Widgets can’t navigate their main frame to any URL with the exception of fragment inside itself.  You can use an iframe to open a web URL though.
4. Widgets can navigate to the following specific purpose URIs

URI	Description	Example
SMS:	Starts composing an SMS message addressed to the given phone number	sms:1111111111
mailto:	Starts composing a mail message using the specified parameters (Like destination, subject and body)	mailto:test@test.com?subject=Hello?body=From%20Here
callto:	Initiates a voice call to the given number	callto:1111111111
tel:	Initiates a voice call to the given number	tel:1111111111
http:, https:	Opens the specified URI using the default browser.	http://www.microsoft.com

Widgets and the Marketplace

Windows Mobile 6.5 restricts distribution of Widgets to trusted sources only.  This means consumers will only be able to install widgets from the Marketplace and, on some cases, Mobile Operator stores directly.  This restriction was implemented because we don’t currently support digital signature verification for widget files which prevents users from being able to verify the origins and authenticity of any given widget.  This might seem a little restrictive but I believe it provides the right balance between security and flexibility, specially if you consider that there are ways to allow enthusiasts and developers to install widgets from non-trusted sources, as long as they acknowledge and understand the risks of doing so.  Use your best judgment :).

Other important security considerations

• The local persistent storage is unencrypted, use caution when storing information that should be protected in clear text.
• The widget ID is sent to the server as part of the user agent string if you would like to use it on your server for any reason.
• Widget files are stored unencrypted on the device file system so anyone with device access can potentially read them.
• Cross domain data access is allowed, this is super important for widgets since they can be used to mash up data from multiple sources.

That’s it for now, feel free to comment about any other security related questions that were not covered.
Next post: Widget Anatomy – Touch and D-Pad inputs, oh joy!