RE: [discovery] Network Service Discovery: current status

Hi Rich,

At first I would like to say that this is good stuff and I understand that there is a lot of work behind this API. I am sorry that I have not been more active in reviewing and commenting the specification. The use cases for this API are very relevant but as you state below the security issues have been the main concern.

I do not currently have a very strong opinion but if we look at alternatives I can see two possible approaches, one low level and one high level:

1. Low level UDP API. I am editing the SysApps TCP and UDP API, http://www.w3.org/2012/sysapps/tcp-udp-sockets/, that for example can be used to implement UPnP or mDNS local network service discovery in JavaScript, either directly by a web app needing it or in a Javascript library. However, the main assumption is of course that this API can only be exposed to "trusted web apps", for example according to models like FFOS privileged/certified web apps or Chrome web apps. Or maybe to a model as proposed in our work with FFOS trusted hosted web apps, http://lists.w3.org/Archives/Public/public-sysapps/2014Sep/0000.html. 

2. A high level approach allowing the browser/web apps to use specific services in the local network. 

There is an earlier input on this mailing list along these lines: http://lists.w3.org/Archives/Public/public-web-and-tv/2014Apr/0054.html.  

Examples of this approach is the browser printing a web page on a LAN printer and the Presentation API proposal, http://www.w3.org/2014/secondscreen/presentation-api/20140721/, to enable web content to access external presentation-type displays and use them for presenting web content. 

With this approach we target only specific well-defined services in the network but maybe we could find a more general model that still is high level and secure. The target must be to hide low level protocol details and details of local devices in the user's network and only expose APIs to high level services?

Best regards
  Claes


Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nilsson@sonymobile.com

sonymobile.com




> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: den 4 september 2014 14:13
> To: Device APIs Working Group
> Subject: [discovery] Network Service Discovery: current status
> 
> Responding to feedback from the Web and TV IG [1] we began drafting a
> Network Service Discovery API proposal [2] within this group. Today we
> have two prototype implementations [3] [4] and tentative Intent to
> Implement approval within Chromium [5].
> 
> The strongest API concerns have related to the security of sharing
> existing UPnP, Zeroconf and DIAL services with web pages. We have since
> added additional features to the NSD API proposal to mitigate these
> issues: requiring network-based services to 'opt-in' to web sharing by
> implementing appropriate CORS headers before they can be shared with
> web pages. Additionally we have left open the ability for implementers
> and/or users to 'whitelist' their own network services for web sharing
> at their own request. In such whitelisting, implementations would then
> simulate the cross-origin resource sharing as if CORS were supported
> natively in the whitelisted network-based service itself.
> 
> An additional concern related to the permissions required to obtain
> access to network services discovered via this API. The NSD API
> proposal requires that users actively select the services that a web
> page can interact with through a runtime permission dialog. A web page
> will request a well-known network service type and then the UA (when it
> is aware or can discover matching services on the local network via the
> CORS/whitelisting checks described above) would provide the user a
> dialog to share access to selected network services with the requesting
> web page.
> 
> We previously prototyped this API within Opera [4] and we then had to
> put this work on hold while we switched engines from Presto to Blink.
> We are now considering whether we want to implement this API in current
> Opera browsers given the use cases we have that could benefit from the
> availability of a _generic_ network-service discovery interface.
> 
> So feedback from group participants - both implementers and developers
> - would be welcome on the following questions:
> 
> 1. Is generic network service discovery and communications
> bootstrapping important for the web?
> 
> 2. Does this group want to continue working on a generic network
> service discovery and communications bootstrap mechanism?
> 
> 3. Does this group want to continue working on this against the current
> API proposal [2]?
> 
> 4. Have we reasonably addressed the above security concerns for the
> current API proposal [2]?
> 
> 5. Does anyone have additional plans and/or a roadmap to share relating
> to this feature?
> 
> Looking forward to feedback.
> 
> Best regards,
> 
> Rich
> 
> [1] http://www.w3.org/TR/hnreq/

> 
> [2] https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html

> 
> [3] http://jcdufourd.wp.mines-telecom.fr/2013/05/15/network-service-

> discovery-api/
> 
> [4] https://dev.opera.com/articles/network-service-discovery-api/

> 
> [5] https://groups.google.com/a/chromium.org/d/msg/blink-

> dev/HT0KZKuTLxM/IC4bUbmOmYcJ

Received on Tuesday, 9 September 2014 06:28:07 UTC