Re: NSD API security

On Fri, Sep 20, 2013 at 8:28 PM, Rich Tibbett <richt@opera.com> wrote:
> 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

Just to be clear here, I saw it done once from a trusted browser
extension. On a web page you are restricted by same-origin policy so a
scan from there is a no-go.

> 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:37:29 UTC