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.
> 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
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.
--
Arve Bersvendsen
Opera Software ASA, http://www.opera.com/