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:[email protected]] 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.
