Re: NSD API security

On Fri, Sep 20, 2013 at 7:19 PM, FABLET Youenn
<Youenn.Fablet@crf.canon.fr> wrote:
> 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.

Well, you *can* and I've seen it done but you need to guess the users
local network addressing system and then scan over all address. Or
exhaustively scan over the most common subnets (not to mention doing
alternative port scans). However you do this it is very slow and it is
more than a little imprecise. Network Discovery is precisely to avoid
this hack.

> If a local device enables  '*' CORS, a web page can already interact with it.

We will need to figure out if a network service is advertising CORS
support in its discovery messages. For UPnP/DIAL that can be handled
by looking for a 'Access-Control-Allow-Origin: *' HTTP header in the
SSDP discovery process. For Zeroconf we need to discuss the
appropriate solution a bit further.

Other than that, the API itself does not need to change much to enable
CORS. Instead of 'imitating' CORS support in network services (as we
do in the current specification) we only propagate actual CORS-enabled
services to web pages. XHR itself handles all CORS processing at the
messaging level of the API (since we hand-off to XHR, Web Sockets, etc
at the messaging level).

br/ Rich

>         Y
>
>> -----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 10:29:15 UTC