- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 3 Jun 2009 16:40:02 +0100
- To: public-webapps WG <public-webapps@w3.org>
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