While I agree with most of the article, in light of recent events (blanket surveillance, Heartbleed), an argument could very well be made in favour of using JS crypto -- not by itself, but in addition to TLS.
> The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography.
Scenario 1: You run a note-storing service as described in the article. Your site is delivered through TLS, using one of the non-DHE ciphersuites. You used your CA's web interface to generate the certificate and private key, because it's simpler than generating your own CSR. An NSL with an attached gag order requires your CA to submit all generated RSA private keys to the NSA and shut up about it.
Without JavaScript crypto, the NSA is able to passively decrypt each connection and collect all of the notes' contents.
If you add JavaScript crypto (again, as described in the article), they need to either mount an active attack (which might get discovered) or find a flaw in the JS crypto (which is very much possible -- but adds work).
Scenario 2: You run any site with a login prompt. You are using OpenSSL.
Without JavaScript crypto: during a brief window of two years or so, attackers may be able to exploit Heartbleed and read unencrypted passwords that were submitted by users.
If you add JavaScript crypto, attackers may be able to exploit Heartbleed and read HMAC-digests of recently submitted user passwords. Other sensitive data might, of course, still be disclosed.
> The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography.
Scenario 1: You run a note-storing service as described in the article. Your site is delivered through TLS, using one of the non-DHE ciphersuites. You used your CA's web interface to generate the certificate and private key, because it's simpler than generating your own CSR. An NSL with an attached gag order requires your CA to submit all generated RSA private keys to the NSA and shut up about it.
Without JavaScript crypto, the NSA is able to passively decrypt each connection and collect all of the notes' contents.
If you add JavaScript crypto (again, as described in the article), they need to either mount an active attack (which might get discovered) or find a flaw in the JS crypto (which is very much possible -- but adds work).
Scenario 2: You run any site with a login prompt. You are using OpenSSL.
Without JavaScript crypto: during a brief window of two years or so, attackers may be able to exploit Heartbleed and read unencrypted passwords that were submitted by users.
If you add JavaScript crypto, attackers may be able to exploit Heartbleed and read HMAC-digests of recently submitted user passwords. Other sensitive data might, of course, still be disclosed.