RE: NSD API security

Defining a good blacklist/whitelist may not be an easy task.
Such a list may evolve over time, there is no guarantee that different implementations of the same service type be all safe, a single device may implement both a safe type and an unsafe type...

Legacy devices can already be accessed by packaged apps and browser extensions without whitelisting.
Existing services (AV content storage, renderers, printers...) may already be useful to existing packaged apps (music players, image managers...).
What is missing is the discovery part. This may trigger early NSD API market adoption.
Enabled features would be translated to web pages once CORS become implemented in devices, using exactly the same code base.

Early adopters of the NSD API for web apps may resort on browser extensions to access discovered legacy devices, be they HTTP or not.
Some experiments (https://github.com/youennf/nsdExperiments) showed the feasibility of “bridge” extensions that would either validate-then-send or generate-then-send requests on behalf of a web app (more study needed on security aspects though).
The web app code adaptation needed to access both CORS-enabled and legacy devices is for instance fairly low.
Resorting on extensions is probably not that appealing to web developers, but this may still be a viable transition approach.

A single version of the NSD API should make possible these different approaches.
Starting from the current specification, that would probably mean removing the whitelisting mechanism.
Probably also keeping user permission to cover fingerprinting issues.

Regards,
 Youenn

> -----Original Message-----
> From: HU, BIN [mailto:bh526r@att.com]
> Sent: vendredi 27 septembre 2013 00:28
> To: Rich Tibbett; Dominique Hazael-Massieux
> Cc: Giuseppe Pascale; FABLET Youenn; public-device-apis@w3.org; public-
> web-and-tv
> Subject: RE: NSD API security
> 
> At AT&T side, we support Rich and Dom's proposal of supporting both CORS
> as the primary mode and whitelisting for legacy devices.
> 
> While CORS approach will be good for implementers to start with from now
> on, current legacy devices on market cannot be ignored. If we don't support
> legacy devices, I am not sure if market eventually will adopt NSD with CORS
> only approach, or the market will be fragmented.
> 
> Thus CORS + whitelisting approach is more reasonable to keep the market
> support.
> 
> Thanks
> Bin
> 
> -----Original Message-----
> From: Rich Tibbett [mailto:richt@opera.com]
> Sent: Friday, September 20, 2013 3:44 AM
> To: Dominique Hazael-Massieux
> Cc: Giuseppe Pascale; FABLET Youenn; public-device-apis@w3.org; public-
> web-and-tv
> Subject: Re: NSD API security
> 
> On Fri, Sep 20, 2013 at 6:18 PM, Dominique Hazael-Massieux
> <dom@w3.org> wrote:
> > Le vendredi 20 septembre 2013 à 17:28 +1000, Rich Tibbett a écrit :
> >> So there are a number of directions we could take this in:
> >>
> >> 1. Focus the specification around a CORS-only solution. CORS is an
> >> accepted mechanism to allow cross-origin communication on the web
> and
> >> could work well in the local network environment also. The problem
> >> with adopting a CORS-only approach is we have zero devices currently
> >> ready to step in to this brave new world with us. A specification
> >> that allows you to connect with precisely zero network services will
> >> not be useful.
> >
> > I think that no matter what, the spec should support a CORS-based
> > approach.
> 
> A CORS approach only? As I said, there are no services I'm aware of that
> would work with that today so we would also have to see if device vendors
> are interested in releasing CORS-based devices and services. I know we have
> a few device vendors on this list so it would be good to hear their opinions at
> this point.
> 
> >
> >> 2. Support whitelisting of specific local network services in the
> >> user agent, at the user's request to enable communication with those
> >> services. Even if we went with a CORS-only approach (see (1.) above),
> >> this could be a practical fallback to support existing/legacy network
> >> services. This would provide non-CORS-enabled services with the same
> >> privileges as CORS-enabled services from the user agent without the
> >> service itself needing to support CORS implicitly (as also proposed
> >> in the current NSD API specification).
> >
> > I support the idea (at least in theory — it would remain to be seen
> > whether any user agent would feel confident to support such a
> > whitelist); but given that this is an exception mechanism, I'm not
> > even sure it needs to be specified —  since the user agent is
> > ultimately responsible for managing the same origin policy,
> > user-specified exceptions to that policy (which such a whitelist would
> > be) seem beyond what we need to define for interoperability. Or did
> > you have in mind some specific aspects that would need to be spec-d here?
> 
> It may warrant a note in the spec to say that a user agent MAY whitelist non-
> CORS-enabled network services and that if it does so it MUST pass through
> XHR/WebSocket messages to the network service endpoints as if they were
> CORS enabled.
> 
> Other than that, I don't anticipate any other issues with interoperability.
> 
> >
> > Dom
> >

Received on Tuesday, 1 October 2013 07:10:04 UTC