NSD API security

In case the WG is not aware, implementation of the NSD API was discussed on various browser engine mailing lists ([1], [2], [3]).
Interesting feedback related to security issues was brought up.

First, fingerprint issues were raised.
These issues may probably be solved by user permission requests and/or data exposure minimization.
Second, a granted local service is exposed to receiving and processing any kind of data from a given web page.
Local services are often weak in terms of security (not regularly patched for instance, [4]).
This may enable new hacking possibilities through tweaked HTTP requests (XML/SOAP payloads or arbitrary data e.g.).
Solving both kinds of issues through a single user permission UI was perceived as too complex and error-prone.

>From what I know, research has been done on identifying issues related to protocols and implementations like SSDP.
Since the browser engine is handling the discovery part, the NSD API spec is probably safe there.

I do not know much about the possibilities on hacking through tweaked HTTP requests.
This potential threat, especially for legacy devices, weakens the idea of whitelisting granted local services.
Also, getting access to a discovered local service can already be done using existing approaches:

-          packaged web applications/extensions may get permissions to do cross-origin requests

-          CORS may be implemented in future local network services

The discovery part of the NSD API specification seems already in a pretty good shape.
The access granting part of the NSD API specification may take more time to mature.
Given all of that, would it make sense to split the NSD API specification in two documents?

Regards,
                Youenn

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HT0KZKuTLxM
[2] http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg23727.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=914579
[4] http://www.upnp-hacks.org/