Re: [widget] Security model

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.
>

right.

>> 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.
>

Ok.

-- 
Marcos Caceres
http://datadriven.com.au

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