W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [Widgets] URI Scheme revisited.... again

From: Mark Baker <distobj@acm.org>
Date: Mon, 13 Oct 2008 10:59:52 -0400
Message-ID: <e9dffd640810130759q98166ceo613f5a88119de736@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT