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 <[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
