RE: [widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec)

Comments inline.

Thanks,

Mark 

>-----Original Message-----
>From: marcosscaceres@gmail.com 
>[mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
>Sent: 22 February 2009 16:02
>To: Priestley, Mark, VF-Group
>Cc: Arthur Barstow; public-webapps
>Subject: Re: [widgets] The access element (was: RE: Reminder: 
>January 31 comment deadline for LCWD of Widgets 1.0: Packaging 
>& Configuration spec)
>
>Hi Mark,
>
>2009/2/19 Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>:
>> Hi All,
>>
>> In the email [1] containing my comments against the LCWD of 
>Widgets 1.0:
>> Packaging & Configuration spec, I wrote:
>>
>>>> 7.10 The access Element
>>>> The access element defines a network attribute as "A boolean
>> attribute
>>>> that indicates that the widget might need to access network 
>>>> resources
>>
>>>> as specified in [Widgets-Security]. "
>>>>
>>>> Based on this description we would like to make the following 
>>>> observations and suggestion:
>>>>
>>>> The access element contains security permissions that will be used 
>>>> as
>>
>>>> hooks in the yet to be written [Widgets-Security] 
>specification. The 
>>>> problem is that the permissions haven't yet been discussed 
>in detail 
>>>> and so we may find that we want to represent additional context 
>>>> other
>>
>>>> than a black and white "is network access required?". For example, 
>>>> it
>>
>>>> may be the case that it is important from a security point of view 
>>>> to
>>
>>>> know which bearer or protocol will be used, or to nest a set of 
>>>> domains/URLs with which the widget wants to communicate. I do not
>> have
>>>> a strong view on what might be relevant here, and I am not 
>>>> suggesting
>>
>>>> that it needs to be considered as part of the last call of the 
>>>> Packaging and Configuration spec, only that it is likely that the 
>>>> permission will need to be more complex when we look at it from a
>> security perspective.
>>
>> Marcos replied:
>>
>>> I think we better start this soon, then. My feeling is that we will
>> need some kind of <domain> access declarations, and I would like to 
>> see them in the > configuration document.
>>
>> My follow up:
>>
>> Marcos makes the suggestion that he would like to see the access 
>> element replaced/extended with domains. Vodafone have come to a 
>> similar conclusion. We feel that a widget author should be able to 
>> declare the hosts with which they want to communicate. The widget 
>> should then only be allowed to communicate with those hosts.
>>
>> This is beneficial for two reasons:
>>
>> 1.) It allows the widget author to practice the principle of least 
>> privilege, limiting the potential attack space
>
>Agreed.
>
>> 2.) It allows other parties (users, widget distributors, consuming 
>> widget user agents) to inspect the widget to get some idea 
>of who the 
>> widget will communicate with, thereby enabling more sensible 
>security 
>> decisions to be made.
>
>Agreed.
>
>> There is however one exception that we would like to enable, the 
>> ability for a widget author to indicate that their widget might be 
>> expected to communicate with any host. This is to allow for 
>use cases 
>> such as widget RSS readers. We would therefore like to propose that 
>> the access element is extended along the following lines:
>>
>> <access>
>>    <network any-host="true/false">
>>        <target host="somehost.com" />
>>        <target host="en.anotherurl.com" />
>>    </network>
>> </access>
>
>Firstly, this assumes communication over HTTP. I think we need 
>to make this protocol agnostic. How do I indicate I want to 
>use HTTPs? You would need a special purpose URI parse that can 
>parse malformed URIs.
>
>I propose the simpler:
>
><access network="true">
>     <domain href="URI" />
></access>
>
>The semantics of the URI can be derived from whatever URI type 
>is used (most likely case will be HTTP, in which case you 
>parse the URI semantics using RFC2616). User agents can 
>support whatever URIs they like, or exclude others (e.g., file://).
>

Agreed - with some comments below

>> Declaring <network any-host="true"/> would mean that regardless of 
>> whether the network element contained any child domain elements, the 
>> author was declaring that they wanted access to any host 
>(note that by 
>> default this value would be "false" so only authors who 
>wanted access 
>> to any host would be inclined to use it).
>
>I suggest a special case of <domain>:
>
><domain href="*"/>

Agreed - the only advantage I saw of using an attribute was that if an
author incorrectly specified specific domains and the "all domains"
value, the user agent wouldn't have to process the specific domains that
were in error. But I agree this was ugly and support a special domain
value as you suggest. 

>
>
>> There is IMO an open question as to whether it would better 
>to specify:
>>
>> 1. full URLs in place of hostnames, eg:
>>
>> <target url="http://somehost.com" />
>
>From my point of view, yes... as per the rationale above.

I mostly agree but with some follow up questions below...

>
>> 2. hostnames (to allow for use of http and https and other protocols 
>> without requiring multiple declarations), maybe by using an 
>additional 
>> attribute, eg:
>>
>> <target host="somehost.com" protocol="http"/>
>
>URIs already define all this, so we don't need to break up the 
>URIs into their parts. The semantics of HTTP URIs are well 
>understood and already easily parsed by implementations.

Point accepted - I was not trying to re-invent URIs! My only additional
thought here is that separating the protocol could allow you to specify
the use of multiple protocols with a single host without requiring
separate elements. Not a strong argument so happy to drop this as a
proposal.

>
>> 3. hostnames + paths (to allow authors to restrict access to specific
>> resources)
>> <target host="somehost.com" protocol="http" path="/images"/>
>>
>
>Would be supported by using URIs:
>
><domain href="http://somehost.com/images/"/>
>
>OR
>
><domain href="http://example.com/resource" />
>

Agreed - question remains what the following would mean:

<domain href="http://example.com" />

Anything resource from example.com requested using http? And the
inclusion of a path would restrict access to that directory and its
sub-directories? For example:

<domain href="http://example.com/resource" />

Would allow http access to resources in "example.com/resource" but not
"example.com/images".

Similarly, if no port was declared then any port would be allowed, but
if a port was declared then only that port would be allowed. If so then
I think this would be OK for Widget's 1.0 but I would welcome opinions
from others. For example, would there be any value in specifying special
wildcard values for protocols and sub domains?     

>The resource could then be exploited (in a good way) at 
>runtime through query strings:
>
><script src="http://example.com/resource?callback=helloThere" >
>
>FWIW, I think we need to look at what CORS is doing with 
>respect to this and mirror as much as we can:
>http://dev.w3.org/2006/waf/access-control/
>

I've had a look at the latest version of the CORS spec and IMHO its
addressing a slightly different use case and therefore not immediately
clear how it would be applicable in this context, although I think it is
complimentary. I would however be happy to be corrected.

>> Related to the above options is whether or not the omission of 
>> protocols and paths could/should be specified to mean "any value". 
>> This would allow a certain degree of flexibility while still 
>allowing 
>> the author to lock things down if they wanted.
>
>There is also port. Again CORS has dealt with a lot of this, 
>so we might look there for guidance.
>
>> I would like to also bring it to the group's attention that 
>BONDI have 
>> also identified this as an issue and have specified 
>something similar 
>> to the proposal above - see [2] section 3.3.4 - as an 
>extension to the 
>> W3C configuration document.
>>
>> Ignoring where the element is located and the additional attributes, 
>> the main difference between the BONDI approach and the 
>approach that I 
>> have outlined here is that BONDI does not restrict the 
>widget to only 
>> access those hosts declared but instead uses the declarations as 
>> values to evaluate within the security policy. This is an 
>advantage in 
>> one respect as it allows a lot of flexibility - the policy can 
>> restrict the widget to only the declared hosts, or the 
>declared hosts 
>> plus a whitelist of safe hosts etc, and can also control whether or 
>> not wildcarding is allowed.
>
>Agreed. This seems like a good idea, but it should together 
>with the solution we define in the spec.
>
>> However, I would argue that the BONDI approach also presents a 
>> significant disadvantage, namely that in relying on the security 
>> policy of the consuming device to interpret the declared 
>targets, the 
>> behaviour is unpredictable for the widget author, distributor and 
>> potentially the user.
>
>Agreed.
>
>> This is the main reason that I am not suggesting that the BONDI 
>> approach is adopted as is. I will also cross post this email to the 
>> BONDI list to get feedback. Speaking from a Vodafone perspective and 
>> as someone who participates in both W3C WebApps and BONDI, 
>ideally we 
>> would like to see the solution specified in W3C and then simply 
>> referenced in BONDI. With BONDIs current specifications being at 
>> Candidate Release status until the 9th March there is still a good 
>> opportunity to achieve this kind of alignment.
>
>BONDI's approach sounds implementation specific, which might be ok.
>Like you outlined, it does have significant disadvantages.
>
>> I realise that it's late in the day to be specifying new 
>elements but 
>> I think there are real advantages to extending the access element in 
>> the way proposed and it addresses a real use case.
>
>No it's cool. We've known about this issue from the beginning 
>(As the P&C spec originated from Opera, there was something 
>similar to what you are proposing in the very first draft of 
>this specification. See the <access> element in the following link:
>http://dev.opera.com/articles/view/opera-widgets-specification-
>1-0/#xmlsecurityaccess
>
>It was originally in our spec, but we took it out because it 
>was problematic.... and we (the WG) are still trying to solve 
>the problem!
>:) )

OK great - I think the approach you propose in this email (with the
addition of a description of the corresponding user agent behaviour)
meets our requirements and is something we'd be happy to see in Widgets
1.0.

>
>Kind regards,
>Marcos
>
>--
>Marcos Caceres
>http://datadriven.com.au
>

Received on Monday, 23 February 2009 14:20:14 UTC