Web widgets

[Benjamin Smedberg]

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.

[Robert O'Callahan]

Benjamin Smedberg wrote:
> 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.

So basically the same machinery as for offline Web apps.

> 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.

The user still has to make some kind of decision in order to active a
widget from an untrusted site, right? We don't want to give arbitrary
sites a unilateral ability to create unlabelled windows.

Rob

[Benjamin Smedberg]

Robert O'Callahan wrote:

> So basically the same machinery as for offline Web apps.

Yes... widgets would be offline webapps writ small.

> The user still has to make some kind of decision in order to active a
> widget from an untrusted site, right? We don't want to give arbitrary
> sites a unilateral ability to create unlabelled windows.

Do you think that "widgets" should be harder to open than windows with no
chrome decorations (except for the titlebar)?

--BDS

[Robert O'Callahan]

Benjamin Smedberg wrote:

> Robert O'Callahan wrote:
>> The user still has to make some kind of decision in order to active a
>> widget from an untrusted site, right? We don't want to give arbitrary
>> sites a unilateral ability to create unlabelled windows.
>
> Do you think that "widgets" should be harder to open than windows with
> no chrome decorations (except for the titlebar)?

Yes, because they lack a titlebar. That makes it really easy to spoof
whatever you want.

Rob

[Ian Hickson]

On Wed, 7 Jun 2006, Benjamin Smedberg wrote:
> >
> > The user still has to make some kind of decision in order to active a
> > widget from an untrusted site, right? We don't want to give arbitrary
> > sites a unilateral ability to create unlabelled windows.
>
> Do you think that "widgets" should be harder to open than windows with
> no chrome decorations (except for the titlebar)?

Opening one of those requires chrome privs, right?

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'