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 <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 Friday, 24 October 2008 10:52:29 UTC