W3C home > Mailing lists > Public > public-pkg-uri-scheme@w3.org > September 2009

Re: [widgets] Widgets URI scheme... it's baaaack!

From: Robin Berjon <robin@berjon.com>
Date: Wed, 2 Sep 2009 16:46:33 +0200
Cc: public-webapps <public-webapps@w3.org>, public-pkg-uri-scheme <public-pkg-uri-scheme@w3.org>
Message-Id: <EA6915BD-4161-4145-8A55-BF16C3BF0DCB@berjon.com>
To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>

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


> 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  

> "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:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:38:12 UTC