Re: Widgets spec (ACTION-37)

Just as additional information for those who haven't used any of the 
widget frameworks, many of the widgets fall into two categories:

1) Display of system information (battery meter, CPU usage, system time)
2) Display of information coming from a source on the internet (weather, 
moon phase, number of unread web email messages)

User trust is usually determined at widget installation time instead of 
at run-time.  Thus the required act of downloading and keeping a local 
copy of that .zip.  That said, given the widget framework is a run-time 
XML/JS interpreter and a widget is defined purely as XML and Javascript, 
the packaging as a zip file is not strictly necessary from a technical 
standpoint.

--Brad

Thomas Roessler wrote:
> Per ACTION-37, I was to review the Widgets specs at [1] and [2];
> these are, fortunately, Working Drafts.
>
> Widgets are small Web applications (HTML + CSS + Javascript) bundled
> up in a zip file with a bit of metainformation in an XML format
> that's defined in there.  Basically, these are web applications run
> locally (without even a web server); the Widgets spec is harmonizing
> existing practice from a number of corners.
>
> What are the distinguishing features for our purposes?
>
> - Widgets are epxected to run without browser chrome.  Yes, that
>   cute little clock on your Macintosh Dashboard might indeed be
>   Javascript + HTML, running on top of some part of your web
>   browser's code base.
>
> - Widgets are generally expected to have access to local resources
>   beyond what the usual browser sandbox would permit.  The details
>   of this are open.
>
> - Widgets *might* very quickly morph into general web browsing --
>   setting a link is pretty easy, isn't it?
>
> The first two points basically mean "well, these are local apps that
> use HTML&friends as a platform." The last one is where I could see
> some need for a comment from us to that group; basically, we might
> ask them to specify that when a widget starts getting web content
> from arbitrary sources, then it should morph into a full browser and
> follow whatever we recommend.
>
>
> Now, for the off-topic part: The widgets spec has a "security"
> element (which is an existentially quantified variable), and it has
> a "security model" for an openURL method which is supposed to open a
> browser. The spec says that one widget MUST NOT "access" (without
> saying clearly what this means) both intranet and Internet
> resources.  Intranet resources are defined as resources that sit in
> the private-use IPv4 networks (aka 10/8, 192.168/16, and friends).
> Bummer.  I understand that some folks at a certain browser vendor
> figured that somebody would take the bait and fix it for them.
>
> Fixing this is obviously beyond our charter; if some of you would be
> interested in reviewing a draft comment, please ping me off-list.
>
> 1. http://www.w3.org/TR/2006/WD-WAPF-REQ-20061109/
> 2. http://www.w3.org/TR/2006/WD-widgets-20061109/
>
> Thanks,
>

Received on Thursday, 7 December 2006 18:59:18 UTC