Hi all,
here is an attempt to reach consensus (defined as the position that
produces the least disagreement :) on the security model that applies
to packaged widgets.
DEFINITIONS
* feature-enabled API: an API that is for one reason or another
considered to be sensitive (typically because it has access to the
user's private data). It may be that this API can also be activated in
a broader web context (e.g. through user interaction, prompting,
etc.); but here we are considering the case where it was activated
based on processing the <feature> element in the widget's
configuration file.
* widget execution scope: this is the scope (or set of scopes, seen
as a single one for simplicity's sake) being the execution context for
code running from documents that were part of the widget package. Note
that a script loaded from an external URI into a document that is part
of the widget is running in widget execution scope.
* web execution scope: this is the scope (or set thereof) being the
execution context for code running from documents that have been
loaded off the web.
A TYPICAL USE CASE
Here's a rather trivial use case that I strongly believe that we must
enable (or rather, not disable) in order to produce a usable platform,
and from which I believe most of the security model trickles out.
Let's call it the "DahutStumbler" widget. It is very simple: it's
basically a widget that recommends specific online content based on
what your friends have liked. You launch the widget, and it goes
through your contact book looking for email addresses. If it finds any
email address that wasn't there when it was last launched, it sends
them to the backend at http://dahutstumbler.org/ so that those people
can be added as friends (this is implemented using a mixture of
BONDI's PIM contacts, local storage, and XHR â€” in other words nothing
fancy).
UI-wise it's also pretty simple: there's basically a bar on the side
that lists the ten top latest cool online stuff your friends have
liked (based on the magical Dahut Stumble algorithm). Those resources
could be pretty much anything: web pages, videos, images, whatever.
Clicking on one of the suggestions shows it on the right panel which
is larger so as to accommodate a fair chunk of content. As you look at
the content you are given a chance to rate it too, so that it may
become available for other friends in your network (which may not be
the same as the original friend's network). The latter naturally
entails that it can't be launched in a separate application â€” that
would make for a rather poor user experience.
I think that what falls out here is clear: all linked resources (a
DailyMotion video inside a blog post, links to the Dojo libraries on a
CDN, mashed up content, images included with an inlined Flickr widget,
and of course ads loaded from an arbitrary third party) MUST just
work. Equally, the original widget scope MUST have access to the phone
book (possibly through <feature>) and MUST request specific network
access within that scope (possibly through <access>). Finally, linked
content inside the iframe that is presumably being used to display the
content MUST NOT have access to that same API â€” for obvious reasons.
REQUIREMENTS
* The widget platform must be fully compatible with existing web
technology. This includes not breaking linking to JS libraries (e.g.
Dojo), embedded media (e.g. DailyMotion videos), ads, etc.
* The widget platform must not be less powerful than the web
platform.
* An execution scope that has direct access to feature-enabled APIs
must have its network access-restricted.
SECURITY MODEL
That yields the following model:
* resources inside the widget execution scope:
. have access to feature-enabled APIs
. have no network access unless enabled through <access>
* resources inside the web execution scope (e.g. loaded through an
<iframe>) use whatever rules apply for the language being used (HTML,
SVG, Flash, XUL, whatever). Typically, they have limited access to
feature-enabled APIs and various network-access policies depending on
the referencing method.
Note that it is not up to us to specify what happens in the latter
case: it is only within scope for us to specify the former.
POST SCRIPTUM â€” WEBGETS
Imagine a website that federates your online content: private pics,
address book, emails, online payment, etc., in other words some mix of
Flickr, GMail, and PayPal. It's not so hard to picture â€” your Google
account provides access to much of that, and we're heading towards
tighter integration.
This is no different from a widget running on your phone with
<feature>-enabled APIs for the Media Gallery, Messaging, and a Payment
API. It's not different /at all/, unless we make it so.
You choose to put all your data online â€” you choose to grant a widget
access to your data. Same difference. If that data is passed to an
iframe to a third party that has been compromised, the situation is
the same for both situations. Trying to invent a security model that
is more restrictive than that which applies to the above website is,
in my humble opinion, as bad an idea as it gets. At the end of the
day, it simply amounts to neutering the widget platform to make it
less powerful than the web. I don't see that as being very useful. It
also diverges widgets from the web, when our task is to erase those
boundaries.
I think that this approach is simple, does not tie down the DAP WG,
does not introduce security issues that don't already exist on the
web. It allows us to move forward and publish a simple spec, leaving
it to the DAP WG to tackle security policy in a more granular fashion.
I'd like us to agree tomorrow to put this in the Widgets: Access
Requests Policy (WARP â€” better name) document so we can push it to FPWD.
--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/