- From: Thomas Roessler <tlr@w3.org>
- Date: Thu, 26 Feb 2009 18:34:52 +0100
- To: Marcos Caceres <m.caceres@qut.edu.au>
- Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>
- Message-Id: <9DD110C1-D860-40C9-B688-2E08F4D86D20@w3.org>
Marcos, R37 currently reads: > A conforming specification MUST recommend that, at runtime, the > addressing scheme used by a resource that addresses another resource > within a widget package be resolved to some hierarchical URI scheme > for the purpose of DOM normalization. A conforming specification > SHOULD recommend or specify an appropriate URI scheme: That is, a > URI scheme that does not expose the underlying file system (if any) > to the instantiated widget. In addition, an instantiated widget MUST > NOT be able to address resources outside the widget resource via the > URI scheme (even if URI scheme allows it).The URI scheme MUST > pertain to individual widget instances, but it MAY potentially allow > widgets to address each other (for instance, when used in > conjunction with cross-widget communication). http://dev.w3.org/2006/waf/widgets-reqs/#r37.-resolve-addressing-scheme-to-uri-scheme I don't think that this requirement should be phrased in terms of URI *schemes* at all. Additionally, the "MUST NOT be able to address resources outside the widget resource" part of the requirement isn't clear -- why is that needed? (Sounds like a bit of security policy crept in here.) Finally, while I agree that you don't want a widget to jailbreak, that's part of an overall security policy; it shouldn't be normatively mixed into the resource identification requirement. Instead, the requirement should be that there ought to be a security policy with these effects. Therefore, my version of R37 would be: > A conforming specification MUST define a mechanism to set the base > URI for any DOM instances that occur within the Widget, and it MUST > define a mechanism that enables the construction of URI references > between different resources within a widget package. Regards, -- Thomas Roessler, W3C <tlr@w3.org>
Received on Thursday, 26 February 2009 17:35:03 UTC