Widget Anatomy – Security Insights

Widget Anatomy – Security Insights

  • Comments 5
  • Likes

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





Starts composing an SMS message addressed to the given phone number sms:1111111111


Starts composing a mail message using the specified parameters (Like destination, subject and body) mailto:test@test.com?subject=Hello?body=From%20Here


Initiates a voice call to the given number callto:1111111111


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!

You must be logged in to comment. Sign in or Join Now
  • Hi miles

    Widgets can be only full screen apps and they are, out of the box, limited in the amount of information they can get from the device.  That said, they are extensible so if you don't care about distributing them on the Marketplace, you can use COM to get the data you need (community.softteq.com/.../extending-the-widget-model-on-windows-mobile-6-5.aspx).

    Hi scrodine,

    WM has supported both for a while now so it was best to just keep for widgets to support the same

  • scronide
    21 Posts

    I'm not a Windows Mobile developer, but was wondering why you support both callto: and tel: URI schemes? I know tel: has been defined in a couple of RFCs and callto: has been used by NetMeeting and Skype but, even supporting both, wouldn't it make sense to promote one option over the other for the sake of simplicity?

  • mies
    2 Posts

    Would you explain please if widgets can act as a part of phone desktop similar to Vista Widgets or Samsung TouchWiz widgets or WM home screen plugins. According to available articles widget takes whole screen – simply browser without browser menu.  It seems that phone specific API is to say it gently: very limited. Is it possible to call .NET compact framework objects from within widgets. If not then how to use contacts, calendar, GPS, compass, g-sensor, send and intercepts SMS in background and utilize another device specific API.

  • Hello Me1.

    Windows Mobile 6.5 out of the box will not install widgets that do not come from trusted sources like the Marketplace.  That said, developers and enthusiasts can enable the installer so it will be directly executed by the OS when a widget file is side-loaded on the device from untrusted sources.  Do this with care since WM 6.5 can't certify the authenticity of the widget so treat it as you would with any untrusted web site.

    The process to re-enable the installer requires a registry editor, the details are already documented on other sites so a simple Bing search should take you on the right direction.  

    Speaking of Bing, someone should write a Bing widget that fetches the cool images from their home page for our viewing pleasure :)...

  • Me1
    1 Posts

    It is not clear if widgets which are provided by developers on their own servers can be installed on WM 6.5. I have read that if we provide the right registry keys and register the wmwidgetinstaller.exe via a provisioning doc widgets can be installed. Can you please explain this? Thank you.