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..
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:
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 :).
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!
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).
WM has supported both for a while now so it was best to just keep for widgets to support the same
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?
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.
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 :)...
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.