Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, Sep 15, 2009 at 7:26 AM, Robin Berjon ro...@berjon.com wrote: The regex could just as easily have been written to exclude the authority component of the URI. Do you have a better example? It could have, but it wasn't — interoperability isn't what happens when people write to a W3C working group to get their code debugged, it's what happens when real people write code on their own. Sure, some people will write really bad code. I just don't think we have to accommodate all of them. Of course, but the above piece of code isn't bad at all. It gets the job done, and it's not more generic than one has reason to expect it to be, especially with web development background. What we're accommodating are expectations of interoperability and least surprise — in my book that hardly qualifies as catering to really bad code. Am I missing something? The code will only work on implementations which use http URIs and with a local domain. How many of them do that? If not all, then that is bad code. Let us assume that we don't at all say what is returned by the many attributes that normally expose URIs. What regex would you just as easily have written to match an unspecified value? Here are some samples from several implementations given an image linked to as /img/dahüt.svg: A: http://magic.local/img/dahüt.svg B: file://mushroom.local/img/dahüt.svg C: file:///img/dahüt.svg D: file:///C|/img/dahüt.svg E: \\myphone\img\dahüt.svg F: C:\MY DOCUMENTS AND SETTING\MY USERS\MY MARKB\MY DOCUMENTS\MY WIDGETS\MY ARSE\DAH~1.VML G: http:///img/dah%FCt.svg H: cool-product:/img/dah%u0055%u0308t.svg I: inode:DEADBABEC0EDBEEF J: many more things... Some of those aren't URIs, and some aren't hierarchical. Of the others, [:/]//?*/(.*$) should cover it. Sure, but in the absence of any indication from the specification, why should implementers use a URI there? In fact, one could make the case that it makes better sense to pick something that cannot I guess I missed your qualification; Let us assume that we don't at all say what is returned by the many attributes that normally expose URIs. I don't understand why you'd want to do that. I thought we just finished agreeing that we need to identify things with URIs. I'll note in passing that your regex doesn't take into account cases that might expose the query string in some implementations and not in others. Would you consider it to be really bad code? Certainly one could construct a more robust regex than yours, but it's a lot better to provide the means for implementations to be interoperable from the start rather than having to document which hacks work everywhere. [..] But if it would simplify things, I wouldn't be averse to a getBaseURI() call. I'm not sure what exactly that would cover, and how it would help. It would permit a developer to easily turn a URI into a relative path. Let's imagine we say nothing and you're an implementer: what would you do? Everyone in this discussion understands that introducing new schemes should be done with caution — what I don't understand is what architectural value you are seeing in not using URIs to identify resources, encouraging non-interoperable solutions, or sweeping the issue under the rug by delegating to a special name instead of a scheme. I'm not doing any of those things AFAICT. I encourage resources to be identified by URIs. I just don't see a need to tell implementations what their URIs should look like, other than to say they should be hierarchical for obvious reasons. Should they include query strings? Should? No. But if there's a good reason to use them I don't see why it should be prohibited. Fragments? Ditto. Can they contain UTF8 characters? URIs can't contain non-ASCII UTF8 of course, but escaping issues are well understood (if inconsistently implemented). What are the security implications of reusing an existing scheme with a magic name (given that it could be highjacked)? The same implications there's always been. This is a case where saying less only bring more problems. If we were to go your suggested route of telling implementations everything about what the URIs should look like except what the scheme would be, what we'll end up specifying is a URI scheme without a scheme name You say that saying less can bring problems, and I agree that what I'm proposing is to say very little, but then you say I'm telling implementations everything about what the URIs should look like? I'm a bit confused about your complaint, as those sound contradictory to me. . Apart from scoring a perfect Montesquieu on the Mint New URI Schemes With A Trembling Hand, I'm not sure that it buys us much that simply providing implementers with information that they've been asking for doesn't. Well, there are good reasons to avoid new URI schemes as RFC 4395 describes. Minting a new one is *always* the most expedient thing to do - which is
Re: [widgets] Widgets URI scheme... it's baaaack!
On Sep 9, 2009, at 19:01 , Mark Baker wrote:
On Wed, Sep 9, 2009 at 10:17 AM, Robin Berjonro...@berjon.com wrote:
On Sep 8, 2009, at 17:18 , Mark Baker wrote:
function getSection () {
return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
$1).toLowerCase();
}
The regex could just as easily have been written to exclude the
authority component of the URI. Do you have a better example?
It could have, but it wasn't — interoperability isn't what happens
when
people write to a W3C working group to get their code debugged,
it's what
happens when real people write code on their own.
Sure, some people will write really bad code. I just don't think we
have to accommodate all of them.
Of course, but the above piece of code isn't bad at all. It gets the
job done, and it's not more generic than one has reason to expect it
to be, especially with web development background. What we're
accommodating are expectations of interoperability and least surprise
— in my book that hardly qualifies as catering to really bad code.
Let us assume that we don't at all say what is returned by the many
attributes that normally expose URIs. What regex would you just as
easily
have written to match an unspecified value? Here are some samples
from
several implementations given an image linked to as /img/dahüt.svg:
A: http://magic.local/img/dahüt.svg
B: file://mushroom.local/img/dahüt.svg
C: file:///img/dahüt.svg
D: file:///C|/img/dahüt.svg
E: \\myphone\img\dahüt.svg
F: C:\MY DOCUMENTS AND SETTING\MY USERS\MY MARKB\MY DOCUMENTS\MY
WIDGETS\MY
ARSE\DAH~1.VML
G: http:///img/dah%FCt.svg
H: cool-product:/img/dah%u0055%u0308t.svg
I: inode:DEADBABEC0EDBEEF
J: many more things...
Some of those aren't URIs, and some aren't hierarchical. Of the
others, [:/]//?*/(.*$) should cover it.
Sure, but in the absence of any indication from the specification, why
should implementers use a URI there? In fact, one could make the case
that it makes better sense to pick something that cannot
I'll note in passing that your regex doesn't take into account cases
that might expose the query string in some implementations and not in
others. Would you consider it to be really bad code? Certainly one
could construct a more robust regex than yours, but it's a lot better
to provide the means for implementations to be interoperable from the
start rather than having to document which hacks work everywhere.
But if it would simplify things, I wouldn't be averse to a
getBaseURI() call.
I'm not sure what exactly that would cover, and how it would help.
Let's imagine we say nothing and you're an implementer: what would
you do?
Everyone in this discussion understands that introducing new
schemes should
be done with caution — what I don't understand is what
architectural value
you are seeing in not using URIs to identify resources, encouraging
non-interoperable solutions, or sweeping the issue under the rug by
delegating to a special name instead of a scheme.
I'm not doing any of those things AFAICT. I encourage resources to be
identified by URIs. I just don't see a need to tell implementations
what their URIs should look like, other than to say they should be
hierarchical for obvious reasons.
Should they include query strings? Fragments? Can they contain UTF8
characters? What are the security implications of reusing an existing
scheme with a magic name (given that it could be highjacked)?
This is a case where saying less only bring more problems. If we were
to go your suggested route of telling implementations everything about
what the URIs should look like except what the scheme would be, what
we'll end up specifying is a URI scheme without a scheme name. Apart
from scoring a perfect Montesquieu on the Mint New URI Schemes With A
Trembling Hand, I'm not sure that it buys us much that simply
providing implementers with information that they've been asking for
doesn't.
The identifiers produced by implementations you list above suggests
that at least some implementors feel that they can reuse existing
schemes, no?
No, the list is provided as an example, not taken from actual
implementations. Implementers have been asking repeatedly for this URI
scheme to be defined, I think largely because they want to be
interoperable with one another. Push-back on this has come mostly from
the armchair end of the spectrum.
--
Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Sep 8, 2009, at 17:18 , Mark Baker wrote:
function getSection () {
return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
$1).toLowerCase();
}
I won't say that it's necessarily the best-written code, but it's
not daft
enough to be shrugged off and it's not particularly contrived. It's
easy to
come up with a bunch of similar cases. If you get one
implementation with
more market-share than the others, then they'll have to copy its
behaviour,
and we'll then have to specify it.
The regex could just as easily have been written to exclude the
authority component of the URI. Do you have a better example?
It could have, but it wasn't — interoperability isn't what happens
when people write to a W3C working group to get their code debugged,
it's what happens when real people write code on their own.
Let us assume that we don't at all say what is returned by the many
attributes that normally expose URIs. What regex would you just as
easily have written to match an unspecified value? Here are some
samples from several implementations given an image linked to as /img/
dahüt.svg:
A: http://magic.local/img/dahüt.svg
B: file://mushroom.local/img/dahüt.svg
C: file:///img/dahüt.svg
D: file:///C|/img/dahüt.svg
E: \\myphone\img\dahüt.svg
F: C:\MY DOCUMENTS AND SETTING\MY USERS\MY MARKB\MY DOCUMENTS\MY
WIDGETS\MY ARSE\DAH~1.VML
G: http:///img/dah%FCt.svg
H: cool-product:/img/dah%u0055%u0308t.svg
I: inode:DEADBABEC0EDBEEF
J: many more things...
Another situation is a security manager that applies different
policies based on scheme, authority, etc. URIs are useful — they can
identify and locate stuff.
Let's imagine we say nothing and you're an implementer: what would you
do? Everyone in this discussion understands that introducing new
schemes should be done with caution — what I don't understand is what
architectural value you are seeing in not using URIs to identify
resources, encouraging non-interoperable solutions, or sweeping the
issue under the rug by delegating to a special name instead of a scheme.
We have a semantics that match no existing scheme. We have a locator
behaviour that matches no existing scheme. Resources should be
identified by URIs. All we're doing is applying the Web architecture.
--
Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, Sep 9, 2009 at 10:17 AM, Robin Berjonro...@berjon.com wrote:
On Sep 8, 2009, at 17:18 , Mark Baker wrote:
function getSection () {
return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
$1).toLowerCase();
}
I won't say that it's necessarily the best-written code, but it's not
daft
enough to be shrugged off and it's not particularly contrived. It's easy
to
come up with a bunch of similar cases. If you get one implementation with
more market-share than the others, then they'll have to copy its
behaviour,
and we'll then have to specify it.
The regex could just as easily have been written to exclude the
authority component of the URI. Do you have a better example?
It could have, but it wasn't — interoperability isn't what happens when
people write to a W3C working group to get their code debugged, it's what
happens when real people write code on their own.
Sure, some people will write really bad code. I just don't think we
have to accommodate all of them.
Let us assume that we don't at all say what is returned by the many
attributes that normally expose URIs. What regex would you just as easily
have written to match an unspecified value? Here are some samples from
several implementations given an image linked to as /img/dahüt.svg:
A: http://magic.local/img/dahüt.svg
B: file://mushroom.local/img/dahüt.svg
C: file:///img/dahüt.svg
D: file:///C|/img/dahüt.svg
E: \\myphone\img\dahüt.svg
F: C:\MY DOCUMENTS AND SETTING\MY USERS\MY MARKB\MY DOCUMENTS\MY WIDGETS\MY
ARSE\DAH~1.VML
G: http:///img/dah%FCt.svg
H: cool-product:/img/dah%u0055%u0308t.svg
I: inode:DEADBABEC0EDBEEF
J: many more things...
Some of those aren't URIs, and some aren't hierarchical. Of the
others, [:/]//?*/(.*$) should cover it.
But if it would simplify things, I wouldn't be averse to a getBaseURI() call.
Another situation is a security manager that applies different policies
based on scheme, authority, etc. URIs are useful — they can identify and
locate stuff.
Let's imagine we say nothing and you're an implementer: what would you do?
Everyone in this discussion understands that introducing new schemes should
be done with caution — what I don't understand is what architectural value
you are seeing in not using URIs to identify resources, encouraging
non-interoperable solutions, or sweeping the issue under the rug by
delegating to a special name instead of a scheme.
I'm not doing any of those things AFAICT. I encourage resources to be
identified by URIs. I just don't see a need to tell implementations
what their URIs should look like, other than to say they should be
hierarchical for obvious reasons.
We have a semantics that match no existing scheme. We have a locator
behaviour that matches no existing scheme.
The identifiers produced by implementations you list above suggests
that at least some implementors feel that they can reuse existing
schemes, no?
Mark.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, Sep 8, 2009 at 1:21 AM, Mark Bakerdist...@acm.org wrote: I don't understand. In what scenario would a script be comparing URIs produced by different implementations? implementations tend to be stupid and parse things by hand. if you don't believe this, all you have to do is look at the html5 discussion about c:\fakepath
Re: [widgets] Widgets URI scheme... it's baaaack!
On Sep 8, 2009, at 00:21 , Mark Baker wrote:
On Wed, Sep 2, 2009 at 10:33 AM, Robin Berjonro...@berjon.com wrote:
On May 23, 2009, at 19:21 , Mark Baker wrote:
Right. That's the same point Arve made. I don't see a problem with
it. Sure, a widget will be able to discover an implementation
detail
of its widget container - the base URI - but it's still up to the
container to permit or deny access to other resources from that
widget
when asked to dereference it, whether the widget discovered the URI
via a mechanism such as the one you describe, or even if it simply
guessed it.
Calling it an implementation detail doesn't make it one. Say I have
a script
in which I need to identify resources that I'm currently using from
within
the widget. Since I don't want to have to care how the designers
linked them
in, I'll use their absolute URIs to compare them. If implementation A
returns http://magic-widget-host.local/dahut.svg;, and
implementation B
file:///special-widget-mount/dahut.svg, and C gives me made-up:/
dahut.svg
we don't exactly have interoperability.
I don't understand. In what scenario would a script be comparing URIs
produced by different implementations?
Know which section you're in to highlight a given button:
function getSection () {
return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
$1).toLowerCase();
}
I won't say that it's necessarily the best-written code, but it's not
daft enough to be shrugged off and it's not particularly contrived.
It's easy to come up with a bunch of similar cases. If you get one
implementation with more market-share than the others, then they'll
have to copy its behaviour, and we'll then have to specify it.
--
Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, Sep 8, 2009 at 7:41 AM, Robin Berjonro...@berjon.com wrote:
On Sep 8, 2009, at 00:21 , Mark Baker wrote:
On Wed, Sep 2, 2009 at 10:33 AM, Robin Berjonro...@berjon.com wrote:
On May 23, 2009, at 19:21 , Mark Baker wrote:
Right. That's the same point Arve made. I don't see a problem with
it. Sure, a widget will be able to discover an implementation detail
of its widget container - the base URI - but it's still up to the
container to permit or deny access to other resources from that widget
when asked to dereference it, whether the widget discovered the URI
via a mechanism such as the one you describe, or even if it simply
guessed it.
Calling it an implementation detail doesn't make it one. Say I have a
script
in which I need to identify resources that I'm currently using from
within
the widget. Since I don't want to have to care how the designers linked
them
in, I'll use their absolute URIs to compare them. If implementation A
returns http://magic-widget-host.local/dahut.svg;, and implementation B
file:///special-widget-mount/dahut.svg, and C gives me
made-up:/dahut.svg
we don't exactly have interoperability.
I don't understand. In what scenario would a script be comparing URIs
produced by different implementations?
Know which section you're in to highlight a given button:
function getSection () {
return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
$1).toLowerCase();
}
I won't say that it's necessarily the best-written code, but it's not daft
enough to be shrugged off and it's not particularly contrived. It's easy to
come up with a bunch of similar cases. If you get one implementation with
more market-share than the others, then they'll have to copy its behaviour,
and we'll then have to specify it.
The regex could just as easily have been written to exclude the
authority component of the URI. Do you have a better example?
Mark.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, Sep 2, 2009 at 10:33 AM, Robin Berjonro...@berjon.com wrote: On May 23, 2009, at 19:21 , Mark Baker wrote: Right. That's the same point Arve made. I don't see a problem with it. Sure, a widget will be able to discover an implementation detail of its widget container - the base URI - but it's still up to the container to permit or deny access to other resources from that widget when asked to dereference it, whether the widget discovered the URI via a mechanism such as the one you describe, or even if it simply guessed it. Calling it an implementation detail doesn't make it one. Say I have a script in which I need to identify resources that I'm currently using from within the widget. Since I don't want to have to care how the designers linked them in, I'll use their absolute URIs to compare them. If implementation A returns http://magic-widget-host.local/dahut.svg;, and implementation B file:///special-widget-mount/dahut.svg, and C gives me made-up:/dahut.svg we don't exactly have interoperability. I don't understand. In what scenario would a script be comparing URIs produced by different implementations? Mark.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, May 26, 2009 at 5:38 PM, Jean-Claude Dufourdjean-claude.dufo...@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 http://datadriven.com.au
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, Sep 2, 2009 at 4:33 PM, Robin Berjonro...@berjon.com wrote: On May 23, 2009, at 19:21 , Mark Baker wrote: Right. That's the same point Arve made. I don't see a problem with it. Sure, a widget will be able to discover an implementation detail of its widget container - the base URI - but it's still up to the container to permit or deny access to other resources from that widget when asked to dereference it, whether the widget discovered the URI via a mechanism such as the one you describe, or even if it simply guessed it. Calling it an implementation detail doesn't make it one. Say I have a script in which I need to identify resources that I'm currently using from within the widget. Since I don't want to have to care how the designers linked them in, I'll use their absolute URIs to compare them. If implementation A returns http://magic-widget-host.local/dahut.svg;, and implementation B file:///special-widget-mount/dahut.svg, and C gives me made-up:/dahut.svg we don't exactly have interoperability. And here is where the fun starts. How do we reconcile the above without a new scheme? This gets more interesting once you bring the localisation mechanism from P+C into play, whereby the Zip relative path and the relative URI are different when you have multilingual content. Exactly. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Widgets URI scheme... it's baaaack!
Hi Mark, On May 22, 2009, at 15:25 , Mark Baker wrote: I'm curious to learn where the requirement that Must not allow addressing resources outside a widget came from? Can you point to a precedent for such a restriction in any other protocol? I remember TimBL writing something to the effect of Anywhere you can use a URI, you can use any URI, possibly in his design issues, but I can't find a reference right now. The idea is that as currently defined, the URI scheme can only point to resources contained inside the widget. Wherever you use a widget: URI, you can also use other URI schemes such as http: or file: (i.e. there's no restriction on the content) but depending on your security settings it might not be retrieved and if executed it probably won't have access to the same APIs. The widget: URI comes with a guarantee that you're pointing inside the widget, which is a nice, clean, sandboxed world (which incidentally might also be signed). I also don't understand what that bit about run on the web means in the intro. Yeah, neither do I. I've tried to make the abstract clearer. Thanks! -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
Hi Larry, On May 22, 2009, at 17:29 , Larry Masinter wrote: If the widget: scheme is intended for inter-package references then there are security issues with that. If not, then why the UUID? Inter-widget communication is a use case that can be tackled later — this is left as an open door. The UUID has been dropped since indeed without that it is not needed. Thanks! -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On May 22, 2009, at 20:21 , Mark Baker wrote: Ah, right, I didn't realize it was related to a discussion Marcos and I had last year; http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/thread.html#msg50 I thought he had (somewhat grudgingly) accepted that way (the use of relative references) forward, as IIRC, the widget: scheme idea was dropped about that time. Has some new requirement emerged since then that makes relative references an undesirable option? Reading that thread I don't see a consensus emerging one way or another, and a lot of options appear to be considered that seem to be out of scope (or too close to the metal) for this specification. I see some arguments around using file: that could be used, but none seem to explain how it could be without entirely precluding other file: access (which could potentially be needed) or minting special names (e.g. a special file host), which strikes me as a bad idea. Would you care to outline what specifically you had in mind? -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On May 23, 2009, at 19:21 , Mark Baker wrote: Right. That's the same point Arve made. I don't see a problem with it. Sure, a widget will be able to discover an implementation detail of its widget container - the base URI - but it's still up to the container to permit or deny access to other resources from that widget when asked to dereference it, whether the widget discovered the URI via a mechanism such as the one you describe, or even if it simply guessed it. Calling it an implementation detail doesn't make it one. Say I have a script in which I need to identify resources that I'm currently using from within the widget. Since I don't want to have to care how the designers linked them in, I'll use their absolute URIs to compare them. If implementation A returns http://magic-widget-host.local/dahut.svg , and implementation B file:///special-widget-mount/dahut.svg, and C gives me made-up:/dahut.svg we don't exactly have interoperability. This gets more interesting once you bring the localisation mechanism from P+C into play, whereby the Zip relative path and the relative URI are different when you have multilingual content. -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, 02 Sep 2009 16:26:19 +0200, Robin Berjon ro...@berjon.com wrote: Reading that thread I don't see a consensus emerging one way or another, and a lot of options appear to be considered that seem to be out of scope (or too close to the metal) for this specification. I see some arguments around using file: that could be used, but none seem to explain how it could be without entirely precluding other file: access (which could potentially be needed) or minting special names (e.g. a special file host), which strikes me as a bad idea. In my opinion, the file: protocol needs to be avoided *at all costs*. User agents have, in over fifteen years of trying, not managed to agree on how to implement it interoperably, varying from how to encode drive and host names (on some operating systems) to how you deal with path traversal and content protection issues. Neither have they managed to agree on what origin means, or whether it is acceptable to accept active content in this context. We could spend man-years in trying to come up with something interoperable and be exactly where we were yesterday. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
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/
Re: [widgets] Widgets URI scheme... it's baaaack!
On May 27, 2009, at 10:15 , Jean-Claude Dufourd wrote: Arve Bersvendsen a écrit : The main issue here, I think, is one of being proactive on this front. Given that absolute URIs are required for resolution, and that UA vendors will, unless specified, have to pick a URI scheme of their own, the situation may well arise where they have specified something that would either be insecure (eg. file:), incompatible ( again, file:) or inappropriate (all schemes that fail to make query strings and fragment identifiers useful) JCD: I am unconfortable with such thinking that standards makers somehow know better than implementors (and I am a standard maker). As it happens, Arve is an implementer. This is a case where you would expose the problem in an informative part of the spec and propose (not mandate) a working solution to implementers. I don't see how that would work — how does an optional specification help interoperability. If it is not seen by the author But, as has been explained before, it is. -- Robin Berjon - http://berjon.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, 26 May 2009 17:38:48 +0200, Jean-Claude Dufourd jean-claude.dufo...@telecom-paristech.fr wrote: 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. ... 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. Thanks. The main issue here, I think, is one of being proactive on this front. Given that absolute URIs are required for resolution, and that UA vendors will, unless specified, have to pick a URI scheme of their own, the situation may well arise where they have specified something that would either be insecure (eg. file:), incompatible ( again, file:) or inappropriate (all schemes that fail to make query strings and fragment identifiers useful) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On 27 May 2009, at 09:34, Arve Bersvendsen wrote: The main issue here, I think, is one of being proactive on this front. Given that absolute URIs are required for resolution, and that UA vendors will, unless specified, have to pick a URI scheme of their own, the situation may well arise where they have specified something that would either be insecure (eg. file:), incompatible ( again, file:) or inappropriate (all schemes that fail to make query strings and fragment identifiers useful) Umh... 1. There is (again) no reason why the base URI that is chosen to absolutize relative URI references needs to be the same URI that is used to construct the origin. The argument that the URI scheme used to absolutize is somehow too insecure depends on a specific design decision that can go either way; in that context, I'm still waiting for your answer to this note: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0603.html See also Adam Barth's note here: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0608.html 2. Where does the requirement for query strings suddenly come from? I can't find it in the current editor's draft, and (beyond a side discussion with timeless) don't recall conversation about it.
Re: [widgets] Widgets URI scheme... it's baaaack!
Arve Bersvendsen a écrit : The main issue here, I think, is one of being proactive on this front. Given that absolute URIs are required for resolution, and that UA vendors will, unless specified, have to pick a URI scheme of their own, the situation may well arise where they have specified something that would either be insecure (eg. file:), incompatible ( again, file:) or inappropriate (all schemes that fail to make query strings and fragment identifiers useful) JCD: I am unconfortable with such thinking that standards makers somehow know better than implementors (and I am a standard maker). This is a case where you would expose the problem in an informative part of the spec and propose (not mandate) a working solution to implementers. If it is not seen by the author, and not useful for interoperability, there is no reason to mandate a solution. Otherwise, you force extra technology on vendors, and that is a recipe for failing standards. Best regards JC PS: I agree with Thomas, but my tack is different. -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, May 27, 2009 at 10:44 AM, Thomas Roessler t...@w3.org wrote: 2. Where does the requirement for query strings suddenly come from? I can't find it in the current editor's draft, and (beyond a side discussion with timeless) don't recall conversation about it. Basically web apps expect that window.location behave properly, if you use a scheme such as data: data:text/html,scriptalert(window.location.query%20?%20window.location.query%20:%20query is not supported)/script?%20Wouldn't%20it%20be%20nice? note that i can't do anything useful with this web app encoded as a data url because query is empty. Query based web apps are very common. Note: regrets for the next meeting, I'm traveling again.
Re: [widgets] Widgets URI scheme... it's baaaack!
On 27 May 2009, at 10:58, timeless wrote: On Wed, May 27, 2009 at 10:44 AM, Thomas Roessler t...@w3.org wrote: 2. Where does the requirement for query strings suddenly come from? I can't find it in the current editor's draft, and (beyond a side discussion with timeless) don't recall conversation about it. Basically web apps expect that window.location behave properly, if you use a scheme such as data: Just to be clear... The expectation you're talking about is that: 1. upon dereferencing, the query part is ignored 2. when present, it's propagated into window.location.query Correct? data:text/html,scriptalert(window.location.query%20? %20window.location.query%20:%20query is not supported)/script?%20Wouldn't%20it%20be%20nice? note that i can't do anything useful with this web app encoded as a data url because query is empty. Query based web apps are very common. Note: regrets for the next meeting, I'm traveling again.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, May 27, 2009 at 12:03 PM, Thomas Roessler t...@w3.org wrote: Just to be clear... The expectation you're talking about is that: 1. upon dereferencing, the query part is ignored I'm not specifically making this request, I believe in our unminuted discussion we talked about the potential to allow a script to handle mappings between URL and Resource. (Also note that HTML5 has at times talked about this sort of thing for Offline Apps.) In such a system, 1 wouldn't apply. However, yes, ignoring such a feature (or similar), the query part should be ignored. 2. when present, it's propagated into window.location.query Correct? it isn't just query that wants behavior, it's more the way that query is supposed to be filled (and certainly is for gecko) is that the object be a URL as opposed to simply a URI. http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIURL.idl http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIURI.idl http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsStandardURL.cpp http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSimpleURI.cpp http://www.ietf.org/rfc/rfc2396.txt The URI syntax is dependent upon the scheme. In general, absolute URI are written as follows: scheme:scheme-specific-part ^ Simple (data:, telnet:,) v Generic (http:, hypothetical widget:) This generic URI syntax consists of a sequence of four main components: scheme://authoritypath?query From an implementation perspective, a hypothetical widget: needs to fall into nsStandardURL instead of nsSimpleURI, path must behave, query must behave, fragment should behave. In general host and other fields should also behave, as having them throw exceptions just to break applications doesn't seem helpful. To everyone else who wasn't involved in my discussion w/ tlr, I'm sorry, but the above is I believe one of the many items we discussed.
Re: [widgets] Widgets URI scheme... it's baaaack!
Ouch. :) I'll start by disputing this requirement: Must provide an origin URI for widget-contained documents Many mechanisms in widgets (e.g. cookies, local storage, XMLHttpRequest) key off the URI or part thereof from which they are used. Since widgets are for all intents and purposes local applications that do not have an origin, this scheme must provide integration with these mechanisms. Some specification must provide that origin URI. But can somebody give a use case for this being a requirement on the widget URI scheme spec? (Specifically, why do origin and base URI need to match within widgets? Section 4.4 seems to indicate that URIs with scheme widget don't ever leave the specific widget instance. So, why?) Thanks, -- Thomas Roessler, W3C t...@w3.org On 22 May 2009, at 10:24, Marcos Caceres wrote: Just a heads up that the widget URI scheme is back (with a vengence) in its own spec: http://dev.w3.org/2006/waf/widgets-uri/Overview.html Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Widgets URI scheme... it's baaaack!
On Sat, 23 May 2009 06:33:21 +0200, Mark Baker dist...@acm.org wrote: On Fri, May 22, 2009 at 5:36 PM, Anne van Kesteren ann...@opera.com wrote: a.href is always an absolute URL on getting. Making it something else would be a bad hack and counter to how it has been designed. You mean the href attribute as used in the config file? I'm only talking about @src there AFAICT, as well as other linking mechanisms inside the widget content, e.g. html:href in HTML. That said, it does seem a bit odd to have an attribute called href that doesn't mean the same as html:href. But I don't wish to dig into that here and now; it's not a big deal. I just meant an HTML file in use within the widget. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Sat, May 23, 2009 at 6:40 AM, Anne van Kesteren ann...@opera.com wrote: On Sat, 23 May 2009 06:33:21 +0200, Mark Baker dist...@acm.org wrote: On Fri, May 22, 2009 at 5:36 PM, Anne van Kesteren ann...@opera.com wrote: a.href is always an absolute URL on getting. Making it something else would be a bad hack and counter to how it has been designed. You mean the href attribute as used in the config file? I'm only talking about @src there AFAICT, as well as other linking mechanisms inside the widget content, e.g. html:href in HTML. That said, it does seem a bit odd to have an attribute called href that doesn't mean the same as html:href. But I don't wish to dig into that here and now; it's not a big deal. I just meant an HTML file in use within the widget. It's perfectly good HTML to use a relative reference inside an href, as I'm sure you know. Are you suggesting that widgets have a more restrictive processing model for HTML? I can't find any reference to such a model in the spec. Mark.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Sat, May 23, 2009 at 10:32 AM, Anne van Kesteren ann...@opera.com wrote: On Sat, 23 May 2009 15:54:17 +0200, Mark Baker dist...@acm.org wrote: It's perfectly good HTML to use a relative reference inside an href, as I'm sure you know. Are you suggesting that widgets have a more restrictive processing model for HTML? I can't find any reference to such a model in the spec. I think we're talking past each other. I'm talking about the DOM. The href _DOM_ attribute of a always returns an absolute URL on getting. (I.e. the href member of the HTMLAnchorElement interface.) Right. That's the same point Arve made. I don't see a problem with it. Sure, a widget will be able to discover an implementation detail of its widget container - the base URI - but it's still up to the container to permit or deny access to other resources from that widget when asked to dereference it, whether the widget discovered the URI via a mechanism such as the one you describe, or even if it simply guessed it. Mark.
[widgets] Widgets URI scheme... it's baaaack!
Just a heads up that the widget URI scheme is back (with a vengence) in its own spec: http://dev.w3.org/2006/waf/widgets-uri/Overview.html Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Widgets URI scheme... it's baaaack!
Marcos, I'm curious to learn where the requirement that Must not allow addressing resources outside a widget came from? Can you point to a precedent for such a restriction in any other protocol? I remember TimBL writing something to the effect of Anywhere you can use a URI, you can use any URI, possibly in his design issues, but I can't find a reference right now. I also don't understand what that bit about run on the web means in the intro. Thanks. Mark.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, 22 May 2009 15:25:40 +0200, Mark Baker dist...@acm.org wrote: I'm curious to learn where the requirement that Must not allow addressing resources outside a widget came from? Can you point to a precedent for such a restriction in any other protocol? I remember TimBL writing something to the effect of Anywhere you can use a URI, you can use any URI, possibly in his design issues, but I can't find a reference right now. The point here is that the widget URI scheme is only supposed to be used to synthesise an origin so nodes in the DOM can be sensibly resolved for resources inside the package. The reason for choosing a synthetic scheme are: 1. A web (http(s?)) origin will not work, because a widget MAY be distributed over other channels than the web (such as bluetooth, pre-bundled on devices, installed through third-party package managment systems (debian packages/repositories)). 2. Further, (some) widgets might not provide an authorative means of determining the web origin of the widget, if any such origin existed in the first place. 3. A well-behaved widget runtime should provide complete isolation from the underlying operating system, including the layout of the file system 4. It must not be possible for a widget to resolve and reference resources in other widget packages on the same system (The underlying assumption here is that it should not be possible for a widget running on a user agent to determine which other widgets are running or installed on the same system. Points 1/2 pretty much invalidate http as a valid origin, while 3/4 invalidates the use of file: (which also has an entirely different set of compatibility issues between web ua's that I doubt will be resolved anytime soon.) -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
RE: [widgets] Widgets URI scheme... it's baaaack!
I didn't think widget had ever gone away. The document you pointed at says: This document is not a specification as of this time, though it is likely to become one once consensus has been reached on its fundamental direction. In the meantime, this document must be considered to sit outside the Widgets 1.0 family of specifications and to contain no normative content. I'm not sure what the vengeance is. It seems pretty clear that there must be some requirement that keeps the group from being comfortable about reusing or extending some existing URI scheme, such as using thismessage (RFC2557 defines for multipart/related but could be reused), file (consider the widget as a little mounted file system), cid (to pick up the UUID but add a path component. The requirements for new URI schemes for permanent registration are given in RFC 4395, and the ones I'd be concerned about here are: * the scheme is well-defined. In particular, terms in the definition are either part of common usage or are defined in the document or in referenced document. * there are requirements that require a new scheme rather than reusing an existing one. * Security considerations are explicit. If the widget: scheme is intended for inter-package references then there are security issues with that. If not, then why the UUID? Larry -- http://larry.masinter.net
RE: [widgets] Widgets URI scheme... it's baaaack!
What makes a set of widgets related? Is there an attack where based on UUID knowledge where two unrelated widgets could somehow appear related? What existing infrastructure for security are you planning to reuse? Often, security loopholes are introduced when reusing security infrastructure designed for one context in a way that it wasn't designed for. thismessage:/ basically didn't allow references outside the package at all. By adding a UUID and alluding to related packages as possibly being available, widget might become a vector. I'm not saying it is, I'm just saying that getting external review for security mechanisms and assumptions is critical. Larry -- http://larry.masinter.net -Original Message- From: Arve Bersvendsen [mailto:ar...@opera.com] Sent: Friday, May 22, 2009 9:55 AM To: Larry Masinter; marc...@opera.com; public-pkg-uri-scheme; public-webapps Subject: Re: [widgets] Widgets URI scheme... it's bck! On Fri, 22 May 2009 17:29:57 +0200, Larry Masinter masin...@adobe.com wrote: If the widget: scheme is intended for inter-package references then there are security issues with that. If not, then why the UUID? At the time of writing, I do not see them being used for inter-package references (If my understanding equals yours here, as in references between otherwise unrelated widgets. The UUID? Well, it actually eases implementations a bit, since an implementation can use the UUID as domain when requests are made, which actually allows vendors to reuse existing infrastructure for security checks and so on. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, May 22, 2009 at 9:41 AM, Arve Bersvendsen ar...@opera.com wrote: On Fri, 22 May 2009 15:25:40 +0200, Mark Baker dist...@acm.org wrote: I'm curious to learn where the requirement that Must not allow addressing resources outside a widget came from? Can you point to a precedent for such a restriction in any other protocol? I remember TimBL writing something to the effect of Anywhere you can use a URI, you can use any URI, possibly in his design issues, but I can't find a reference right now. The point here is that the widget URI scheme is only supposed to be used to synthesise an origin so nodes in the DOM can be sensibly resolved for resources inside the package. Ah, right, I didn't realize it was related to a discussion Marcos and I had last year; http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/thread.html#msg50 I thought he had (somewhat grudgingly) accepted that way (the use of relative references) forward, as IIRC, the widget: scheme idea was dropped about that time. Has some new requirement emerged since then that makes relative references an undesirable option? Mark.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, 22 May 2009 19:13:35 +0200, Larry Masinter masin...@adobe.com wrote: What makes a set of widgets related? Is there an attack where based on UUID knowledge where two unrelated widgets could somehow appear related? What existing infrastructure for security are you planning to reuse? Not having to rewrite from the bottom up how XMLHttpRequest works, and is checked in most user agents, as an example (It goes for a lot of other code in DOM). Often, security loopholes are introduced when reusing security infrastructure designed for one context in a way that it wasn't designed for. thismessage:/ basically didn't allow references outside the package at all. By adding a UUID and alluding to related packages as possibly being available, widget might become a vector. I'm not saying it is, I'm just saying that getting external review for security mechanisms and assumptions is critical. Larry -- http://larry.masinter.net -Original Message- From: Arve Bersvendsen [mailto:ar...@opera.com] Sent: Friday, May 22, 2009 9:55 AM To: Larry Masinter; marc...@opera.com; public-pkg-uri-scheme; public-webapps Subject: Re: [widgets] Widgets URI scheme... it's bck! On Fri, 22 May 2009 17:29:57 +0200, Larry Masinter masin...@adobe.com wrote: If the widget: scheme is intended for inter-package references then there are security issues with that. If not, then why the UUID? At the time of writing, I do not see them being used for inter-package references (If my understanding equals yours here, as in references between otherwise unrelated widgets. The UUID? Well, it actually eases implementations a bit, since an implementation can use the UUID as domain when requests are made, which actually allows vendors to reuse existing infrastructure for security checks and so on. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
Arve - Getting the value of 'src' here using 'document.images[0].getAttribute(src)' should return the relative path. The Microsoft guys made a big deal out of the fact that IE8 (in IE8 'strict standards' mode) will now properly return the relative path when 'getAttribute()' is used, but the full path (as you state), when the 'property access' version of the call is used. In IE 8, some extra JS to determine base path and then relativize the value would be necessary in those browsers. Cheers, - Bill On May 22, 2009, at 2:22 PM, Arve Bersvendsen wrote: On Fri, 22 May 2009 20:21:56 +0200, Mark Baker dist...@acm.org wrote: I thought he had (somewhat grudgingly) accepted that way (the use of relative references) forward, as IIRC, the widget: scheme idea was dropped about that time. Has some new requirement emerged since then that makes relative references an undesirable option? The problem here is that no user agent implementation I am aware of uses 'relative' URIs when resolving nodes. If you provide img src=foo/bar/baz.png / - they all compose an absolute URI from the string representing the relative URI, and expose that when you query for the attribute value, so putting my markup fragment into a document at the root of http://example.com/: html img src=foo/bar/baz.png / script // The following Outputs http://example.com/foo/bar/baz.png alert(document.images[0].src); /script -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, May 22, 2009 at 3:22 PM, Arve Bersvendsen ar...@opera.com wrote: On Fri, 22 May 2009 20:21:56 +0200, Mark Baker dist...@acm.org wrote: I thought he had (somewhat grudgingly) accepted that way (the use of relative references) forward, as IIRC, the widget: scheme idea was dropped about that time. Has some new requirement emerged since then that makes relative references an undesirable option? The problem here is that no user agent implementation I am aware of uses 'relative' URIs when resolving nodes. If you provide img src=foo/bar/baz.png / - they all compose an absolute URI from the string representing the relative URI, and expose that when you query for the attribute value, so putting my markup fragment into a document at the root of http://example.com/: html img src=foo/bar/baz.png / script // The following Outputs http://example.com/foo/bar/baz.png alert(document.images[0].src); /script Sure. Why is that a problem? Mark.
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, 22 May 2009 20:21:56 +0200, Mark Baker dist...@acm.org wrote: Ah, right, I didn't realize it was related to a discussion Marcos and I had last year; http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/thread.html#msg50 I thought he had (somewhat grudgingly) accepted that way (the use of relative references) forward, as IIRC, the widget: scheme idea was dropped about that time. Has some new requirement emerged since then that makes relative references an undesirable option? a.href is always an absolute URL on getting. Making it something else would be a bad hack and counter to how it has been designed. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] Widgets URI scheme... it's baaaack!
On Fri, May 22, 2009 at 5:36 PM, Anne van Kesteren ann...@opera.com wrote: a.href is always an absolute URL on getting. Making it something else would be a bad hack and counter to how it has been designed. You mean the href attribute as used in the config file? I'm only talking about @src there AFAICT, as well as other linking mechanisms inside the widget content, e.g. html:href in HTML. That said, it does seem a bit odd to have an attribute called href that doesn't mean the same as html:href. But I don't wish to dig into that here and now; it's not a big deal. Mark.
