Follow-up on widgets scheme discussion with TAG members [Was: Re: [Widgets] URI Scheme revisited.... again]
Marcos, All, I agree the main follow-up is that we need to do some additional work, particularly regarding fleshing out related requirements. The minutes indicate there are some requirements that aren't explicitly captured in the October 20 version of R6: http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing Perhaps some of these should be more explicit: [[ http://www.w3.org/2008/10/20-wam-minutes.html#item12 Marcos: We don't want the URI scheme to have the ability to reference things outside the resource Marcos: the real use case for this is resolving the DOM nodes. For example, images, iframes, they all need to resolve to something. Arve: it [widget: scheme] is only a convenience for resolving resources Josh: For these things, the general expectation is that the names are local. They're just so that widget can introspect itself. Josh: It shouldn't be able to be remotely readable. It's a privacy violation if you can see what else is running. DanC: did the requirements list the security policy, e.g. same origin, details? Arve: it also establishes a security model for accessing things as the browser can reuse the cross domain security module. We're using an identifier because it's an incredibly convenient way to establish a same origin policy. ]] Also, some related suggestions and questions were raised: * Transparency: Can the scheme be modeled such that it is an implementation detail (i.e. names are private to the UA) and thus never [publicly] exposed? What are the consequences if the scheme leaks? If the scheme will be public, is there a need for a registry? * Update scenarios: How would the widget scheme fit into various update scenarios? * Extensibility: What, if any, extensibility mechanism is required for the widget scheme? What are the related use cases? -Regards, Art Barstow On Oct 24, 2008, at 6:51 AM, ext Marcos Caceres wrote: Hi Mark, Please see [1] for TAG discussion about WebApps proposal of widget URI scheme. From what I got from the discussion, the TAG seems to agree that we likely do need our own URI scheme. We just need to flesh out our technical argument a little more. We are also going to try to coordinate with the Open Document Format people as they also need something very similar. I again ask for your help in defining the scheme correctly, rather than arguing against it. [1] http://www.w3.org/2008/10/20-wam-minutes.html#item11 Kind regards, Marcos On Mon, Oct 13, 2008 at 4:59 PM, Mark Baker [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 10:31 AM, Marcos Caceres [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 5:08 AM, Mark Baker [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 4:00 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok, In one of my previous emails I said that this was a potential privacy/security issue: The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). I'm no security/privacy expert, but this seems like an easy way to at least get someone's username (from which I may be able to derive who they are, etc). Also, if the implementation is crap and does not restrict file:// to the scope of the widget package (thankfully Apple does), then widgets could basically read any files on the hard drive. Sure, but standardizing on a URI scheme won't fix this, because one can guess URIs in any scheme. Less opaque schemes like hierarchical ones are a little more susceptible of course, but it's a problem for all schemes. In the case of widgets, it's not a problem at all for the structure of the package to be guessed (as anyone can just decompress the widget locally anyway and take a look at it's directory structure; that is not the issue). What we don't want is a situation where the underlying operating system is also exposed. That is why we proposed the new scheme. I don't see how a scheme like widget://myWidget.wgt/path/to/file exposes anything about the underlying file system (apart from the name of the widget package)? Instead, file: exposes way too much IMO (i.e. file:///Users/marcos/Library/...! my username is exposed in the path, which everyone can acknowledge is pretty a bad thing, no?). file:, despite the name, doesn't have to be mapped to the file system. Its scope could be limited in exactly the same way you've limited widget: there. Similarly, ftp or http - even part of the space - *could* be mapped to the file system. So the issue you're worried about has little to do with the URI scheme. I suspect implementors are familiar with this issue already,
Re: [Widgets] URI Scheme revisited.... again
Hi Mark, Please see [1] for TAG discussion about WebApps proposal of widget URI scheme. From what I got from the discussion, the TAG seems to agree that we likely do need our own URI scheme. We just need to flesh out our technical argument a little more. We are also going to try to coordinate with the Open Document Format people as they also need something very similar. I again ask for your help in defining the scheme correctly, rather than arguing against it. [1] http://www.w3.org/2008/10/20-wam-minutes.html#item11 Kind regards, Marcos On Mon, Oct 13, 2008 at 4:59 PM, Mark Baker [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 10:31 AM, Marcos Caceres [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 5:08 AM, Mark Baker [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 4:00 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok, In one of my previous emails I said that this was a potential privacy/security issue: The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). I'm no security/privacy expert, but this seems like an easy way to at least get someone's username (from which I may be able to derive who they are, etc). Also, if the implementation is crap and does not restrict file:// to the scope of the widget package (thankfully Apple does), then widgets could basically read any files on the hard drive. Sure, but standardizing on a URI scheme won't fix this, because one can guess URIs in any scheme. Less opaque schemes like hierarchical ones are a little more susceptible of course, but it's a problem for all schemes. In the case of widgets, it's not a problem at all for the structure of the package to be guessed (as anyone can just decompress the widget locally anyway and take a look at it's directory structure; that is not the issue). What we don't want is a situation where the underlying operating system is also exposed. That is why we proposed the new scheme. I don't see how a scheme like widget://myWidget.wgt/path/to/file exposes anything about the underlying file system (apart from the name of the widget package)? Instead, file: exposes way too much IMO (i.e. file:///Users/marcos/Library/...! my username is exposed in the path, which everyone can acknowledge is pretty a bad thing, no?). file:, despite the name, doesn't have to be mapped to the file system. Its scope could be limited in exactly the same way you've limited widget: there. Similarly, ftp or http - even part of the space - *could* be mapped to the file system. So the issue you're worried about has little to do with the URI scheme. I suspect implementors are familiar with this issue already, but if you like, you could point out that implementations should ensure that widgets can't access local resources that the implementation doesn't want them to access. We will of course point out that implementations should ensure that widgets can't access local resources. That is explicitly part of the requirement for the URI scheme. Good. Mark. -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] URI Scheme revisited.... again
On Fri, Oct 24, 2008 at 6:51 AM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi Mark, Please see [1] for TAG discussion about WebApps proposal of widget URI scheme. From what I got from the discussion, the TAG seems to agree that we likely do need our own URI scheme. Hmm, have you read the minutes? Obviously you were part of the discussion and so perhaps something was said that didn't get minuted, but it seems quite clear to me from those minutes that the TAG is asking for more information, and that they were leaning away from a new URI scheme until they get that information, e.g.; Norm NW: My position is roughly in line with Noah's. If you're going to allow these things to leak out, or if it's going to be valuable to share them, then I think the logical thing to do would be to use http: URIs in that case. Norm ...And if you do that, I'd be highly motivated to see if it's possible to use http: for all the names so that you don't need to names. Of course, that doesn't address my argument that even if they don't leak out - which you indicated to me that they wouldn't - that the scheme becomes an implementation detail. Mark.
Re: [Widgets] URI Scheme revisited.... again
On Mon, Oct 13, 2008 at 10:31 AM, Marcos Caceres [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 5:08 AM, Mark Baker [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 4:00 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok, In one of my previous emails I said that this was a potential privacy/security issue: The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). I'm no security/privacy expert, but this seems like an easy way to at least get someone's username (from which I may be able to derive who they are, etc). Also, if the implementation is crap and does not restrict file:// to the scope of the widget package (thankfully Apple does), then widgets could basically read any files on the hard drive. Sure, but standardizing on a URI scheme won't fix this, because one can guess URIs in any scheme. Less opaque schemes like hierarchical ones are a little more susceptible of course, but it's a problem for all schemes. In the case of widgets, it's not a problem at all for the structure of the package to be guessed (as anyone can just decompress the widget locally anyway and take a look at it's directory structure; that is not the issue). What we don't want is a situation where the underlying operating system is also exposed. That is why we proposed the new scheme. I don't see how a scheme like widget://myWidget.wgt/path/to/file exposes anything about the underlying file system (apart from the name of the widget package)? Instead, file: exposes way too much IMO (i.e. file:///Users/marcos/Library/...! my username is exposed in the path, which everyone can acknowledge is pretty a bad thing, no?). file:, despite the name, doesn't have to be mapped to the file system. Its scope could be limited in exactly the same way you've limited widget: there. Similarly, ftp or http - even part of the space - *could* be mapped to the file system. So the issue you're worried about has little to do with the URI scheme. I suspect implementors are familiar with this issue already, but if you like, you could point out that implementations should ensure that widgets can't access local resources that the implementation doesn't want them to access. We will of course point out that implementations should ensure that widgets can't access local resources. That is explicitly part of the requirement for the URI scheme. Good. Mark.
Re: [Widgets] URI Scheme revisited.... again
On Mon, Oct 13, 2008 at 3:59 PM, Mark Baker [EMAIL PROTECTED] wrote: file:, despite the name, doesn't have to be mapped to the file system. Its scope could be limited in exactly the same way you've limited widget: there. Similarly, ftp or http - even part of the space - *could* be mapped to the file system. So the issue you're worried about has little to do with the URI scheme. On Mon, Oct 13, 2008 at 4:21 PM, Marcos Caceres [EMAIL PROTECTED] wrote: That's absolutely true. actually, it isn't. file has a host field and a well defined if utterly ignored meaning. it basically means that if i am not the host listed, then i'm supposed to error. file://foopy/tmp should only work if i'm foopy, or something strange like that. you can't simply hijack the host field from file, it's both reserved and has hacks in the most likely user agents to handle cases where people improperly used it (resulting in either file:/// or file:/). It could be that, for instance, we recommend file://widgetEngine/widget.wgt/path/to/file or just file:///widget.wgt/path/to/file. But we are still stuck on the fact that file: hasn't been formally standardized anywhere. Does that matter? and the fact that file has behaviors which are not going to be friendly to such abuse.
Re: [Widgets] URI Scheme revisited.... again
Hi, It seems to me that Requirement 6 should be split into two requirements: A. A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime. B. A conforming specification MUST specify or recommend an addressing scheme to address individual widget instances. For requirement A, I think that, given that the WG specifies a Packaging Format for Widget, it could define as well a Fragment Identifiers syntax for this package. This would have the advantage of separating/hiding the protocol used to retrieved the widget and therefore address the problem of The addressing scheme MUST NOT expose the underlying file system (if any). I think authors are also used to that mechanism and therefore would satisfy The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed. For requirement B, correct me if I'm wrong, but since the exact identifier of a widget instance can only be known at runtime, I don't see how an author can determine it declaratively as a URL before instantiation. So, the URL to the widget instance has to be created at runtime as well. Therefore, I imagine that there could be an API to do the following: querying the available widget instances, then requesting a URL (internal to the User Agent) to a particular widget instance and finally creating the final URL using the previous URL and appending a proper fragment identifier. Therefore it seems to me that a new URI scheme is not necessary. Where is my reasoning wrong? Regards, Cyril Marcos Caceres a écrit : Hi Mark, On Thu, Oct 9, 2008 at 6:00 AM, Mark Baker [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres [EMAIL PROTECTED] wrote: snip Any hierarchical URI scheme would seem to be able to meet those requirements. So why not, for the sake of argument, file:? Yes, file: might be ok. But where is the spec that defines file:? I can't find it. Good question. At least twice during the past 15 years or so, somebody's tried to write a spec for it, but both times that's ended in failure (e.g. http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought it up only as an example, because it doesn't carry all that network resource mental baggage that many people commonly associate with schemes such as ftp or http. It's still possible to use it of course, as long as the fuzzy areas are avoided. I see what you mean, the Hoffman draft above reads more like a here is a list of what is wrong with file: rather than a spec. And rfc1738 has been obsoleted. But I wonder whether the scheme really matters very much. What kind of intra-package references do you expect to be able to resolve? Will they all be relative, or will there be absolute ones? If it's just relative references, then any hierarchical one will do, as the consuming user agent can just mint their own base, be it an http URI, a file URI, or otherwise. We use both relative and absolute URI references, and the base is derived from the i18n model we have introduced. The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). Personally, the solution I keep coming to is something like : widget-uri = http://; widget-engine [: instance-id] / package-name path-absolute [# fragment] Where widget-engine is something akin to using, say, localhost, but uses some arbitrary string that identifies the engine (e.g. theFooEngine). The optional instance-id would be a string that uniquely identifies a widget instance for the purpose of cross-widget communication. However, I can foresee that there may be problems with thieving http's port semantics to uniquely identify an instance (so we leave this out until version 2). The scheme would only support GET requests. For example, http://theFooEngine/barWidget.wgt/index.html#welcome Kind regards, Marcos -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [Widgets] URI Scheme revisited.... again
On Fri, Oct 10, 2008 at 3:29 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok. I will add Any hierarchical URI scheme as the proposed solution into the spec. I will say that, personally, I feel it is irresponsible for the WebApps WG to not recommend a complete and a secure solution for this issue. I also fear that not mandating a URI scheme will lead to interoperability issues (especially going forward into V2, where we might want to support things like queries and fragments, which something like file: does not support). Well, the questions I asked of you were intended to discover whether or not interoperability was impacted by not specifying a URI scheme. Is there some aspect of this I didn't consider? Can you give me an example of an interoperability (or security, as you say) problem that's created by not specifying a URI scheme? Mark.
Re: [Widgets] URI Scheme revisited.... again
On Fri, Oct 10, 2008 at 8:35 PM, Mark Baker [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 3:29 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Ok. I will add Any hierarchical URI scheme as the proposed solution into the spec. I will say that, personally, I feel it is irresponsible for the WebApps WG to not recommend a complete and a secure solution for this issue. I also fear that not mandating a URI scheme will lead to interoperability issues (especially going forward into V2, where we might want to support things like queries and fragments, which something like file: does not support). Well, the questions I asked of you were intended to discover whether or not interoperability was impacted by not specifying a URI scheme. Is there some aspect of this I didn't consider? Can you give me an example of an interoperability (or security, as you say) problem that's created by not specifying a URI scheme? Ok, In one of my previous emails I said that this was a potential privacy/security issue: The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). I'm no security/privacy expert, but this seems like an easy way to at least get someone's username (from which I may be able to derive who they are, etc). Also, if the implementation is crap and does not restrict file:// to the scope of the widget package (thankfully Apple does), then widgets could basically read any files on the hard drive. -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] URI Scheme revisited.... again
On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres [EMAIL PROTECTED] wrote: snip Any hierarchical URI scheme would seem to be able to meet those requirements. So why not, for the sake of argument, file:? Yes, file: might be ok. But where is the spec that defines file:? I can't find it. Good question. At least twice during the past 15 years or so, somebody's tried to write a spec for it, but both times that's ended in failure (e.g. http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought it up only as an example, because it doesn't carry all that network resource mental baggage that many people commonly associate with schemes such as ftp or http. It's still possible to use it of course, as long as the fuzzy areas are avoided. But I wonder whether the scheme really matters very much. What kind of intra-package references do you expect to be able to resolve? Will they all be relative, or will there be absolute ones? If it's just relative references, then any hierarchical one will do, as the consuming user agent can just mint their own base, be it an http URI, a file URI, or otherwise. Mark.
Re: [Widgets] URI Scheme revisited.... again
Hi Mark, On Thu, Oct 9, 2008 at 6:00 AM, Mark Baker [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres [EMAIL PROTECTED] wrote: snip Any hierarchical URI scheme would seem to be able to meet those requirements. So why not, for the sake of argument, file:? Yes, file: might be ok. But where is the spec that defines file:? I can't find it. Good question. At least twice during the past 15 years or so, somebody's tried to write a spec for it, but both times that's ended in failure (e.g. http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought it up only as an example, because it doesn't carry all that network resource mental baggage that many people commonly associate with schemes such as ftp or http. It's still possible to use it of course, as long as the fuzzy areas are avoided. I see what you mean, the Hoffman draft above reads more like a here is a list of what is wrong with file: rather than a spec. And rfc1738 has been obsoleted. But I wonder whether the scheme really matters very much. What kind of intra-package references do you expect to be able to resolve? Will they all be relative, or will there be absolute ones? If it's just relative references, then any hierarchical one will do, as the consuming user agent can just mint their own base, be it an http URI, a file URI, or otherwise. We use both relative and absolute URI references, and the base is derived from the i18n model we have introduced. The reason we don't want to allow vendors to mint their own is that there are potential security and privacy issues related to URI schemes such as file:. For instance, because Dashboard uses file: it is very easy for me to work out what the username and home directory of a user on MacOsX by simply picking up any DOM node that contains a dereferenced URI (eg. by examining an img's src, I get something like file:///Users/marcos/Library/widget/Default.png). Personally, the solution I keep coming to is something like : widget-uri = http://; widget-engine [: instance-id] / package-name path-absolute [# fragment] Where widget-engine is something akin to using, say, localhost, but uses some arbitrary string that identifies the engine (e.g. theFooEngine). The optional instance-id would be a string that uniquely identifies a widget instance for the purpose of cross-widget communication. However, I can foresee that there may be problems with thieving http's port semantics to uniquely identify an instance (so we leave this out until version 2). The scheme would only support GET requests. For example, http://theFooEngine/barWidget.wgt/index.html#welcome Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] URI Scheme revisited.... again
Marcos - IIRC, there was little or no support for a widget URI scheme in the discussion on www-tag. Why are you continuing to move ahead with it? Note that you'll still have to get this past IANA who maintains the registry. IANA uses a process specified in RFC 4395 which says; The use and deployment of new URI schemes in the Internet infrastructure is costly; some parts of URI processing may be scheme-dependent, and deployed software already processes URIs of well-known schemes. Introducing a new URI scheme may require additional software, not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [11]. URI schemes constitute a single, global namespace; it is desirable to avoid contention over use of short, mnemonic scheme names. For these reasons, the unbounded registration of new schemes is harmful. New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes. -- http://tools.ietf.org/html/rfc4395#section-2.1 Mark. On Tue, Oct 7, 2008 at 1:31 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi All, I think, for V1, that we should drop the authority part of the widget URI scheme and leave it as an implementation detail (but add a note saying that we might add a scheme in V2). I propose this because we don't currently have an API or security/interaction model for cross-widget communication and I don't think we will get one by the end of the year (not from me, anyway... and I haven't seen any other member put forward any real viable solution to this problem). Another reason is that it simplifies the widget URI scheme, but still allows us to expand on it later (v2). My proposal is: widget-uri = widget:// path-absolute [# fragment] (query strings are not supported (ignored) in v1) In other words, DOM nodes would be resolved to: widget:///someFolder/SomeFile.ext#someFragment I'm also not convinced that uniquely identifying the widget should be part of the authority (if we do decide to use it, would it b more appropriate to hijack the :port?). For example, widget://:a34af23bh23/myFile.png Marcos -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] URI Scheme revisited.... again
Hi Mark, On Wed, Oct 8, 2008 at 4:28 PM, Mark Baker [EMAIL PROTECTED] wrote: Marcos - IIRC, there was little or no support for a widget URI scheme in the discussion on www-tag. Why are you continuing to move ahead with it? Sorry Mark, I'm afraid that your recollection on this issue is wrong. Firstly, I was not aware that the TAG dictated what Web Apps works on. Secondly, the TAG is interested in solving this problem as much as we are [1]. Thirdly, TAG members have requested time at TPAC to meet with Web Apps to allow us to move forward on this issue (if there was little support, then why do they want to meet with us? [2]). Fourthly, we continue to push for a URI scheme because we can't resolve DOM nodes in widgets to nothing (and we see the use of the file:// scheme as bad (and not standardized) and http://; as too complex for V1). There is no way for us to ignore the URI issue, so we need help in resolving it. Asking us to stop working on this is not an option. However, if you can help us or point us in the right direction then please do so! Note that you'll still have to get this past IANA who maintains the registry. IANA uses a process specified in RFC 4395 which says; The use and deployment of new URI schemes in the Internet infrastructure is costly; some parts of URI processing may be scheme-dependent, and deployed software already processes URIs of well-known schemes. Introducing a new URI scheme may require additional software, not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [11]. URI schemes constitute a single, global namespace; it is desirable to avoid contention over use of short, mnemonic scheme names. For these reasons, the unbounded registration of new schemes is harmful. New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes. -- http://tools.ietf.org/html/rfc4395#section-2.1 We have evaluated other options and none seem suitable. However, I we are always open to suggestions of schemes to investigate (so long as they are in line with our packaging requirements; hence, no MIME formats for version 1.0 please!). The requirement for the URI scheme is as follows: R6. Addressing Scheme A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime. The addressing scheme MUST be able to address individual widget instances, while potentially allowing widgets to address each other. The addressing scheme MUST NOT expose the underlying file system (if any) to the instantiated widget and an instantiated widget MUST NOT be able to address resources outside the widget resource via the addressing scheme. The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed. Motivation: Ease of use, compatibility with other standards, current development practice or industry best-practice, and security. Rationale: To allow resources to be resolved and normalized within DOM attributes. To make it easy for authors to address and load resources into their instantiated widgets, either declaratively or programmatically. For example, addressing a resource via an IRI reference (e.g. img src=images/bg.png'/ where the src attribute resolves to something akin to widget://myWidget/images/bg.png). To disable access that could lead to potentially unsafe manipulation by widget instances to the underlying file system (if any) or other resources which are not instances of the same widget or resources contained in the widget resource used to create the current set of widget instances. Kind regards, Marcos [1] http://www.w3.org/2001/tag/group/track/issues/61 [2] http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda -- Marcos Caceres http://datadriven.com.au
[Widgets] URI Scheme revisited.... again
Hi All, I think, for V1, that we should drop the authority part of the widget URI scheme and leave it as an implementation detail (but add a note saying that we might add a scheme in V2). I propose this because we don't currently have an API or security/interaction model for cross-widget communication and I don't think we will get one by the end of the year (not from me, anyway... and I haven't seen any other member put forward any real viable solution to this problem). Another reason is that it simplifies the widget URI scheme, but still allows us to expand on it later (v2). My proposal is: widget-uri = widget:// path-absolute [# fragment] (query strings are not supported (ignored) in v1) In other words, DOM nodes would be resolved to: widget:///someFolder/SomeFile.ext#someFragment I'm also not convinced that uniquely identifying the widget should be part of the authority (if we do decide to use it, would it b more appropriate to hijack the :port?). For example, widget://:a34af23bh23/myFile.png Marcos -- Marcos Caceres http://datadriven.com.au
