W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

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

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 4 Sep 2009 17:30:09 +0200
Message-ID: <b21a10670909040830i291dd23ha50adb9990642001@mail.gmail.com>
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>
On Tue, May 26, 2009 at 5:38 PM, Jean-Claude
Dufourd<jean-claude.dufourd@telecom-paristech.fr> wrote:
> Marcos, Mark, all,
> I am picking up the discussion where Cyril left it some months ago. I have
> read this thread, the Oct 08 one, the proposed URI scheme spec, even skimmed
> through the wam minutes. I still am leaning towards Mark's position. It
> seems to me that the URI scheme is not needed, or if needed, the reasons
> have not yet been "shown".
> I am trying to reformulate the situation:
> 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.
> 2- the browser will have to resolve the relative URI to an absolute URI
> because of the DOM spec, 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.
> 3- Marcos seems to be deducing from 2- that a URI scheme must be defined for
> mandatory internal use in all widget UAs to guarantee that this
> vulnerability does not exist.
> 3- does not follow logically from 2-.
> "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.
> 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.
> My past standardization experience is that things which "will never be used
> by the author and will never be exchanged between two implementations"
> should not be standardized at all. Are there other predicates for the need
> for standardisation ?

No. Just to stop implementers from using file://. I guess then it
doesn't matter. All the URI scheme should be is an informative note
that implementers should be allowed to use if they want. Implementers
should be able to use whatever scheme they want so long as the end
result is indistinguishable from what would be obtained from using the
widget URI  scheme.

> Marcos mentions the widget V2 spec and extensibility as one reason for
> adopting the proposed URI scheme. I would like to understand how V2 and
> extensibility could make the URI scheme either seen by the author or
> exchanged between implementations, or make its absence otherwise imperil
> implementations.

Personally, I wish implementations would use http as a scheme AND as a
protocol. That is, the widget user agent behave as a web server when
serving any/all content to itself.

Marcos Caceres
Received on Friday, 4 September 2009 15:31:09 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC