Attempt at consensus on the <access> model

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/

Received on Wednesday, 3 June 2009 15:40:36 UTC