Marcos, Re "the whole point of WARP is to put these boundaries around the behavior of widgets because they run locally.", there is really no difference between browser-context and widget-context webapps in that sense. Both run on the device, and both can access device resources and network resources. The only essential difference is that widgets are downloaded and installed as a package which can define some extra information that is useful in the install phase of the application lifecycle (e.g. compatibility checks via the the <feature> and <access> elements).
I don’t believe it is correct to say that "How a browsing context should behave when run locally is not really defined by HTML5.". I believe that regardless of where a web page originates, the security model must be consistent. For the part of HTML5 (e.g. access to DOM elements) that depends upon same-origin restrictions, the source of the stored content is important (and should anyway be known by the browser in most cases), but for the other parts (e.g. img tag and referenced scripts) it is irrelevant. Placing broad restrictions on widget-context webapp access to network resources (substantially different from browser-context webapps) is not an effective approach to creating a useful widget-context webapp platform. That would create a significant barrier to market acceptance of the W3C widget standards. Best regards, Bryan Sullivan | AT&T -----Original Message----- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Tuesday, November 10, 2009 7:30 AM To: SULLIVAN, BRYAN L (ATTCINW) Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec SULLIVAN, BRYAN L (ATTCINW) wrote: > Marcos, > I agree there is an assumption behind the approach I proposed, which I also > believe will be valid for the vast majority of widgets which will actually > have "index.html" or something like that as the start page. Further, the > statements in the config.xml apply to all resources in the widget, not just > the start page, i.e. I can start with a non-HTML which references an HTML > file in the package, to which the "tag" attribute applies. So we are clear, the tag attribute does not work in the following situation. I want to disable x:script, but allow v:script... unless you know what the things different namespaces will not be added dynamically to the DOM: <x:html xmlns:x="http://www.w3.org/1999/xhtml";> ... <x:script> ... </x:script> <v:svg v:width="6cm" v:height="5cm" v:viewBox="0 0 600 500" xmlns:v="http://www.w3.org/2000/svg"; version="1.1"> <v:script src="...">...</v:script> </v:svg> </x:html> > If the proposed solution is inadequate, I welcome other suggestions. I don't have a suggestion because I don't believe this part of WARP is broken or is necessary. >But as it stands, the WARP spec is not consistent with the web security model, so we need to fix the<access> element definition somehow. Well, the whole point of WARP is to put these boundaries around the behavior of widgets because they run locally. How a browsing context should behave when run locally is not really defined by HTML5. This leaves a gap for us to fill.
