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:37:02 +1000
Message-ID: <CAAsrAZDCk4z-Rwr1krZm2pOs=CE8Hj0GTj-_SsXQbhzoOd61Dg@mail.gmail.com>
To: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
Cc: Dominique Hazael-Massieux <dom@w3.org>, 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>
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

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