- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Thu, 19 Sep 2013 17:18:06 +0200
- To: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
- Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>, public-web-and-tv <public-web-and-tv@w3.org>
Youenn, thanks for starting this thread, I had similar plans but never got around it. I'm including the webandtv list in CC, since the requirements for this spec originated from that group (and we are still discussing similar topics). I hope members of the IG can also join this conversation Let me share some of my thoughts: On Thu, Sep 19, 2013 at 11:00 AM, FABLET Youenn <Youenn.Fablet@crf.canon.fr> wrote: >In case the WG is not aware, implementation of the NSD API was discussed on various browser engine mailing lists ([1], [2], [3]). >Interesting feedback related to security issues was brought up. I'm wondering if we should try to bring all interested people on this list so that we have this discussion in one place. Maybe I should drop a link to this thread on those lists? [...] > Second, a granted local service is exposed to receiving and processing any > kind of data from a given web page. > > Local services are often weak in terms of security (not regularly patched > for instance, [4]). > > This may enable new hacking possibilities through tweaked HTTP requests > (XML/SOAP payloads or arbitrary data e.g.). > > Solving both kinds of issues through a single user permission UI was > perceived as too complex and error-prone. > > This issue was raised already 2 years ago when this spec was presented to the DAP group for the first time, and I actually tend to agree with those concerns. I suspect we need to consider "dropping" the "support for legacy devices" requirement, at list when this API is used in a normal web browser, i.e. in absence of a security model that can guarantee that the API is not abused. What we could consider is to provide a way for services to "opt-in" for being exposed to web apps. Opting-in would mean that only devices/services designed and implemented with this use case in mind will be exposed. >I do not know much about the possibilities on hacking through tweaked HTTP requests. >This potential threat, especially for legacy devices, weakens the idea of whitelisting granted local services. >Also, getting access to a discovered local service can already be done using existing approaches: > > - packaged web applications/extensions may get permissions to do > cross-origin requests > > - CORS may be implemented in future local network services > > The whitelisting was defined in order to support legacy devices. If people believe that supporting legacy devices (in normal conditions) is too risky anyway, we can probably drop the whitelisting feature and go for CORS. In other words, if you need to change your service in order to opt-in for being exposed, you can also change it to support CORS. > > The discovery part of the NSD API specification seems already in a pretty > good shape. > > The access granting part of the NSD API specification may take more time to > mature. > > Given all of that, would it make sense to split the NSD API specification in > two documents? > What I personally think it could make sense is to try and define a "secure" version of the full spec, that "loose" the requirement for supporting legacy devices and instead assume that discovery protocols and services need to be (slightly) changed to opt-in for this feature. >From there it should be easy to imagine an extension that people can use in other scenarios where they want to support also legacy protocols and they are able to secure the user home network via some other means). BTW assuming we still want to have an api that works across multiple discovery protocols, this group would have to liaise with the groups in charge of standardizing such discovery protocols in order to agree on a way for services to opt-in for this API. /g > > [1] > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HT0KZKuTLxM > > [2] http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg23727.html > > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=914579 > > [4] http://www.upnp-hacks.org/ > >
Received on Thursday, 19 September 2013 15:18:57 UTC