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
