- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 29 Oct 2008 09:39:01 -0400
- To: ext Marcos Caceres <marcosscaceres@gmail.com>
- Cc: "Mark Baker" <distobj@acm.org>, public-webapps <public-webapps@w3.org>
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 <distobj@acm.org> wrote: >> On Mon, Oct 13, 2008 at 10:31 AM, Marcos Caceres >> <marcosscaceres@gmail.com> wrote: >>> On Mon, Oct 13, 2008 at 5:08 AM, Mark Baker <distobj@acm.org> wrote: >>>> On Fri, Oct 10, 2008 at 4:00 PM, Marcos Caceres >>>> <marcosscaceres@gmail.com> 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 >
Received on Wednesday, 29 October 2008 13:40:07 UTC