[bren2013]

I mean, it is secure against passive adversaries... but that's nit-picking.

ChatCrypt has made a large number of mistakes, though, I concur. They don't use HTTPS, it isn't open sourced, and the developer is practically anonymous.

I would still maintain that Matasano's article is problematic, though, because it has one of two effects on the reader:

1. The reader is more-than-well convinced on faulty basis that JS crypto should never be used.

2. The reader is still adamant on continuing their project, but is now alienated from a source that could have offered a plethora of helpful advice. (Example: "Please, for all that is good, use HTTPS.")

Of course, nothing will prevent the occasional surfacing of bad crypto, but their article certainly doesn't help any of its causes.

[tptacek]

How about, instead of arguing that readers of an article are more convinced than they should be about something you yourself appear to be convinced of, you put your money where your mouth is and formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography. Give yourself the full benefit of every facility the web programming model gives you, up to the limit of installing browser extensions (at which point you're no longer talking about content-controlled code). What's a system like this that has worked well, and would be resilient to a determined adversary?

[bren2013]

Is that a question? I don't understand the question. "Put your money where your mouth is" doesn't sound like a rebuttal.

I've no idea what you're talking about.

[niels_olson]

> I don't understand the question.

Let me break that down for you:

1) formulate an argument for a setting in which content-controlled browser Javascript is a sensible place to deploy cryptography.

1.a) Give yourself the full benefit of every facility the web programming model gives you, up to the limit of installing browser extensions.

2) What's a system like (1) that has worked well, and would be resilient to a determined adversary?

So, he's claiming to have shown that content-controlled browser javascript crypto is worse that useless because it allows good people to inadvertently leak secrets. All you have to do to prove him wrong is just tell him a use case where it would make sense and then cite an example where that worked well* and would be resilient to a determined* adversary.

So, all you have to do is say "chatcrypt.com's use case makes sense and chatcrypt rocks. Here I show that it is unbreakable until long after the stars cool, and no amount of kneecap cryptography will lessen the adversery's burden."

* He's giving you two wiggle words already, you can define them however you'd like.

[read]

He means crypto from servers can't be trusted. You need something better. You need crypto running in a browser extension.

If I understood your article correctly, when you (bren2013) refer to in-browser crypto you mean crypto code is delivered from the server. But that's not the only in-browser crypto you can get. You can also get in-browser crypto delivered from a browser extension. Under this second definition of in-browser crypto, the following sentence in the article isn't accurate:

there is nothing in-browser crypto can do to defend against active adversaries.

(I admit I didn't read the article thoroughly.)