RE: [discovery] Network Service Discovery: current status

Hi Rich,

See inline below.

BR
  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 9 september 2014 13:26
> To: Nilsson, Claes1
> Cc: Device APIs Working Group
> Subject: Re: [discovery] Network Service Discovery: current status
> 
> Hi Claes,
> 
> On Tue, Sep 9, 2014 at 8:27 AM, Nilsson, Claes1
> <Claes1.Nilsson@sonymobile.com> wrote:
> > 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.
> 
> We have been addressing these issues in the NSD API specification. We
> have simply mandated that the same network-level security mechanisms be
> in place in line with other client-side HTTP-based web communication
> mechanisms (e.g. XHR). That is to say, we have not prescribed any
> fundamentally new restrictions on HTTP-level communication here but are
> enforcing web security best practices.
> 
> >
> > 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.
> 
> I'm curious. Are there additional benefits of the Presentation API
> compared to exposing 'Screen Sharing' buttons in a web browser's chrome
> (for screen/tab/url sharing/streaming) and in audio/video element
> controls (for audio/video content sharing/streaming)? This is how e.g.
> AirPlay works today and it also happens to intuitively solve how we
> obtain user permission to stream content to second screens.

[Claes] Yes, as I state above, either the browser itself or APIs exposed to web apps can expose common high level services. So the browser itself can provide a feature to show content on another screen (for example Chromecast tab sharing). I guess that, when reading the Presentation API report, http://www.w3.org/2014/secondscreen/presentation-api/20140721/, that an API allowing web applications to use an external screen gives more flexibility and supports common use cases in a simple way. 

> 
> Furthermore, I think there's a lot of undefined magic going on in the
> current Presentation API draft. Will all browsers support the same
> second screen technologies? How does the proposed Web Messaging
> interoperate across local networks?

[Claes] I hope that members of the Second Screen CG could answer this but I assume that browsers will use existing technology to attach second screens (HDMI, Chromecast, DLNA, AirPlay or similar).

> 
> >
> > 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?
> 
> This very much ties in to principles behind the Extensible Web
> Manifesto where the priority is on exposing the right device/network
> primitives to web developers (aka: the right low-level APIs). The right
> primitive for network-based communication from the web is HTTP.
> Giving developers higher-level communication controls would mean none
> of the provided examples in the NSD specification could be used:
> https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-

> api/Overview.html#examples.
> In summary there is an implicit loss of freedom in defining and
> exposing higher-level APIs where lower-level APIs not only exist but
> also happen to be a better network communication abstraction point.
> 
> With higher-level APIs you will not be able to build web apps to e.g.
> obtain networked media library contents or allow remote control of
> devices to e.g. change channels or adjust volume or interactively view
> with the contents of your fridge or control your home thermostat or
> lighting. HTTP paths would enable those types of web applications,
> allow browser makers to maintain a smaller API footprint in
> implementations and push the onus of local-networked service innovation
> back from browser makers to web developers. With higher-level APIs we
> will be relying on browser makers to implement our particular local-
> network back-ends for years to come.
> 
> If we had taken this high-level approach to network-based communication
> before in the web platform instead of providing robust HTTP primitives
> like XMLHttpRequest then the web would be a lot more restrictive than
> is the situation today. That same principle applies here.

[Claes]These are relevant comments. However, to go further with "Web of Things" we probably need a layer focused on the services that networked devices support. At the recent Web of Things workshop in Berlin, http://www.w3.org/2014/02/wot/report.html, there were for example discussions around high level approaches like JSON-based service descriptions and mapping of JavaScript APIs to HTTP REST APIs.   

But once again, I don't have a very strong opinion on NSD, I am rather observing what is going on in the web community and what seems to get momentum.

> 
> Best regards,
> 
> Rich
> 
> >
> > 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 15:38:35 UTC