RE: NSD API security

Hi,

Generally speaking, mixing the two layers (access and discovery) is apparently not optimal in terms of UI. It also reduces the scope of the NSD API.
By splitting the two layers, non HTTP services (for which whitelisting does not make a lot of sense) could be in scope of the NSD API.

Automatic whitelisting is also one solution amongst several that enable access to a given HTTP service.
Some alternatives:
1.
CORS can be used to distinguish legacy devices that may be at risk from new devices that would handle that risk properly.
The user will only have to agree that the web app does service discovery (NSD call time or install time).
2.
A packaged web app may request XHR whitelisting at install time.
The user will then have to agree to that (install time).
The user will also have to agree that the web app does service discovery (NSD call time or install time).
This agreement process may be more intuitive/understandable to the user.
3.
Signed scripts/Extensions can be used to provide a convenient way for web apps to interact with any service of a particular UPnP/MDNS type.
These signed scripts would request greater privileges (typically the ability to do any cross-site XHR or to send/receive any TCP/UDP packet) at install time.
Since they implement the message generation internally, a web app can no longer craft evil HTTP requests.
If a security bug is found, fixing these scripts will be quicker than fixing local services.
To achieve the same whitelist security level as currently described in the NSD API, the scripts could also be made to refuse sending requests to a service for a web app that did not go through the NSD API to discover it.

Regards,
 Youenn

> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
> Sent: jeudi 19 septembre 2013 14:02
> To: FABLET Youenn
> Cc: public-device-apis@w3.org
> Subject: Re: NSD API security
> 
> Hi,
> 
> Le jeudi 19 septembre 2013 à 09:00 +0000, FABLET Youenn a écrit :
> > 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.
> > [...]
> 
> Thanks for the very good summary.
> 
> > 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?
> 
> While I am in general sympathetic to the idea of reducing scope to broaden
> adoption and reduce development time, I'm sure what a pure discovery API
> would be useful for without the ability to communicate with the discovered
> services. Could you maybe detail a bit more what you have in mind here?
> 
> Thanks,
> 
> Dom
> 
> >
> > [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/

> >
> >
> >
> >
>

Received on Thursday, 19 September 2013 14:18:05 UTC