W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2013

RE: NSD API security

From: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
Date: Fri, 20 Sep 2013 09:19:38 +0000
To: Dominique Hazael-Massieux <dom@w3.org>, Rich Tibbett <richt@opera.com>
CC: Giuseppe Pascale <giuseppep@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, public-web-and-tv <public-web-and-tv@w3.org>
Message-ID: <ACC41E833067BD4FB8084DEBA2D866BE2F529A67@ADELE.crf.canon.fr>
I wonder what should be added/changed to the NSD API spec to make CORS work.
A web page can already try to scan the local network through GET requests.
If a local device enables  '*' CORS, a web page can already interact with it.

> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
> Sent: vendredi 20 septembre 2013 10:19
> To: Rich Tibbett
> Cc: Giuseppe Pascale; FABLET Youenn; public-device-apis@w3.org; public-
> web-and-tv
> Subject: Re: NSD API security
> 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.
> > 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?
> Dom

Received on Friday, 20 September 2013 09:20:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:58 UTC