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.

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?

>
> 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.

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 11:26:01 UTC