Nick. Please. It doesn't do this thing you keep claiming it does, because you left out any mechanism for the client to verify the code the server sends. You keep implying, directly and indirectly, that clients can do this by hand. People keep telling you, no they can't. When I give a specific and unintuitive reason why people can't manually verify your code in a browser, you throw out a smokescreen about how Javascript is a fine language to write things in, which of course has nothing to do with the issue at hand.

(By the way, thing you don't want to hear from the guy offering you super-secure communication system? "You have a superstitious paranoia about Javascript".)

And, as Steve Weis took the time to point out, even if you had invented some new system by which browsers could verify the state of a Javascript interpreter fed by an app that, among other things, had until a few hours ago a bunch of obvious Javascript injection flaws, you still wouldn't have been secure, because you don't really understand how CTR mode works and implemented colliding nonces. (Why did you bother with CTR mode anyways?) You also don't seem to understand the relation between encryption and authentication; not having a MAC would just be an embarassing oversight if you hadn't then argued with Weis about why it wasn't necessary.

The security model behind this application is just a really bad idea, Nick. I know that's tough to hear, since you obviously put some time and effort into it, but you're going to need to zag instead of zig now and come up with something cool about this chat system other than the notion that it's somehow more secure than Campfire or any other https chat.