Intent to Implement: Network Service Discovery

[Justin Lin]

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-discovery-api-support-in-opera/

[Eric Seidel]

The idea of exposing this to the web seems fine to me. The API seems
more complicated that I had expected, but I guess it's not any more
complicated than Mac's:
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNetService_Class/Reference/Reference.html

lgtm.

[Elliott Sprehn]

This API needs to use Promises instead of callback pairs.

On Wed, Jul 31, 2013 at 5:12 PM, Justin Lin <just...@chromium.org> wrote:

[Adam Barth]

There are a bunch of other web platform idioms in the IDL that should be fixed (e.g., PERMISSION_DENIED_ERR should be a DOMString rather than an integer error code).

(I haven't looked at the details yet.)

Adam

[Justin Lin]

Thanks. Actually, there is a more updated spec using promises here:

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

The first link has not been updated yet.

2013/7/31 Adam Barth <aba...@chromium.org>

[John Mellor]

Have we done a security review on this? The API allows webpages to perform essentially arbitrary communication with TVs, routers, printers, webcams, etc on your LAN, most of which will have ancient insecure drivers, or won't ever have been hardened, since the manufacturers implicitly trusted other devices on your LAN (more than the public internet).

The spec talks about requiring "user authorization", but I struggle to see how we could explain to users the subtleties of making sure all devices on their LAN are up to date and suitably hardened.

Whitelisting devices is probably impractical, given the spec's very generic use cases. But we should consider requiring devices to opt-in to being accessible from the public web, rather like on Android we only enable WebGL on GPUs that implement the GL_ARB_robustness extension.

(The spec is also unusually low-level, and most usages require lots of ugly XML boilerplate according to whatever proprietary schema the specific device you are talking to has chosen; this doesn't feel very "webby". Many of the spec's use cases could be fulfilled by cleaner higher-level APIs, though they obviously wouldn't be as general purpose...)

[mark a. foltz]

On Fri, Aug 2, 2013 at 6:03 AM, John Mellor <joh...@chromium.org> wrote:

Have we done a security review on this? The API allows webpages to perform essentially arbitrary communication with TVs, routers, printers, webcams, etc on your LAN, most of which will have ancient insecure drivers, or won't ever have been hardened, since the manufacturers implicitly trusted other devices on your LAN (more than the public internet).

I don't believe arbitrary network communication is possible, only methods supported through existing protocols (http://, ws://, ftp://, ...) 

We will of course review this with the Chrome security and privacy teams before anything is released.

The spec talks about requiring "user authorization", but I struggle to see how we could explain to users the subtleties of making sure all devices on their LAN are up to date and suitably hardened.

The user messaging will be very important to get right.  I also want to address showing the authorization request in terms the user can understand, instead of (or in addition to) low-level uPnP or mDNS service names. 

 

Whitelisting devices is probably impractical, given the spec's very generic use cases. But we should consider requiring devices to opt-in to being accessible from the public web, rather like on Android we only enable WebGL on GPUs that implement the GL_ARB_robustness extension.

That's an idea to consider.  As the update cycle for many of these devices is on the longer side, very few devices would be available to the API.

 

(The spec is also unusually low-level, and most usages require lots of ugly XML boilerplate according to whatever proprietary schema the specific device you are talking to has chosen; this doesn't feel very "webby". Many of the spec's use cases could be fulfilled by cleaner higher-level APIs, though they obviously wouldn't be as general purpose...)

Yeah...XML...

I think the spec is correctly focused on the discovery piece, leaving most of the Web-to-device protocol details to higher level libraries.  I believe this will help when extending the API with additional types of discovery down the road.

I also hope that newer iterations of devices will move to more "webby" protocols like JSON-over-WebSocket, which should be pretty lightweight to use on top of a discovery API.

m.

[Eric Seidel]

It's also not clear that one needs to write this in Blink. From
Blink's perspective this is a tiny amount of code, you're just
exposing some additional events/apis.

One could easily do this from an extension with plugin to get the
necessary HTTP privileges.

I'm not sure being off in a plugin is necessarily the end goal for
such code. But it might allow you to iterate very quickly and prove
the idea?

Even if this is in Blink, I expect it would live in the Modules
directory and mostly be a wrapper around Platform calls up into
Chromium's network stack.

On Wed, Jul 31, 2013 at 5:12 PM, Justin Lin <just...@chromium.org> wrote:

[Mark Scott]

That's actually exactly what we did - there's a chrome.dial API that provides the necessary low level access (to SSDP/UDP multicast), with much of the logic being built at an extension level.  We used this to build a DIAL implementation at an extension level.

However, while we do expose certain APIs from the extension, it's not an approach that scales well to enabling a broad array of sites across the web, and that's why we're now going down this path.

Mark.

[Torne (Richard Coles)]

On 2 August 2013 21:09, mark a. foltz <mfo...@google.com> wrote:

On Fri, Aug 2, 2013 at 6:03 AM, John Mellor <joh...@chromium.org> wrote:

Have we done a security review on this? The API allows webpages to perform essentially arbitrary communication with TVs, routers, printers, webcams, etc on your LAN, most of which will have ancient insecure drivers, or won't ever have been hardened, since the manufacturers implicitly trusted other devices on your LAN (more than the public internet).

I don't believe arbitrary network communication is possible, only methods supported through existing protocols (http://, ws://, ftp://, ...) 

We will of course review this with the Chrome security and privacy teams before anything is released.

This is effectively granting cross-origin permissions for whatever the user says the page can connect to, right? There have been a lot of reports about these kinds of devices being highly insecure lately, e.g.:

https://securityledger.com/2013/08/samsung-smart-tv-like-a-web-app-riddled-with-vulnerabilities/

http://news.cnet.com/8301-1009_3-57596851-83/wi-fi-routers-more-security-risks-than-ever/

http://securityevaluators.com/content/case-studies/routers/soho_service_hacks.jsp

(there were also talks on this at Black Hat last week I think?)

There are lots of multifunction router devices these days that are the user's primary network route and firewall, but also a UPnP/SMB/etc media server - the exact kind of service web pages are most likely to want to discover. If you can buffer-overrun the discovered media service you probably immediately become root on the router (they may not bother with any privilege separation at all) and are able to reconfigure the user's network as you please: changing their DNS settings would be a great start for a lot of malware :/

 

The spec talks about requiring "user authorization", but I struggle to see how we could explain to users the subtleties of making sure all devices on their LAN are up to date and suitably hardened.

The user messaging will be very important to get right.  I also want to address showing the authorization request in terms the user can understand, instead of (or in addition to) low-level uPnP or mDNS service names. 

That's all very well, but in the attack I suggest above, the request may well be 100% reasonable sounding to the user no matter how you describe it: "AwesomeMusicPlayer.com wants to access media files on mymediabox".

 

Whitelisting devices is probably impractical, given the spec's very generic use cases. But we should consider requiring devices to opt-in to being accessible from the public web, rather like on Android we only enable WebGL on GPUs that implement the GL_ARB_robustness extension.

That's an idea to consider.  As the update cycle for many of these devices is on the longer side, very few devices would be available to the API.

This seems much more sane. In fact, for HTTP-based services you could just use CORS headers?

 

 

(The spec is also unusually low-level, and most usages require lots of ugly XML boilerplate according to whatever proprietary schema the specific device you are talking to has chosen; this doesn't feel very "webby". Many of the spec's use cases could be fulfilled by cleaner higher-level APIs, though they obviously wouldn't be as general purpose...)

Yeah...XML...

I think the spec is correctly focused on the discovery piece, leaving most of the Web-to-device protocol details to higher level libraries.  I believe this will help when extending the API with additional types of discovery down the road.

If the browser implemented the actual UPnP/etc protocol itself rather than allowing the web page to craft its own payloads, then it would probably be much harder to exploit the devices..

[Adam Barth]

Thanks, that version is much better than the TR version.  :)

I've now reviewed this feature in more detail and have the following concerns:

1) This API clearly has security and privacy implications, but the specification doesn't have a security or a privacy considerations section.  You might have thought through the security and privacy considerations, but it's difficult for me to evaluate them without these sections in the specifications.  In this thread, you mention that you'll get a security review from the security team before enabling the feature by default, but I would feel more comfortable if we gave more consideration to privacy and security ahead of time.  Specifically, I would like to see the following two things happen before we start implementing the specification:

  a) Some feedback from the security and privacy teams about whether they're comfortable exposing this API to the web.  We don't need to do a complete review ahead of implementing, but I think this feature would benefit from an up-front "gut check" with these folks.

  b) The specification should include security and privacy considerations sections that explain the security and privacy risks associated with the feature and what user agents should do to mitigate these risks.  For example, John Mellor mentioned that some of these devices might have old, vulnerable drivers.  Mark Foltz claimed that wasn't a problem, but that sort of issue should be discussed in the spec's security considerations section so that we don't need to have this same discussion every time someone new reads the spec.

2) The requirements in the garbage collection section seem quite onerous and unlikely to be correct.  There area a number of problems with these requirements:

  a) The specification states that a certain object must not be garbage collected until the user navigates away from a particular origin.  Chrome uses a multiprocess architecture in which a given origin might be present in multiple processes.  If we implemented this requirement, we might need to keep a process alive just to avoid garbage collecting this object if the user happened to be viewing another page from the object's origin in another process.  Even if this requirement were scoped to a given process, this requirement would still cause use to keep the object alive much longer that reasonable, effectively leaking resources.

  b) The specification requires that we garbage collect certain objects at the same time that we garbage collect certain other objects.  It's not clear to me what the author of that requirement intended, but, as written, the requirement is problematic:

    i) The requirement mandates a finalizer for the NetworkService objects that can change a web-visible property from true to false, giving scripts the ability to detect when garbage collection occurs.  We've carefully avoided giving scripts this visibility into the internal details of the garbage collector to avoid having to mimic garbage collector quirks across user agents.

    ii) It's not clear what behavior the user agent is required to exhibit if script keeps a reference to a NetworkService object but does not keep a reference to the corresponding NetworkServices object.  Perhaps the requirement would better be phrased as forbidding collection of the NetworkServices object in this situation rather than mandating the garbage collection of the NetworkService object?  As written, this requirement would leave script with a reference to an object that had already been garbage collected, violating a basic invariant of the garbage collector.

3) According to chromestatus.com, we've received no public signals from Safari, Firefox, or Internet Explorer about this feature.  We probably need to socialize this feature a bit more before we plunge ahead with an implementation.  In particular, I wouldn't be surprised if one or more of these vendors had opinions about this feature that we haven't yet heard expressed and therefore haven't been able to consider.

For these reasons, I don't think we should start implementing this feature yet.

Adam

[mark a. foltz]

Adam,

Thanks for your feedback.  (I'm working with Justin on this.)  I'll summarize our response and plan.

(1) Agreed that a longer discussion of the security and privacy implications of the API is warranted.  Rich posted a section to the spec [1] that is a good starting point; I plan on working with the editors on minimizing the opportunities for harm, and minimizing the ability to fingerprint users of the API, which was brought up by the Chrome privacy team.

(2) Rich posted an update to the spec to address the language around garbage collection.

https://dvcs.w3.org/hg/dap/diff/b4b2569b4e9b/discovery-api/Overview.src.html

(3) I reviewed the last several months of list traffic and, to my ability to scan, haven't seen comments or commitment from other browser vendors.  I'll let Rich fill in if there are any updates here.  I think an effort to evangelize and get additional participation will be helpful to the spec as a whole.

Given the current set of feedback, we plan on working with the spec editors and coming back when we feel it is ready to implement.

m.

[Adam Barth]

On Fri, Aug 16, 2013 at 2:55 PM, mark a. foltz <mfo...@google.com> wrote:

Adam,

Thanks for your feedback.  (I'm working with Justin on this.)  I'll summarize our response and plan.

(1) Agreed that a longer discussion of the security and privacy implications of the API is warranted.  Rich posted a section to the spec [1] that is a good starting point; I plan on working with the editors on minimizing the opportunities for harm, and minimizing the ability to fingerprint users of the API, which was brought up by the Chrome privacy team.

The requirements in that section sound like good goals, but it's not entirely clear to me what the risks of implementing this API are.  For example, Maciej raised the question of whether this API provides access to vulnerable services that would otherwise be protected by the browser's same-origin policy:

http://www.mail-archive.com/webki...@lists.webkit.org/msg23756.html

I haven't studied the API in enough detail to understand whether this concern is warranted.  These are the sorts of issues that are important to understand about the feature.

(2) Rich posted an update to the spec to address the language around garbage collection.

https://dvcs.w3.org/hg/dap/diff/b4b2569b4e9b/discovery-api/Overview.src.html

There are a few more details we'll need to clean up there, but I have a much better understanding of what the spec author intends.

 

(3) I reviewed the last several months of list traffic and, to my ability to scan, haven't seen comments or commitment from other browser vendors.  I'll let Rich fill in if there are any updates here.  I think an effort to evangelize and get additional participation will be helpful to the spec as a whole.

There's been a discussion about this specification on the webkit-dev mailing list:

http://www.mail-archive.com/webki...@lists.webkit.org/msg23727.html

Folks from Apple seem pretty negative about the security implications of this feature.  We don't need to get every last browser vendor on board to ship a feature (for example, we shipped WebGL even though Microsoft was opposed initially), but building consensus among implementors is important so that this feature doesn't end up being Chrome-only.

Given the current set of feedback, we plan on working with the spec editors and coming back when we feel it is ready to implement.

More than polishing the specification, my sense is what we need to do to make progress here is to build consensus among implementors.  Given that Apple appears to be opposed to the feature, are there other implementors who are interested in implementing the feature?

Adam

[Torne (Richard Coles)]

On 9 September 2013 17:51, Adam Barth <aba...@chromium.org> wrote:

On Fri, Aug 16, 2013 at 2:55 PM, mark a. foltz <mfo...@google.com> wrote:

Adam,

Thanks for your feedback.  (I'm working with Justin on this.)  I'll summarize our response and plan.

(1) Agreed that a longer discussion of the security and privacy implications of the API is warranted.  Rich posted a section to the spec [1] that is a good starting point; I plan on working with the editors on minimizing the opportunities for harm, and minimizing the ability to fingerprint users of the API, which was brought up by the Chrome privacy team.

The requirements in that section sound like good goals, but it's not entirely clear to me what the risks of implementing this API are.  For example, Maciej raised the question of whether this API provides access to vulnerable services that would otherwise be protected by the browser's same-origin policy:

http://www.mail-archive.com/webki...@lists.webkit.org/msg23756.html

I haven't studied the API in enough detail to understand whether this concern is warranted.  These are the sorts of issues that are important to understand about the feature.

I'm very concerned about the security implications of this and don't think it's possible to secure this API simply with a permissions dialog. As I understand, the following would be allowed:

1) Webpage asks for access to DLNA/UPnP media streaming services to play music.

2) Browser scans for suitable services, presents me with a list, one of which is the same physical device as my wifi AP and router.

3) I select the router, because it's serving the music I want to play.

4) Webpage now has cross-origin permission to make requests to the HTTP streaming server on the router.

5) Webpage sends malicious HTTP payload that exploits a bug in the streaming service to execute arbitrary commands on the device.

6) Webpage reconfigures my router's network settings however it feels like, e.g. changing DNS so that every client on my network gets sent to some ad network, or similar. (there's lots of DNS-redirecting malware in the wild, including some that attempts to log into routers using default passwords or exploits to reconfigure the DNS network-wide).

This doesn't require stepping outside the security model in the spec: the webpage only needs access to the specific, appropriate-for-purpose origin that the user manually approved. There are lots of multifunction routers that have UPnP media streaming capabilities (and torrent clients, and bulk downloaders, and many other potentially exploitable network services), and they don't have a great track record for being patched promptly (or in many cases ever) when they have security holes.

The only way I can think of to close off this kind of attack is to have the browser implement the actual protocol to communicate with the device as well as the discovery protocol, and only expose task-specific interfaces (e.g. information about what specific media is available to be streamed, or the actual stream of audio/video data).

Treating the user's acceptance of a discovery prompt as blanket permission for the webpage to send arbitrary data to the device (even if it's restricted to "HTTP on a specific port" or similar) is exposing a large number of devices that are not really designed with security in mind to new sources of attack.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[gius...@opera.com]

Hi,

as you may know the DAP group is also discussing these issues (partially also triggered by this thread TBH). Some relevant threads are [1] and [2]

If you can find some time to join that discussion that could help to speed up changes to the spec to address the security aspects while still enabling web apps to discover and talk to other web apps or services running on other devices.

[1] http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0029.html

[2] http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0000.html

[fjhi...@gmail.com]

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/htmldiff?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	file | diff | annotate
Rich Tibbett	Fix minor respec link bugs and other minor editorials	file | diff | annotate
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	file | diff | annotate
Rich Tibbett	Add CORS as the primary network service opt-in mechanism for the NSD API specification	file | diff | annotate
Rich Tibbett	Fix [DAP-ISSUE-147]: Reference 'Requirements for Home Networking Scenarios' in Introduction	file | diff | annotate
Rich Tibbett	Fix [DAP-ISSUE-134]: Rename NetworkServices and NetworkService events	file | diff | annotate
Rich Tibbett	Replace numeric error codes with string-based error types and fold the NavigatorNetworkServiceError interface in to DOMError (therefore, removing NavigatorNetworkServiceError from spec)	file | diff | annotate
Rich Tibbett	Fix [DAP-ISSUE-136]: Issues related to garbage collection	file | diff | annotate
Rich Tibbett	Fix [DAP-ISSUE-135]: Add security and privacy considerations section [Network Service Discovery]	file | diff | annotate
Rich Tibbett	Fix minor typo in NSD API spec examples	file | diff | annotate
Rich Tibbett	Change getNetworkServices API + associated algorithms to use DOM Promises

[Kenneth Rohde Christiansen]

cc'ing Rick Tibett to the thread, as this is probably interesting to him.

I find it a bit weird how the spec uses promises, so Rick should probably look at https://github.com/w3ctag/promises-guide

Cheers

Kenneth

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆﹆﹆

[Rich Tibbett]

On Thu, Feb 20, 2014 at 11:26 PM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

cc'ing Rick Tibett to the thread, as this is probably interesting to him.

I find it a bit weird how the spec uses promises, so Rick should probably look at https://github.com/w3ctag/promises-guide

Do you have specific feedback on this aspect of the spec? We did ask for and obtain review on the use of Promises when it was initially added to this spec [1] [2]. 

If there are any changes you want to see here just let us know. Presumably the best place for that kind of discussion would be over on the W3C DAP list [3].

On Thu, Feb 20, 2014 at 11:10 PM, <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/htmldiff?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 

This update is particularly targeted toward resolving concerns previously raised on this thread. It would be interesting to hear from others whether we now have an implementable proposal or whether some concerns still need to be addressed before we can proceed.

br/ Rich

[1] http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0150.html

[2] http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0073.html

[3] http://lists.w3.org/Archives/Public/public-device-apis/

[Torne (Richard Coles)]

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.

[jor...@missingdesign.com]

Is this something that is on the roadmap for Blink in the near future?

Thanks!

[mark a. foltz]

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.

[red...@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 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

[youenn fablet]

2014-11-08 1:03 GMT+01:00 <red...@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?

CORS check is a good step forward.
The NSD API as it stands may still disclose the IP range of the local
network, at least when interacting with existing UPnP services.
This may help an attacker optimize the attacks made on local services:
no new attacks but potentially faster...
Fingerprinting is another issue that was brought up, probably more
relevant in case of "no user prompt".

> I'm interested in a standardization of this proposal and have put together a 2-page doc 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.

I will take a look at your doc.
Here are a few thoughts:
- Asking a user to select a finite number of services greater than one
may be difficult. It may be easier to go with "please select one"
and/or "please give me all I can talk to" approaches.
- "Please select one" NSD scenarios may be covered through potentially
small modifications to the presentation API. You may be interested in
the work presented at W3C TPAC (see
http://lists.w3.org/Archives/Public/public-webscreens/2014Nov/0001.html
for instance).

Regards,
y

[Rich Tibbett]

On Mon, Nov 10, 2014 at 9:56 AM, youenn fablet <you...@gmail.com> wrote:
> 2014-11-08 1:03 GMT+01:00 <red...@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?
>
> CORS check is a good step forward.
> The NSD API as it stands may still disclose the IP range of the local
> network, at least when interacting with existing UPnP services.
> This may help an attacker optimize the attacks made on local services:
> no new attacks but potentially faster...

There are two schools of thought on this.

The first is that we should relay requests through an opaque proxy,
thereby obfuscating service URLs presented to web pages. That could be
somewhat brittle since subsequent HTTP/WebSocket communication to that
URL could expose this IP address information at a later time but there
may be some significant benefits to having initial service URL
obfuscation in the NSD API.

The second school of thought is that since sharing occurs after the
user has already opted in - or after pre-established trust has
otherwise been established through e.g. the newly proposed
'Access-Control-Allow-Transparent-Discovery-Origin' CORS header - then
the exposing of the local network address of a device is a natural
part of that elevated permission. FWIW, the WebRTC API currently
exposes local IP addresses without any user opt-in (see
http://net.ipcalf.com) and native applications have this capability
implicitly also. If this is an issue for NSD then it makes sense that
we also need a similar solution for WebRTC.

> Fingerprinting is another issue that was brought up, probably more
> relevant in case of "no user prompt".
>
>> I'm interested in a standardization of this proposal and have put together a 2-page doc 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.
>
> I will take a look at your doc.
> Here are a few thoughts:
> - Asking a user to select a finite number of services greater than one
> may be difficult. It may be easier to go with "please select one"
> and/or "please give me all I can talk to" approaches.
> - "Please select one" NSD scenarios may be covered through potentially
> small modifications to the presentation API. You may be interested in
> the work presented at W3C TPAC (see
> http://lists.w3.org/Archives/Public/public-webscreens/2014Nov/0001.html
> for instance).

I don't think the Presentation API and the Network Service Discovery
API need to be considered mutually exclusive to each other. They solve
different use cases for the web IMO.

It will be interesting to see what the Second Screen WG proposes for
communication with non-second screen devices but that feels like
shoehorning additional use cases in to the (deliberately
tightly-scoped) Presentation API.

br/ Rich

>
> Regards,
> y

[youenn fablet]

> The second school of thought is that since sharing occurs after the
> user has already opted in - or after pre-established trust has
> otherwise been established through e.g. the newly proposed
> 'Access-Control-Allow-Transparent-Discovery-Origin' CORS header - then
> the exposing of the local network address of a device is a natural
> part of that elevated permission. FWIW, the WebRTC API currently
> exposes local IP addresses without any user opt-in (see
> http://net.ipcalf.com) and native applications have this capability
> implicitly also. If this is an issue for NSD then it makes sense that
> we also need a similar solution for WebRTC.

Was not aware of this, thanks for the link, does not seem to work in
my environment though.
Local services should be as secure as open web services, but
currently, we are far from there...

>>> I'm interested in a standardization of this proposal and have put together a 2-page doc 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.
>>
>> I will take a look at your doc.
>> Here are a few thoughts:
>> - Asking a user to select a finite number of services greater than one
>> may be difficult. It may be easier to go with "please select one"
>> and/or "please give me all I can talk to" approaches.
>> - "Please select one" NSD scenarios may be covered through potentially
>> small modifications to the presentation API. You may be interested in
>> the work presented at W3C TPAC (see
>> http://lists.w3.org/Archives/Public/public-webscreens/2014Nov/0001.html
>> for instance).
>
> I don't think the Presentation API and the Network Service Discovery
> API need to be considered mutually exclusive to each other. They solve
> different use cases for the web IMO.

Agreed.
NSD fits well in the "please give me all services I can talk to"
scenarios, no pop-up.
Having as a starter a much simplified version of NSD (no
multi-queries, no UPnP events, no onavailable/onunavailable, no
service description...) would be good.

The other interesting area related to sensors/WOT would be how
browsers could let current APIs (geolocation, gum...) be fulfilled
using dynamically discovered sensors.
I guess everything is delegated to the OS now.

[Kostiainen, Anssi]

> On 10 Nov 2014, at 12:16, Rich Tibbett <ri...@opera.com> wrote:
>
> It will be interesting to see what the Second Screen WG proposes for
> communication with non-second screen devices but that feels like
> shoehorning additional use cases in to the (deliberately
> tightly-scoped) Presentation API.

With regard to the Presentation API scoping:

Currently, the window-less (or non-second screen) use case is out of scope for the Working Group [1]. The group discussed this at chartering time, and concluded more experimentation is needed.

That said, the use case is a potential work item for the Community Group [2] to be incubated pre-standards track.

Thanks,

-Anssi (with WG Chair hat on)

[1] http://www.w3.org/2014/secondscreen/
[2] http://www.w3.org/community/webscreens/