Issue with semantics of the access element in WARP
Hi there, Reading through the current WARP draft, I note that the semantics of the element appear to preclude an important use case (for us). At BBC R&D one of the things we're currently working on is the control of personal video recorders and TV set-top boxes, from other devices on the home network, via web APIs. We see mobile phones as a key client platform for this kind of interface. There appears to be optimism at present that widgets (and preferably standardised widgets!) will provide a relatively low-fragmentation development environment for mobile application developers. Given this, we're very keen to push the idea that widget standards should allow for access to the home networks to which mobile phones are increasingly gaining connectivity via WiFi (and perhaps, in the future, via Femtocells). The current draft of WARP effectively prevents widgets from connecting to devices on home networks, because the semantics of the element only allow widgets to request access to URIs with authorities that are known to the widget publisher at the time of publication. Devices on home networks are generally not referenced by DNS records, and have unpredictable IP addresses. Obviously requesting access to "*" would, if granted by the user agent, permit connections of this sort, but my suspicion is that this would be an inappropriate mechanism: even if user agent vendors were to permit this kind of universal access by widgets (and there isn't a great track record for this kind of generosity in the mobile world, at least), surely the home network and the set of all possible URI authorities are very different domains, security-wise? I would love to hear opinions on this from the people on this list, most of whom have spent much longer thinking about these issues than I have... S
Re: [WARP] "uri" attribute is confusing
Phil Archer wrote: The problem is finding the right amount of flexibility without making it too complicated or opening unwanted security holes. ... It depends on your use cases of course. I guess the reason I've joined this discussion is that I'm concerned that most of the schemes out there (including the one proposed for WARP) don't allow the local network to be defined as a security domain, which precludes use cases I care about. The Opera widget security model has the concept of "private" addresses (the RFC 1918 and 3927 ranges) - I presume that this group made the conscious decision not to include this concept in the WARP model? Personally, I'm not sure even the Opera model[1] (which talks about these "private" addresses in the context of intranets) is as flexible as one might like: you could make a good case that 127.0.0.0/8 and the UA device's own IP address(es) masked by the appropriate subnet masks should be added to that list. It does all come down to the use cases though, and I guess my fundamental question is still whether or not widget access to resources on the local network is seen as important by this group. Answers welcome. :-) S [1] http://dev.opera.com/articles/view/opera-widgets-security-model/
Re: [WARP4U] WARP with UPnP
On 20 Nov 2009, at 17:12, Marcin Hanclik wrote: > As discussed on the yesterday's call, I committed to CVS the WARP spec with > the section about local network (required for UPnP use cases) at: > http://dev.w3.org/2006/waf/widgets-access-upnp/ Clearly there are usage scenarios based on technologies other than UPnP for a scheme that allows widgets to declare an intention to access network resources on the local network - simple web services discovered via mDNS/DNS-SD for example. I haven't seen a lot of discussion of this issue recently, apart from Marcin's proposals. If that reflects a general lack of enthusiasm, it would be useful to know if people's reservations are technical in nature, or if the scenarios in question are simply not thought to be common enough? S
Re: [WARP4U] WARP with UPnP
On 2 Dec 2009, at 13:05, Marcin Hanclik wrote: > I am sorry for bypassing earlier comments, I want to answer them anyway asap. > So here comes short summary. > >>> What are we trying to solve? > Forgetting the UPnP and related stacks, the issues can be summarized as > follows: > - pattern for IP addresses in URIs (we have pattern for domains, but nothing > for IP addresses) > > and/or > > - possibility to exclude local (definition needed: I proposed to leave it out > of scope if we cannot agree, but it could be home or corporate network or > private LAN etc) - network resource from being controlled with > element. This acts as a kind of (loosely defined) pattern for IP addresses. Keeping things simple, the most compelling use case I can see (aka the one I care about...) is where the developer wants to write a widget that can access resources on a network with no centralised DNS or developer-predictable IP addresses. This is the case for many home networks. As a concrete example, one of my projects here at BBC R&D is to write a web API for networked televisions and set-top boxes that fits this use case precisely. We'd like widget developers to be able to access it just as easily as native application developers can, and the current WARP spec precludes this. So it's not just about UPnP. (FWIW, we're seriously considering Robin's suggestion that the BBC appoint me as a representative on the webapps WG, but right now I'm not a member. Nevertheless I can put forward some implementation suggestions if that would be of interest to the group.) S
Re: [WARP4U] WARP with UPnP
On 3 Dec 2009, at 11:24, Robin Berjon wrote: > It would be really great if you were to join this group. If you are already > following this list, and willing to make implementation proposals, it > wouldn't necessarily take more of your time than it already does — probably > no more than an extra phone call now and then when we're discussing this > topic (of course, if you want to get more involved, that's fine as well!). It > would, however, help with the IPR thing. OK, I'm now the BBC representative on this WG. Don't expect the BBC to have an opinion on all the issues that the group discusses though. :-) > We certainly welcome technical solutions in this area. The scope of WARP 1.0 > was decided a while ago and since we need to ship it really shouldn't be > extended *but* it would not be difficult to have a separate document that > plugs on top of the existing one and that can be published quickly. Right now > a lot of the hesitation stems from the fact that we don't really have a clear > definition of what "local" is, so a solution that doesn't have that issue > will certainly be good. Indeed, and I haven't seen strong enthusiasm for Marcin's suggestion (http://dev.w3.org/2006/waf/widgets-access-upnp/) that the definition of "local" be left to the user agent. From my perspective the main issue with that proposal is that it's a bit of a recipe for unexpected behaviour on different platforms, so I'd like to explore the possibility of coming up with a stricter definition that the WG might be able to achieve consensus on. Opera have already defined the concept of "private network" access for widgets (details at http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#private_network). I'm not sure this is a perfect match for the "local network" in the use cases that have been mentioned here (indeed, I doubt it was intended to be), but the thing I like about this approach is that it's relatively simple for both widget developers and end-users to understand what it means, as well as being straightforward for UA developers to implement. Presumably including it in the WARP spec has already been considered and rejected by the WG though? I'm tempted to think that it should be possible to come up with a similar list of pre-standardised IP address ranges etc that could be considered "local", and if there's some support for exploring this approach from the other WG members, I'd be more than happy to cook up a straw-man proposal (hopefully covering both IPv4 and IPv6) for you all to poke holes in. S
Re: [widgets] Draft Minutes for 10 December 2009 Voice Conference
On 10 Dec 2009, at 14:48, Arthur Barstow wrote: > TWI spec: CfC to publish Candidate Recommendation > > AB: given we have addressed all of the TWI LC comments, it appears > the TWI spec is ready for Candidate. Any comments about that? > >+1 for CR > >yes! > >yes This was actually confirmation that I could hear you speaking on the conference call, but I am happy for the TWI spec to proceed to CR. > AB: anything eles on WARP spec for today? > ... perhaps SteveJ and Marcin can use this time > > SJ: I just send an email to the public list > > MH: I can provide some info to SJ re discussions related to the > "local" WARP requirement > > RB: I think Arve has ideas as well > ... it would be good to get some input from Opera > > SJ: any feedback on what Opera has done would be useful > >We'll call in again > > Arve: I just started to read SJ'e email > ... I authored the doc from Opera > ... but not sure that feature should be supported > ... think defn of local should be up to the local admin > ... not clear what should happen with IPv6 > > SJ: there is an RFC for IPv6 > ... I'll send it to the list > ... IPv6 is of course more complicated I meant that there was an RFC for IPV6 private network address space. It's this one: http://tools.ietf.org/html/rfc4193 > Arve: what's the use case for knowing what is local and what is not? > > SJ: there are some networks with no DNS or know IP addresses > ... but WARP requires an IP address that should read "known", not "know" S
[WARP] Extending access to local network resources
All, Back in December I volunteered (http://www.w3.org/2009/12/10-wam-minutes.html) to propose an alteration / supplement to WARP to permit widget access to resources on local networks with no managed DNS system. Such resources do not fit into the current WARP model of listing origins in the widget's configuration document unless those resources have IP addresses known in advance to the developer. 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. I haven't gone into more technical detail in this email because I suspect that there will be sufficient disagreement with the general principles laid out above to generate a productive discussion. A few points, though: 1. I think that the definition of a subnet in IP versions 4 & 6 is sufficient to allow a meaningful definition of "link-local". 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. 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. 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. 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. S
Re: [WARP] Extending access to local network resources
On 21 Jan 2010, at 07:18, Arve Bersvendsen wrote: > On Thu, 14 Jan 2010 19:04:18 +0100, Stephen Jolly > wrote: >> 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? RFC 3927 defines a set of IPv4 addesses that are guaranteed to be either unreachable or assigned to other hosts on the local link. Such hosts may have other addresses though, so I'm defining "link-local" to *any* address on "the local subnet(s)". I believe that a user agent can determine this straightforwardly (by resolving the hostname in the requested resource's URL and comparing the routing prefix of the resulting IP address to the routing prefixes of the IP addresses of the host on which the user agent is running, be they IPv4 or IPv6 addresses). Clearly the fact that a host can be connected to multiple networks, consecutively or simultaneously, needs to be taken into account when the policy and user interface for granting network access are implemented, as does the fact that some "local" networks can contain a large number of untrusted third parties: public WiFi hotspots or mobile data networks, for example. >> 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) I agree that "link-local" security would not protect local network resources from maliciously crafted widgets, but I think that's unavoidable. In this particular respect defining a "link-local" set of origins offers no additional security over simply using , I agree. However, there are other respects in which additional security is provided (eg the user gains some control over the origins with which potentially private information can be shared), and there are other advantages (eg the user can be moderately confident that a video streaming application is only going to stream from the local network, rather than an expensive connection between the local network and the Internet). > 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. I believe that the Unique Local Addresses defined by RFC 4193 are the IPv6 equivalent to the reserved "private network" ranges in IPv4. It might therefore be possible to define a set of "non-globally-routable" addresses for IPv4 and IPv6 similar to your definition of IPv4 private networks for Opera widgets (http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#private_network), but I think that a "link-local" restriction is a better match to my use cases. S
[WARP] Use cases for local network access
All, As actioned in the 21st Jan teleconference, here are the use cases that have motivated my specific proposal for supporting local network access in the WARP spec (see http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0173.html for details). 1. A developer wishes to write widgets that can connect to the web API exposed by a network-connected television or personal video recorder (aka digital video recorder) on their home network. This API allows (for example) the channel being viewed to be changed or the list of scheduled recordings to be modified, via a user interface presented by the widget. 2. A developer wishes to write widgets that can connect to the web interface (or API) of a home network router, in order to monitor the ADSL connection state, discover the external IP address of the router's NAT function, control the forwarding of ports to internal servers, etc. 3. A developer wishes to write widgets that can connect to the WebDAV interface provided by a NAS box on a home network, for the purposes of accessing or managing the contents of the remote filesystem. 4. A developer wishes to write widgets that can access the web interface of a networked security camera on a home network, for the purposes of viewing the images it captures. 5. A developer wishes to write widgets that can access the web API of a home automation system running on their home network, for the purposes of monitoring and controlling the devices connected to it. Of these, I only have a direct professional interest in the first in the list. (Which shouldn't surprise anyone, given the organisation that I represent on this WG.) S
Re: [WARP] Use cases for local network access
On 4 Feb 2010, at 15:15, Arve Bersvendsen wrote: On Tue, 02 Feb 2010 19:09:26 +0100, Stephen Jolly wrote: >> As actioned in the 21st Jan teleconference, here are the use cases that have >> motivated my specific proposal for supporting local network access in the >> WARP spec (see >> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0173.html for >> details). >> >> 1. A developer wishes to write widgets that can connect to the web API >> exposed by a network-connected television or personal video recorder (aka >> digital video recorder) on their home network. This API allows (for >> example) the channel being viewed to be changed or the list of scheduled >> recordings to be modified, via a user interface presented by the widget. > > During this teleconference, I was asked to elaborate my position on this > topic. The advantage of creating a definition of a local network is the > following variant of the use case: > > A developer wants to write a widget that posts whatever channel the user > switches to on a network-connected TV to http://μblogging.example.com/. The > problem, with WARP as is that, since the network address of said TV is > indeterminate, the developer's only option is to allow the widget to connect > to any URL it wishes (specifying '*' in origin, or add a large (read: huge) > set of origins in order to be able to do this. Surely the same problem exists if you remove the dependency on the blogging service - ie if the widget merely wants to connect to the television? > My proposal would be to add a second attribute to the specification, a > boolean, such as origin-local, which would replace any IP address the user > agent considers to be local, link-local or even local-machine addresses. > Alternatively, should fine-grained distinction between the three, these could > alternatively be keywords in the existing origin attribute. I would be OK with a solution along those lines, although leaving the definition of "local" up to the user agent still concerns me due to the potential impact on developers and users when the same widget behaves differently on different WUAs. S
Re: [widgets] Draft Agenda for 11 February 2010 voice conf
Art,
My regrets, but due to conflicts I will be unable to attend this VC, or next
week's (assuming one is scheduled).
S
On 10 Feb 2010, at 13:29, Arthur Barstow wrote:
> Below is the draft agenda for the 11 February Widgets Voice Conference (VC).
>
> Inputs and discussion before the VC on all of the agenda topics via
> public-webapps is encouraged (as it can result in a shortened meeting).
> Please address Open and Raised Issues and Open Actions before the meeting:
>
> http://www.w3.org/2008/webapps/track/products/8
>
> Minutes from the last VC:
>
> http://www.w3.org/2010/02/04-wam-minutes.html
>
> Logistics below.
>
> -Regards, Art Barstow
>
> Agenda:
>
> 1. Review and tweak agenda
>
> 2. Announcements
>
> a. LC of XML Signatures spec published 4 Feb:
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0531.html
>
> 3. Packaging and Configuration spec
> http://dev.w3.org/2006/waf/widgets/
>
> CR Implementation Report:
> http://dev.w3.org/2006/waf/widgets/imp-report/
>
> a. Important Test Suite Updates by Marcos
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0485.html
>
> b. Action-486: Create ITS test case(s) for the P&C test suite
> http://www.w3.org/2008/webapps/track/actions/486
>
> 4. Widget Interface spec
> http://dev.w3.org/2006/waf/widgets-api/
>
> a. API - openURL security considerations by Marcos
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0501.html
>
> b. TWI: comments by Cyril
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0479.html
>
> c. window object by Cyril
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0476.html
>
> 5. Access Requests Policy (WARP) spec
> http://dev.w3.org/2006/waf/widgets-access/
>
> a. Action-490: [AB to] Work with MC, RB and Dom on creating a infrastructure
> to test the WARP spec
> http://www.w3.org/2008/webapps/track/actions/490
>
> 6. AOB
>
> a. Charter renewal - please send comments to public-webapps:
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0493.html
>
> Comments from Scott Wilson:
> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0525.html
>
>
> Logistics:
>
> Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston;
> 06:00 Seattle
> Duration: 90 minutes max
> Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152
> PIN: 9231 ("WAF1");
> IRC: channel = #wam; irc://irc.w3.org:6665 ;
> http://cgi.w3.org/member-bin/irc/irc.cgi
> Confidentiality of minutes: Public
>
>
>
