The Matasano post is here:
Perhaps the most objectionable thing about the Matasano article is title. Otherwise it does a very good job of criticizing a particular way of engineering web cryptography that is, for lack of a better term, total bullshit. But is the approach criticized in the Matasano post used in the real world?
Let's try an experiment! Go to google.com and type in "encrypted chat"
If your results are similar to mine, one of the top 3 results will be "chatcrypt.com". Let's read the "How It Works?" page:
> Most people thinks that if a website uses a HTTPS connection (especially with the green address bar) then their "typed-in" informations are transmitted and stored securely. This is only partially true. The transmission is encrypted well, so no third party can sniff those informations, but there is no proof that the website owners will handle them with maximum care, not mentioning that the suitable laws can enforce anyone to serve stored data for the local authorities.
Okay, so this site attempts to implement end-to-end encryption in a web browser. Except... what's the problem? Oh, it looks like chatcrypt.com isn't served over HTTPS. In fact, if we try to visit the site over HTTPS, it doesn't work at all.
Top 3 Google result for "encrypted chat"
Is the Matasano post that unreasonable? (besides the title) It pretty much describes that sort of site to a tee.
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.
I've no idea what you're talking about.
Let me break that down for you:
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, 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.
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.)