- From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
- Date: Tue, 9 Sep 2014 17:38:06 +0200
- To: 'Rich Tibbett' <richt@opera.com>
- CC: Device APIs Working Group <public-device-apis@w3.org>
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