Renewed interest in Network Service Discovery spec

Hi,
there is a new post about the NSD spec on blink-dev list (see also quote
below)
https://groups.google.com/a/chromium.org/d/msg/blink-dev/HT0KZKuTLxM/K46Z7HMsq9YJ

Since our group have been the one promoting the spec in the first place and
we have discussed it again during TPAC, people may be interested in
contributing to the discussion on blink-dev

/g


---------- Forwarded message ----------
From: <reddaly@google.com>
Date: Sat, Nov 8, 2014 at 1:03 AM
Subject: Re: [blink-dev] Re: Intent to Implement: Network Service Discovery
To: blink-dev@chromium.org
Cc: jordan@missingdesign.com, fjhirsch@gmail.com, markdavidscott@google.com,
mfoltz@google.com


My read of the above discussion is that the CORS check largely addresses
the earlier security concerns about vulnerable local devices being exposed
to Internet traffic.  This limits the set of discoverable devices, but that
should be acceptable for many applications (e.g., new devices).  Are there
other outstanding issues people would like resolved?

I'm interested in a standardization of this proposal and have put together
a 2-page doc
<https://docs.google.com/document/d/1-DfCjJZZOhPMsbvQDH-LGAQvw_TRNcs8ERuRVQms0ik/edit>
motivating
a new push.  It would be great to get feedback from blink-dev members as a
first step before taking the discussion to other lists.  You may add
comments to the Google doc if you wish.

Thanks,
Red

On Thursday, October 23, 2014 11:57:20 AM UTC-7, mark a. foltz wrote:
>
> Jordan,
>
> Not at this time (as far as I know).    The developer who started this
> thread no longer seems to be a member of the Chromium project.  My team has
> shifted focus to the Presentation API as it is a better fit for the
> multiscreen scenarios that we support.
>
> m.
>
>
> On Wed, Jul 9, 2014 at 3:11 PM, <jor...@missingdesign.com> wrote:
>
>> Is this something that is on the roadmap for Blink in the near future?
>>
>> Thanks!
>>
>> On Friday, February 21, 2014 5:23:04 AM UTC-8, Torne (Richard Coles)
>> wrote:
>>>
>>> Requiring explicit CORS behaviour as specified in the new version is
>>> probably sufficient to address the concerns I had in the previous
>>> discussions on blink-dev. It's still possible that many UPNP-type devices
>>> will have poor implementations of their services that aren't really secure,
>>> but at least if they have to opt in then the huge number of existing
>>> devices with known-bad code are not exposed.
>>>
>>> I'd still prefer it if we didn't expose the discovered services directly
>>> at all, requiring that the browser implement the service-specific protocol,
>>> to make it harder for websites to construct malicious payloads, but I
>>> understand that this is likely to make this feature much more difficult to
>>> actually get any real-world benefit from (since people invent new protocols
>>> all the time and requiring that we go through a web standards process to
>>> define a protocol-specific JS API every time is going to make this feature
>>> far less attractive), so I think CORS is a reasonable compromise.
>>>
>>>
>>> On 20 February 2014 22:10, <fjhi...@gmail.com> wrote:
>>>
>>>> The W3C DAP WG published an updated working draft of Network Service
>>>> Discovery today.
>>>>
>>>> This draft includes use of CORs, updates related to garbage collection
>>>> issues and updated security and privacy consideration sections.
>>>>
>>>> I suspect this will help address comments in this thread, and any
>>>> feedback would be welcome (preferably on DAP public list as noted in the
>>>> draft)
>>>>
>>>> see http://www.w3.org/TR/2014/WD-discovery-api-20140220/
>>>>
>>>> (the correct diff link is http://services.w3.org/html
>>>> diff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2F2013%2FWD-discovery
>>>> -api-20130924%2F&doc2=http%3A%2F%2Fwww.w3.org%2FTR%2F2014%
>>>> 2FWD-discovery-api-20140220%2F
>>>>
>>>> I hope this is helpful
>>>>
>>>> regards, Frederick
>>>>
>>>> Frederick Hirsch
>>>>
>>>> Change log is applicable since 29 March 2013), i.e.
>>>>
>>>> *Update working version to latest respec build*
>>>> <https://dvcs.w3.org/hg/dap/rev/2f37e8af951a> file
>>>> <https://dvcs.w3.org/hg/dap/file/2f37e8af951a/discovery-api/Overview.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/2f37e8af951a/discovery-api/Overview.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/2f37e8af951a/discovery-api/Overview.html> *Rich
>>>> Tibbett* *Fix minor respec link bugs and other minor editorials*
>>>> <https://dvcs.w3.org/hg/dap/rev/608edb43c84d> file
>>>> <https://dvcs.w3.org/hg/dap/file/608edb43c84d/discovery-api/Overview.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/608edb43c84d/discovery-api/Overview.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/608edb43c84d/discovery-api/Overview.html> *Rich
>>>> Tibbett* *[discovery-api] Re-write CORS-related parts of the spec
>>>> following subsequent feedback on
>>>> http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0049.html*
>>>> <https://dvcs.w3.org/hg/dap/rev/140b6c8d4c18> file
>>>> <https://dvcs.w3.org/hg/dap/file/140b6c8d4c18/discovery-api/Overview.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/140b6c8d4c18/discovery-api/Overview.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/140b6c8d4c18/discovery-api/Overview.html> *Rich
>>>> Tibbett* *Add CORS as the primary network service opt-in mechanism for
>>>> the NSD API specification*
>>>> <https://dvcs.w3.org/hg/dap/rev/f3ea6558ffe1> file
>>>> <https://dvcs.w3.org/hg/dap/file/f3ea6558ffe1/discovery-api/Overview.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/f3ea6558ffe1/discovery-api/Overview.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/f3ea6558ffe1/discovery-api/Overview.html> *Rich
>>>> Tibbett* *Fix [DAP-ISSUE-147]: Reference 'Requirements for Home
>>>> Networking Scenarios' in Introduction*
>>>> <https://dvcs.w3.org/hg/dap/rev/07345c55f11f> file
>>>> <https://dvcs.w3.org/hg/dap/file/07345c55f11f/discovery-api/Overview.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/07345c55f11f/discovery-api/Overview.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/07345c55f11f/discovery-api/Overview.html> *Rich
>>>> Tibbett* *Fix [DAP-ISSUE-134]: Rename NetworkServices and
>>>> NetworkService events* <https://dvcs.w3.org/hg/dap/rev/865b6f93faac>
>>>> file
>>>> <https://dvcs.w3.org/hg/dap/file/865b6f93faac/discovery-api/Overview.src.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/865b6f93faac/discovery-api/Overview.src.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/865b6f93faac/discovery-api/Overview.src.html> *Rich
>>>> Tibbett* *Replace numeric error codes with string-based error types
>>>> and fold the NavigatorNetworkServiceError interface in to DOMError
>>>> (therefore, removing NavigatorNetworkServiceError from spec)*
>>>> <https://dvcs.w3.org/hg/dap/rev/5e36d90b8960> file
>>>> <https://dvcs.w3.org/hg/dap/file/5e36d90b8960/discovery-api/Overview.src.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/5e36d90b8960/discovery-api/Overview.src.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/5e36d90b8960/discovery-api/Overview.src.html> *Rich
>>>> Tibbett* *Fix [DAP-ISSUE-136]: Issues related to garbage collection*
>>>> <https://dvcs.w3.org/hg/dap/rev/b4b2569b4e9b> file
>>>> <https://dvcs.w3.org/hg/dap/file/b4b2569b4e9b/discovery-api/Overview.src.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/b4b2569b4e9b/discovery-api/Overview.src.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/b4b2569b4e9b/discovery-api/Overview.src.html> *Rich
>>>> Tibbett* *Fix [DAP-ISSUE-135]: Add security and privacy considerations
>>>> section [Network Service Discovery]*
>>>> <https://dvcs.w3.org/hg/dap/rev/fcbaadc4fd54> file
>>>> <https://dvcs.w3.org/hg/dap/file/fcbaadc4fd54/discovery-api/Overview.src.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/fcbaadc4fd54/discovery-api/Overview.src.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/fcbaadc4fd54/discovery-api/Overview.src.html> *Rich
>>>> Tibbett* *Fix minor typo in NSD API spec examples*
>>>> <https://dvcs.w3.org/hg/dap/rev/d66ca00fe7d9> file
>>>> <https://dvcs.w3.org/hg/dap/file/d66ca00fe7d9/discovery-api/Overview.src.html>
>>>>  | diff
>>>> <https://dvcs.w3.org/hg/dap/diff/d66ca00fe7d9/discovery-api/Overview.src.html>
>>>>  | annotate
>>>> <https://dvcs.w3.org/hg/dap/annotate/d66ca00fe7d9/discovery-api/Overview.src.html> *Rich
>>>> Tibbett* *Change getNetworkServices API + associated algorithms to use
>>>> DOM Promises* <https://dvcs.w3.org/hg/dap/rev/d25229263a68>
>>>>
>>>>
>>>>
>>>>
>>>> On Wednesday, July 31, 2013 8:12:35 PM UTC-4, Justin Lin wrote:
>>>>>
>>>>> Contact emails
>>>>>
>>>>> mfo...@chromium.org just...@chromium.org markdav...@google.com
>>>>>
>>>>> Spec
>>>>>
>>>>> http://www.w3.org/TR/discovery-api/
>>>>>
>>>>> Summary
>>>>>
>>>>> The NSD API will allow discovering HTTP-based services advertised on
>>>>> the local network. Use of the API will require an explicit user permission
>>>>> grant. NSD can support more than one underlying discovery protocol (i.e.
>>>>> mDNS, SSDP, DIAL).
>>>>>
>>>>> Motivation
>>>>>
>>>>> There is currently no unified way for the web platform to discover
>>>>> local HTTP-based services. This will allow querying the network for
>>>>> available services from nearby devices. This will allow web pages to find
>>>>> and interact in a peer-to-peer fashion with local services.
>>>>>
>>>>> Compatibility Risk
>>>>>
>>>>> None at this point. There is an experimental implementation for Opera
>>>>> [1].
>>>>>
>>>>> Ongoing technical constraints
>>>>>
>>>>> None
>>>>>
>>>>> Will this feature be supported on all five Blink platforms (Windows,
>>>>> Mac, Linux, Chrome OS and Android)?
>>>>>
>>>>> Yes
>>>>>
>>>>> OWP launch tracking bug?
>>>>>
>>>>> http://crbug.com/164472
>>>>>
>>>>> Row on feature dashboard?
>>>>>
>>>>> Yes, row 146.
>>>>>
>>>>>
>>>>> Requesting approval to ship?
>>>>>
>>>>> No
>>>>>
>>>>> [1]: http://dev.opera.com/articles/view/network-service-disc
>>>>> overy-api-support-in-opera/
>>>>>
>>>>
>>>
>