- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 2 Sep 2009 16:46:33 +0200
- To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
- Cc: public-webapps <public-webapps@w3.org>, public-pkg-uri-scheme <public-pkg-uri-scheme@w3.org>
Jean-Claude, On May 26, 2009, at 17:38 , Jean-Claude Dufourd wrote: > 0- the author needs a way to point to resources within the widget > package Correct. > 1- the "URI scheme will never be used by the author" (written by > Marcos), the author will use relative URIs for resources within the > widget. Partly correct. Authors can use it in content (for consistency), they are merely discouraged from doing so. However when identifying a document through the DOM (or any other way that deals in absolute URI references) then it will naturally be used. > 2- the browser will have to resolve the relative URI to an absolute > URI because of the DOM spec Not "because of the DOM spec". It so happens that the DOM exposes the absolute URI — which is the smart thing to do and not an aspect of the DOM that is contested by anyone. Even without the DOM the implementation would likely deal in absolute URI references — however the fact that interests us here is that users have access to that information, that there are valid use cases for scripting against it, and therefore that it must be predictable. > , hence a possible vulnerability by divulging private information > (e.g. actual name of current user in file: URI example of Apple > Dashboard widgets) to scripts running in the widget. That is just one of the many arguments that have been made against reusing existing schemes. Other schemes always involve hacks to work around their semantics or the minting of special names within them (typically for their authority, but possibly for their first steps as well if we consider mounts on localhost). Creating a new scheme avoids reuse-by-brutal-shoehorn. > "Mandating the implementation in the widget UA of a URI resolution > that does not divulge private information to the widget scripts" is > sufficient to ensure that the vulnerability mentioned in 2- does not > happen. The proposed URI scheme could be suggested as an option, but > not more. How do you define "private information"? How does that translate into an actual URI that can be compared character by character in different implementations? It's not clear enough to be a mandate (since it's not clear what implementers must do), and even if it were it seems unlikely to solve the issue. Furthermore, "suggesting the proposed URI as an option" seems to introduce yet more optionality which would further hurt interoperability. > My understanding is that 3- mandates a particular URI scheme which > will never be used by the author and will never be exchanged between > two implementations. That is incorrect. The URI can and will be used in script. -- Robin Berjon - http://berjon.com/
Received on Wednesday, 2 September 2009 14:47:09 UTC