[nickbw]

Actually I really appreciate Weis' comments, because they're actual concrete problems and implementable solutions. (A bit-flipping attack is not particularly interesting by itself, since the server can inject gibberish any time it wants anyway, unless it can be used to insert meaningful content. But I will be happy to add both a MAC and a better nonce.)

What I don't understand is why you think any unaudited code is secure. There is no mechanism by which code from an unknown source becomes trustworthy without someone reading it, or being able to read it.

Nowhere am I suggesting that understanding the javascript source is quick or easy, but it is in fact possible, which is the difference between encrypting client-to-server vs. client-to-client. Source code you can view is not automatically trustworthy. Of course not. But it is easier to trust than code you will never be allowed to see. Can we at least agree on that much?

As far as trustworthiness, I would say: local code > remote code run on the client > remote code run on the server > closed source. This makes (a theoretically fatal-bug-free) bonchat-like system worse than PGP, but better than Facebook IM.

It sounds like your real complaint is with the "marketing", such as it is. Perhaps I should do a better job labeling it as experimental, or a proof of concept? These would be actual concrete criticisms.

Folks complaining of XSS vulnerabilities seem to be under the mistaken impression that it somehow secures you against the people you're talking to, which is not the problem it's trying to solve. Unescaped HTML chat is vulnerable to XSS, which is why you shouldn't exchange raw HTML with random strangers. You wouldn't open an HTML attachment from a stranger, but you'd open one from your good web developer friend.

(A very fair complaint is that, although XSS is irrelevant to the intended use, I should've anticipated that people would want to test/demo the basic chat features by broadly distributing passwords. This turns it into, essentially, a plain text chat with two URLs you have to enter. Which is useless, but perhaps amusing, so I've added default HTML escaping.)

[tptacek]

Nick, "bit flipping attacks" imply that attackers can make messages say whatever they want to. They do not simply mean attackers can inject "random gibberish".

Furthermore, your nonce problem doesn't mean attackers can inject messages; it means attackers can cryptanalyze messages.

It would be helpful, before trying to implement cryptographic security for other people, for you to spend some time researching cryptography. A great way to do that is to learn how to attack cryptosystems in other applications. Maybe that should be your next project.

Best of luck, Nick.

[nickbw]

I appreciate your concern, Thomas, but you seem to be telling me that:

1. no one will be able to gauge the integrity of a web app by reviewing the code, and

2. I should fix the security problems sweis found by reviewing the code.

I wholeheartedly agree with #2 (and I'm working on it now), but it rather contradicts #1.

I threw this thing together because I'm a long-time open source fan and I've been watching as more and more code people entrust their privacy to moves behind the opaque border of the web app cloud. I'd like to find ways to deal with that.

Bug reports are interesting and useful, and I'm extremely grateful for them. My implementation is flawed, no doubt in ways beyond the ones sweis has already pointed out, and discovering those flaws is one reason I posted it somewhere like HN.

But simply declaring that javascript is an unsuitable language for encryption, or that web clients are an unsuitable environment, doesn't add anything factual. I think code transparency is a boon to security, and I would like more web apps to at least try to make their security reviewable, even if reviewing is a job for experts. If you don't think that code transparency adds anything useful, well, fair enough. I respectfully disagree.