Re: [discovery] improving the acceptability of the NSD API

On Tue, Oct 8, 2013 at 4:10 AM, Jean-Claude Dufourd <
jean-claude.dufourd@telecom-paristech.fr> wrote:

>  Dear all,
>
> Re-reading the security issues brought to this list by Youenn,
> I wonder if we should drastically tighten up the security of the NSD API.
> Can we not just _remove_ the fields url and config from the NetworkService
> interface ?
> This way, the discovering web app would have no direct route to the
> discovered
> services: it would have only a handle that is useless for fingerprinting
> or hacking.
> One additional field would be a blob for the service description, if any.
>
> Then, to allow communication between the discovering web app and the
> discovered
> service, the NSD implementation would offer an _indirect_ communication
> channel(s).
>

This is an interesting idea and I explored it thoroughly before proposing
the initial NSD API to this group.

If we were inventing a new sharing protocol and starting from scratch this
would probably be my preferred approach. However...


> One possibility for the indirect communication channel could be Ajax-like,
> another
> could be WebSocket-like, another could be using UPnP messaging
> (HTTP+SOAP...)
>

...this is a non-trivial problem: there is no abstraction (other than URLs)
that is capable of conveniently incorporating all of these concepts well.

The more you design this kind of abstract interface the more you realize
you need the ability to e.g. set HTTP request headers (for e.g. UPnP) and
read HTTP response headers (again for UPnP) and also allow flexibility in
messaging channel types and format types for different types of services.

What this approach introduces is the need to define some black magic that
converts abstracted API comms interfaces in to the HTTP messaging,
WebSocket messaging or any other type of messaging that each device speaks.
The implementation also needs to know what to do with each API interaction
according to the network service the page is interacting with (does it need
to be translated in the HTTP+SOAP, WebSockets, HTTP+ProtocolBuffers,
HTTP+Custom XML, etc?).

The more you explore this idea and design an abstract API you come to
realize that URLs provide the most suitable abstraction point. URLs are the
entry point for a lot of other communication-based APIs currently available
in the web platform (XHR, WebSockets, SSE, etc). A lot of prior work has
happened in designing network communication-based APIs and we should not
have to discard that huge body of prior work here.


> What I mean is the API offered by NSD would replace, in the original API,
> any URL or IP
> with the handle, and if necessary remove any address from returned
> information.
> I have already implemented the last (UPnP-style messaging), have created
> various
> examples and never needed to provide to the web apps any direct link to
> the services.
>
> It would be quite a powerful argument against NSD detractors that the url
> or IP of the service is never shared with the web app,
>

This would be a good thing and it is something we do need to explore
further in the current NSD API spec also. That doesn't mean we need to
throw out URLs altogether. We may want to use a custom URL scheme that
abstracts away IP-based communication. That is of course very non-trivial
but may be worth looking - achieving the same benefits of obfuscating IP
addresses as you present here.


> > and that all communication
> passes through/can be checked by the NSD implementation.
>

Sound like asking for the user agent to perform black magic to me. What
exact checks did you have in mind here?

br/ Rich