Re: [WARP] Extending access to local network resources

On Thu, 14 Jan 2010 19:04:18 +0100, Stephen Jolly  
<stephen.jolly@rd.bbc.co.uk> wrote:


> There are a very large number of such networks in use worldwide: I  
> believe that the vast majority of home networks and many wireless  
> networks fall into this category.  The BBC is specifically concerned  
> that the lack of distinction between local network resources and  
> Internet resources in the current WARP model could prevent widgets from  
> being able to access network resources served from media devices on home  
> networks.
>
> Anyway, the specific proposal I would like to make is for another  
> special value of the "origin" attribute of the "access" element in the  
> widget configuration document called "link-local" or similar, an  
> associated special value in the access-request list and an associated  
> processing rule that says that when the "link-local" value is specified,  
> the user agent should grant access to network resources on the same  
> subnet(s) as the user agent.

Just so we are on the same page here, by link-local, you mean exactly what  
(for IPv4) is defined in RFC 3927, which roughly translates to «Two  
devices connected directly, without involvment of DHCP» - a.k.a.  
169.254.0.0/16?

> 2. Users are likely to want control over which specific networks a  
> widget is granted access to, rather than just a blanket "yes" or "no"  
> permission to access whatever local network(s) to which the host may be  
> connected when the widget is running.  I don't think that this is  
> something that can or should be dealt with in the configuration of  
> widgets.  I believe that good user experiences can be constructed to  
> give the user that control, but I won't go into detail unless somebody  
> asks me to.

I don't think going into detail is necessary at this stage.

> 3. I would expect most *useful* widgets that can access local network  
> resources to need some kind of ability to browse the local link for  
> resources to access.  Again, I think that's out of scope for a WARP  
> alteration/supplement; it's the sort of thing people use mDNS + DNS-SD  
> or UPNP's SSDP for, but those aren't web protocols, and Robin's  
> threatened to drag me into the DAP WG if I start talking about device  
> APIs.

The mDNS-bit is about local service discovery, and likely belongs in the  
DAP, yes.


> 4. Clearly the "local network" and the "local link" are not necessarily  
> the same thing.  I'm proposing a solution targeting the latter because  
> (a) it actually has a useful definition and (b) I believe it to be  
> sufficient for the use cases I care about.

Provided my understanding of link-local is in line with yours, I would  
prefer a mechanism for accessing the local network.

> I look forward to your comments and criticisms - in particular I would  
> like to understand the holes that Arve says are opened by making a  
> distinction between "local" and "remote" IP addresses.

To moderate my statement a bit - it's more a concern than a risk, when you  
at all allow access to "local network", and you have relaxed cross-domain  
security, a maliciously crafted widget can potentially attack local  
networking equipment such as routers. (This risk also exists on the web,  
but is generally less practical, given that an attacker would be shooting  
blind due to the same-origin-policy)

The other problem is one of the definition of local network not being  
entirely clear - the archetypal definition is the IPv4 one with four  
reserved IP ranges.  That definition breaks for IPv6, and it breaks for  
networks not using NAT.  In order to have a useful definition, the network  
would have to provide information about the locality of any given host a  
widget tries to access.



-- 
Arve Bersvendsen

Opera Software ASA, http://www.opera.com/

Received on Thursday, 21 January 2010 07:19:28 UTC