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.

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

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