Re: [discovery] Chromium intent to implement of Network Service Discovery

On Mon, Aug 5, 2013 at 11:13 PM, Dominique Hazael-Massieux <dom@w3.org> wrote:
> Just a quick note of a noted interest in implementing Network Service
> Discovery in Blink/Chromium:
> https://groups.google.com/a/chromium.org/forum/#!
> searchin/blink-dev/network$20service
> $20discovery/blink-dev/HT0KZKuTLxM/S3w-SdvjZfUJ
>
> Note that some concerns (in particular wrt security) are raised as part
> of the declaration of intent.

I have been following that discussion for the past few days as I'm
also subscribed to that list. We should discuss issues raised against
the specification on this W3C list where possible so I will direct my
feedback here for now.

While some of the security concerns raised in [1] may be valid it
cannot be said that the security vulnerabilities highlighted apply
only to UPnP-based APIs or that they are uniquely to be found in that
environment. There are plenty of instances where, for example, Web
APIs have been compromised and/or used maliciously in the past [2] [3]
[4].

What the current Network Service Discovery API design actually gives
us is _more_ control over API access and security than standard API
interactions have previously provided on the web. Each networked
service is required, by design, to advertise a particular identifier
on its current network. If we know that common identifier then we can,
in principle, exert more control on usage of particular HTTP APIs by
e.g. blacklisting/restricting certain identifiers and, thus, removing
access to their corresponding API. There may be candidates for a
services blacklist from the start (e.g. Access Point APIs) but such
blacklisted services could be established on a case-by-case basis and
that list could be updated quickly and at any time without affecting
the myriad other ways this API can be used. In short, we have access
to a very reliable mechanism here that gives us fine-grained control
on what we do and do not allow web pages to connect and communicate
to.

Regarding the request to implement UPnP services directly in browsers,
It is precisely because XHR focuses only on the transport layer that
we have been able to innovate and send e.g. JSON and binary data over
it at a later time. That same principle is extended to locally
networked services that can be improved and innovated upon over time.
XML may not the best format to manipulate on the web but it is still
perfectly valid along with any other text or binary based format we
have today or could invent in the future.

So I want to stress the importance of not blunting this API from the
start - neither implementing more of any particular networking stack
than is absolutely necessary nor unduly restricting access to many
potentially useful HTTP APIs at the expense of a few wild ones. We
have some fine-grained checks and controls at our disposal here and
if/when we come across service-specific issues we should not need to
throw the baby out with the bathwater.

br/ Rich

[1] <https://groups.google.com/a/chromium.org/d/msg/blink-dev/HT0KZKuTLxM/DG9jOw6WzwoJ>
[2] <http://jeremiahgrossman.blogspot.ae/2006/01/advanced-web-attack-techniques-using.html>
[3] <http://vnhacker.blogspot.ae/2009/09/flickrs-api-signature-forgery.html>
[4] <http://hackademix.net/2009/01/13/you-dont-know-what-my-twitter-leaks/>

Received on Monday, 5 August 2013 16:35:21 UTC