- From: Marcos Caceres <marcosc@opera.com>
- Date: Tue, 19 May 2009 13:40:13 +0200
- 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. > 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