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

Re: NSD API security

From: Rich Tibbett <richt@opera.com>
Date: Fri, 20 Sep 2013 20:43:49 +1000
Message-ID: <CAAsrAZBoBpiHoys4iQyX5QVpfzXDjynH7T8=gDPyooJMdEZwWw@mail.gmail.com>
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: Giuseppe Pascale <giuseppep@opera.com>, FABLET Youenn <Youenn.Fablet@crf.canon.fr>, "public-device-apis@w3.org" <public-device-apis@w3.org>, public-web-and-tv <public-web-and-tv@w3.org>
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 Friday, 20 September 2013 10:44:16 UTC

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