- From: <bugzilla@jessica.w3.org>
- Date: Sun, 11 Nov 2012 19:03:55 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19582 --- Comment #16 from Ian 'Hixie' Hickson <ian@hixie.ch> --- (In reply to comment #14) > Scenario 1: "home" > > CoAP sensors and actuators are typically domestic appliances, light bulbs, > meters, etc. > Both the browser and the proxy are behind the home gateway, thus no > ACL/NAT/firewall prevents browser from interacting with the the HTTP-CoAP > proxy. So how is the user going to get this proxy? How is the user going to get the proxy set up as a handler for the coap: protocol? How will sites be restricted from communicating with this coap: protocol handler without the user's permission? > Scenario 2: "city" > > CoAP sensors and actuators are smog/temperature/etc. detectors scattered in > the city territory. > > HTTP-CoAP proxy is in the public internet and can be freely contacted by any > browser. What Web pages are going to be using coap: URLs instead of just communicating with the proxy directly? Consider a case of a user with a laptop in charge of two cities, each with its own set of devices and a proxy. When the user goes to the page for one city, he has to select a different proxy than when he goes to the page for the other city? That seems highly unusable. Wouldn't it be better for those pages just to hardcode their link to the proxies? (In reply to comment #15) > This is a good first step to get CoAP support into the browser. Ian, we had > a discussion via e-mail a few months ago and one main problem that came up > was the security model. With this approach, security is handled by the > cross-proxy and the browser does not introduce new vulnerabilities. That isn't clear to me at _all_. If anything, it seems to make it _easier_ for hostile sites to do damage, since they can just attempt to communicate with coap: resources and the user will have taken care of providing a proxy! > I do have a question, however, what this protocol handler will cover, as I > can only find information about links. Will it also work in other elements > such as iframes or forms? What about the XMLHttpRequest object? > These things would be needed to actually mash things up. In principle these could work for any situation, provided CORS headers are sent. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 11 November 2012 19:03:56 UTC