W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2012

[Bug 19582] Add coap and coaps to the whitelist'ed scheme list

From: <bugzilla@jessica.w3.org>
Date: Sun, 11 Nov 2012 19:03:55 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-19582-2486-1Db9tnp2WU@http.www.w3.org/Bugs/Public/>

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

> 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

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 11 November 2012 19:03:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:35 UTC