Comet Breakthrough: Socket for JavaScript in the Browser(cometdaily.com)
cometdaily.com
Comet Breakthrough: Socket for JavaScript in the Browser
http://cometdaily.com/2008/07/01/sockets-in-the-browser/
6 comments
Misleading title. Not a breakthrough, no new technology, just a different way of explaining it.
Can't stand crap like this. People who reinvent the wheel (poorly), or try to, make the world a worse place... something related to 'visualization' -- psychological stuff. People who fail to visualize and truely, intimately understand things will often invent breakthrough technology as JavaScript 'sockets.'
Hi,
Many of the comments here are negative, probably due to the overly sensational title ;-) Since this is a project I have been working on, however, I will do my best to clarify and respond candidly.
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
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
This isn't new technology, but its a more reasonable way of thinking about real-time communication in a browser. Developers know how to use sockets, so we give them a socket.
In a years time this will be native in all browsers anyway: http://www.whatwg.org/specs/web-apps/current-work/#network
In a years time this will be native in all browsers anyway: http://www.whatwg.org/specs/web-apps/current-work/#network
I wonder if this could be combined with this javascript jabber library to make a fully fledged chat client:
http://zeank.in-berlin.de/jsjac/
.. 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?
.. 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?
I think it proxies through a server, it is not a real socket.
this is exactly what it is doing. it's a javascript lib that exposes an ajax connection (fancifully named "TCPSocket") that is proxying a socket connection through the Orbitd server. if there isn't strict control of client IP addresses and outgoing IP/port at Orbitd, then you should expect folks are going to abuse/hack your server for proxying who knows what from where.
This is going to be a giant security nightmare.
This seems to be the instinctive response of developers in other areas when exposed to a new client-server system...particularly a proxy or relaying system.
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.
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.
This is a bit different to normal applications though.
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.)
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.)
Your average web programmer doesn't even check for SQL injection or XSS attacks. Your average web programmer though, likes to adopt new technologies because of some "buzz." Your average web programmer will read the basic tutorial, which will cover examples, which are not to be used in a production environment. However these examples will make their way into production environments and we'll see a bunch of attacks pop up. I hope I'm wrong, but we'll have to wait and see..
My guess would be that they use nested iFrames. It would be similar to the Google Data APIs.
Ok, neat, but this has ridiculous security implications. Anyone can now open up a socket on my server for any purpose they want (hax0ring, etc)
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.
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.
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."