Re: Simple approach for <access>

In our implementation we plan to use the <access> information to  
provide the information needed for our whitelist proxy server; however  
it would be a hint to the administrator to confirm adding the  
whitelist rules requested by the widget rather than be an automated  
addition to the whitelist.

So far we haven't come across a widget thats needed more than - at  
most - access to a few services, all coded as a single URL or single  
domain.  The only exception to the rule are RSS widgets, but these are  
right at the other end of the spectrum, and would need <access  
href="*"/>.

I think the wording here is perhaps phrased in an 'inverted' way:  
<access> provides hints to the UA that it should permit access to the  
specified resource, its not about restricting restrict access to  
unspecified resources, which would seem to me to be entirely a  
question for the implementation. For example, Apache Shindig ships  
with completely open network access for widgets as the default.

S

On 16 Apr 2009, at 16:23, Thomas Roessler wrote:

> Robin wrote:
>
>> The <access> element is used to restrict a widget's access to a
>> limited set of network resources. In the absence of an <access>
>> element, all access to network resources is forbidden.
>>
>> The <access> element has a single @href attribute the content of  
>> which
>> is an IRI-like string. The access opening that is specified by that
>> string is defined as follows:
>>
>>   - the scheme component MUST be present, and access is granted only
>> for that scheme; and
>>   - the host component MUST be present. If it begins with "*." then
>> the host that follows the "*." is granted access to, as well as all  
>> of
>> its lower-level domains; otherwise access is only granted for that
>> domain; and
>>   - if the port component is absent, it is considered to be specified
>> to be the default for the provided scheme. Access is granted only to
>> that port; and
>>   - if the path and query string component is present, then access is
>> granted for any path and query string that starts with the specified
>> string. It is treated as an opaque string, no attempt must be made to
>> map to potential directories on the remote server; and
>>   - if a fragment component is specified, it must be ignored.
>
> Two questions:
>
> 1. How is the information in this access element going to be used at  
> installation time or distribution time?  I'd like to see some spec  
> text that explains this.
>
> 2. If one of the risks we're interested in is firewall traversal,  
> then then proposed domain name wildcard has a somewhat different  
> risk profile than just a single domain name:  while you can do a DNS  
> rebinding attack for a single hostname, that's a well-known issue,  
> and hopefully worked around in today's browser engines.  With the  
> wildcard, though, it becomes relatively easy to do firewall  
> traversal:  For example, one could simply generate DNS records  
> n.n.n.n.example.com that point to the IP address n.n.n.n.
>
> I wonder whether it might be useful to clearly distinguish the two  
> cases (given the different risk profiles); I'd also like to see some  
> discussion of this effect in the security considerations.
>
> Thanks,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>
>