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.
