W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2006

[whatwg] Web widgets

From: Benjamin Smedberg <benjamin@smedbergs.us>
Date: Wed, 07 Jun 2006 16:23:32 -0400
Message-ID: <448735C4.2000304@smedbergs.us>
A couple weeks ago I was at XTech and talked with some Opera developers 
about the possibility of standardizing a method of doing "web widgets" 
similar to the current Opera widgets (and somewhat similar to Dashboard 
widgets). I am planning on implementing a similar widget functionality for 
mozilla-based browsers and wanted to share a common API that web developers 
could count on for multiple browsers.

Currently, Opera widgets are packaged in an archive (ZIP format) and are 
identified to the browser using a special mimetype. Once installed, widgets 
have elevated privileges, including the ability to perform XMLHttpRequests 
from any domain. Dashboard widgets have even more power, basically granting 
them complete control over the computer.

I have a few issues with the current Opera widget API:

1) By default, widgets should have the permissions of the website they are 
downloaded from. This makes it safe and easy for users to try widgets 
without worrying that the widget might steal personal information. I see the 
use for granting a widget elevated privileges, but I'm not sure how to 
design a sufficiently scary warning that users won't just automatically accept.

e.g. I just installed the "Functions 2d" widget in Opera. There is no reason 
I can see for this widget to have any special privileges (I don't know or 
trust the author). It makes me nervous to install the widget, and I don't 
like feeling nervous.

2) Packaging and downloading widgets as a special archive may not be 
necessary or desirable in all cases. I'd like the mozilla widget 
implementation to use ordinary HTTP caching mechanisms to save the widget data:

window.open("http://example.org/widget.html", "_blank", 
"all=no,widget=yes,width=200,height=150");

This would open the specfied webpage as a widget; if the user decides to 
keep the widget on their desktop, the browser will pin that page in the HTTP 
cache.

For more advanced widgets that need multiple files pinned in the cache for 
offline use, authors should make use of the JAR protocol:

window.open("jar:http://examples.org/widget.jar!/index.svg", "_blank", 
"all=no,widget=yes,width=200,height=150");

This has the added advantage that in older browser which don't have special 
widget support, the widget is opened in a mostly-chromeless browser window 
and can function in basically the same way the widget would behave in a 
newer browser.

3) Widgets don't have any browser UI for showing security information.

Once you have widgets with the permissions of a website, users should be 
able to figure out which website the widget comes from. This is especially 
important in that case of widgets from secure websites that were given the 
privileges of a certificate. This could be as simple as a little system-menu 
button on one of the corners of the widget which gives access to the SSL 
security info.

If/when agreement about widget APIs is reached, should these be included in 
the Web Applications spec?

--BDS

cross-posted to dev-apps-firefox and whatwg.
Received on Wednesday, 7 June 2006 13:23:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:27 UTC