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

Follow-up on widgets scheme discussion with TAG members [Was: Re: [Widgets] URI Scheme revisited.... again]

From: Arthur Barstow <art.barstow@nokia.com>
Date: Wed, 29 Oct 2008 09:39:01 -0400
Message-Id: <BD4AC2A4-3E9C-46FB-9223-8FBF5D31BC17@nokia.com>
Cc: "Mark Baker" <distobj@acm.org>, public-webapps <public-webapps@w3.org>
To: ext Marcos Caceres <marcosscaceres@gmail.com>

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:


Perhaps some of these should be more explicit:


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 <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 Wednesday, 29 October 2008 13:40:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC