W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widget] Security model

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 19 May 2009 13:40:13 +0200
Message-ID: <b21a10670905190440q795639f8nf7f0abb09f3f7fd7@mail.gmail.com>
To: Arve Bersvendsen <arveb@opera.com>
Cc: public-webapps <public-webapps@w3.org>
On Tue, May 19, 2009 at 12:46 PM, Arve Bersvendsen <arveb@opera.com> wrote:
> On Tue, 19 May 2009 11:18:36 +0200, Marcos Caceres <marcosc@opera.com> wrote:
>> With my "editor" hat on, I would like to propose the following
>> security model for widgets:
>> 1. If no <access> element is used, the application type (e.g., HTML,
>> Flash, whatever) is responsible for providing the security
>> context/rules under which the widget runs. For HTML this means that a
>> widget runs as if you had dragged a HTML file from your hard-drive
>> into the Web browser.
> It's at this stage I should point out that "dragged a HTML file from your hard-drive in to the web browser" has no really consistent security model.
> * Some browsers will restrict XHR (and similar interfaces) to only work for valid subtrees of the top-level document.
> * Some browsers will also enforce the previous rule for inlines
> * Some browsers will allow cross-protocol loading of inline resources
> * Some browsers will restrict this
> * Other browsers, where the scripting hooks go fairly infinitely deep into the operating system (Hi, MSIE), will disable scripting and active content entirely.
> It should also be pointed out that there are requirements floating about that basically say "No network access, unless expressly requested by the widgets"
>> This defers the security problem to HTML5 or whoever wants to make use
>> of widgets as a packaging format.  HTML5 already has to deal with
>> situation where HTML files are run locally or with a synthetic origin
>> (think email attachments).
> This is a cop-out that *will* result in incompatible implementations of widgets, because a security model (including the network access bits of it) is sorely needed.

Yes. But we should at least evaluate what, if anything, is done with
this respect in HTML5. If it turns out that the HTML-WG has done
nothing about this, then sure. So,

1. we ask HTML-WG to fix it. A HTML5 insider tells me that HTML5 does
handle our use case because widgets are  "not part of the Web"...so...
2. we have to define our own :(

>> 2. If <access> is used, then this is an "op-in" to a "widget security
>> model" and all network activity is blocked by all means (like a
>> firewall), except those access requests made via <access> element that
>> have been granted by the UA. Access requests are granted via the UA
>> security policy, which is outside the scope of the Widgets spec.
> This would result in widgets that have no use for network access getting access, which may or may not be acceptable on mobile devices.
> My proposal is roughly:
> 1. Adopt Opera's prior proposal as a starting model, work out the kinks, and leave this as the default model
In light of 1, above. This might be our only option.

> 2. Opt-in for "external-origin" widgets, which follow the W3C security model.  Widgets claiming to use this model, can also easily be embedded on the web, and would work as a "stamp of inline-widget" approval.


>> I personally think <access> should be removed from Widgets 1.0 and
>> deferred to Widgets 2.0 once it is properly sorted out.
> In my opinion: absolutely not, even if it implies delaying Widgets.


Marcos Caceres
Received on Tuesday, 19 May 2009 11:41:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC