- From: Rich Tibbett <richt@opera.com>
- Date: Tue, 6 Aug 2013 02:34:52 +1000
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
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