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 14:26:56 +0000
To: Rich Tibbett <richt@opera.com>
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>
Message-ID: <ACC41E833067BD4FB8084DEBA2D866BE2F52ADA4@ADELE.crf.canon.fr>
> >> 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.

A partial scan is theoretically feasible from a web page.
Most local network services store image/icon resources, some of which have highly predictable URL paths.
The hit/miss ratio is of course lower than with a browser extension.

> > 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.

More than agreed :)

> > 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.

I am not sure what you would do with that information.
Limit NSD API exposure of network services to the ones that support CORS?
Add it into NetworkService JS objects? Something else?

Browsers or/and web apps will anyway learn service CORS support when trying to send HTTP requests.
Why not leaving the handling to them?

> > 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).

Additional study may show a potential for improving CORS in that context but this should work as is.

Received on Friday, 20 September 2013 14:27:45 UTC

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