On Tue, May 19, 2009 at 12:46 PM, Arve Bersvendsen <[email protected]> wrote: > On Tue, 19 May 2009 11:18:36 +0200, Marcos Caceres <[email protected]> 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
