- From: Mark Baker <distobj@acm.org>
- Date: Mon, 13 Oct 2008 10:59:52 -0400
- To: "Marcos Caceres" <marcosscaceres@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>
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.
Received on Monday, 13 October 2008 15:00:28 UTC