RE: [WARP] Comments to WARP spec

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:marcosc@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.

Received on Tuesday, 10 November 2009 16:16:31 UTC