RE: [WARP] Comments to WARP spec

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.

If the proposed solution is inadequate, I welcome other suggestions. 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.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Marcos Caceres [mailto:marcosc@opera.com] 
Sent: Tuesday, November 10, 2009 1:36 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec



SULLIVAN, BRYAN L (ATTCINW) wrote:
> Marcos,
>
> Re "I'm personally not in favor of trying to deviate too much from the Web security model.": I agree with you, and that is the point of the comments. The "web security model" (I think you mean the same-origin restriction) does not restrict access to image content from anywhere, like the<access>  element would. The<access>  element as currently in the WARP spec goes beyond the "web security model".
>
> My point is that the statement below in the WARP spec needs to change, because this is not compatible with the "web security model", and also "makes more work for implementers" because the security model for widget-context webapps would not be the same as for browser-context webapps: "In the default policy, a user agent must deny access to network resources  external to the widget by default, whether this access is requested through APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img)."
>
> So either:
> (1) we need to be specific about which API's / resource types are affected by inclusion (or exclusion) of domains in<access>  (and keep this equivalent to HTML5)
> (2) we must add a way for the developer to indicate which types of references should be allowed for the domain
>
> My preference would be (1), but I proposed the use of "tag=" to illustrate how (2) might work.
>

Again, @tag= assumes HTML. There could be many different variant start 
files in a widget. Consider the case where you have a compound XML 
document as the start file (HTML + SVG + Custom XML)... how would you 
say which element this applies to and in which namespace? Also "tag" 
makes no sense in the context of CSS, XHR, etc.

Received on Tuesday, 10 November 2009 15:10:03 UTC