Comet Breakthrough: Socket for JavaScript in the Browser
cometdaily.com
cometdaily.com
Has anyone seen code that manages to multiplex a single connection of this type across multiple tabs within a browser? Is that even possible?
From: http://www.orbited.org/wiki/CherryChat
"Then point your browser at http://localhost:4700/static/chat.html, and then open a second browser window and point it at http://127.0.0.1:4700/static/chat.html, and test the application. It’s important to use the two different hostnames localhost and 127.0.0.1 because some browsers limit the number of open connections you can have to each hostname to two. With this limit it is impossible to run two instances of the chat application on the same host. Of course, 127.0.0.1 and localhost should refer to the same local machine, so its a good way of tricking the browser into thinking its talking to separate servers."
This is clearly not a breakthrough. Sockets (or socket-like interfaces) are the most obvious way to communicate a bi-directional stream of bytes. This has been true for decades. The problem is that everybody has been trying to reinvent the wheel for AJAX. So yes, this is not new, just something that had been missing from the web for a long time!
We have been very mindful of the security implications. Orbited uses a strict whitelist and will not allow outgoing connections to addresses (hostname:port) that are not listed in the access configuration.
Feel free to ask me any questions.
-Frank Salim
In a years time this will be native in all browsers anyway: http://www.whatwg.org/specs/web-apps/current-work/#network
.. currently that library is restricted by the same domain policy. I wonder how this Comet library manages to get around it.
Anyone here care to explain?
But is BIND and the DNS system a "security nightmare"? Is Squid a security nightmare? Apache's mod_proxy, a security nightmare? Postfix or Sendmail or Qmail or Exim, all security nightmares? IRC? OK, maybe SMTP and IRC are security nightmares...but, one could easily argue that it's because their goals include "many-to-many open communication", and not because securing them would be difficult. After all, IMAP/POP3 moves mail around, just like SMTP, and it manages to be locked up nice and tight without even trying very hard.
I'm not saying Orbited isn't a security nightmare. I'm just saying that it's a client-server proxying and/or relaying system, just like all of the systems listed above, and that does not, by definition, make it a security nightmare. If the developers have experience building proxy systems and/or take the time to understand the security requirements of such a system, it'll be just fine. Just because securing a particular technology is sorta hard, doesn't mean you shouldn't build the technology. It just means you need to allocate some of your development resources to solving those security problems.
Normal apps: Developer writes application. Code is installed via user engagement with a package management or installation system.
Comet apps: Developer writes application. Code is pulled and executed by (almost) every vistor to the website it is deployed on.
If the code could open sockets to arbitrary destinations then a high traffic site could be used to spawn a very effective DDOS or distribute hacking attempt.
Of course for Orbited this isn't relevant as the browser security model limits connections to the originating host. So you can't, say, embed javascript into Slashdot.org that does:
End users >>> DDOS attack target.
Instead you get:
End users >>> Slashdot.org proxy >>> DDOS attack taget.
(Which is obviously a total waste of time as any attack via this method would be predicated on having control of Slashdot.org in the first place.)
At the very least there should be ways to limit the hosts and ports of the sockets, but even then I'd be very cautious about using this.