So, first it should be noted that this critique (and the original article) are from 2011. Not a lot has changed since then, but it's worth noting. Secondly, I

So, first it should be noted that this critique (and the original article) are from 2011. Not a lot has changed since then, but it's worth noting. Secondly, I'm an ex-Matasano employee and still friends with tptacek et al; just throwing my potential biases out on the table. Now, I don't agree with every single bit of the original article, but I disagree with just about every bit of this one. I'll go point by point. >> “Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request.” > This problem is simply mitigated by deploying Javascript cryptography in conjunction with HTTPS. No, it's really not mitigated by doing so. Because the crypto code is coming from the server you're attempting to prevent cleartext access to, the trust model is fundamentally broken here. The server could easily throw down JS code that does not perform proper crypto operations, leaks keys, or any number of other things. And that's not even speaking of XSS and other attacks making it trivial for an attacker to compromise your data. Edit (based on edited OP): > [...] it is possible to deliver web apps as signed, local browser plugins, applications and extensions. This greatly helps with solving the problem. Correct, this does mitigate some of the issue. Namely, it allows the code to be reviewed as it is in use. However, the server can still push code arbitrarily and completely compromise the crypto, and XSS is still an issue. >> “Secure delivery of Javascript to browsers is a chicken-egg problem.” > This problem, while serious, can be mitigated with the usage of browser plugins that locally verify the integrity of the Javascript code, warning the user should the code be faulty. This is correct...ish. The problem is that it still gives too much trust to the server. The proper approach would be a browser plugin that exposes a Keyczar-style, high-level interface to JS crypto and allows secure operations on data without revealing access to the server. However, this still isn't enough. Take the case of Gmail adding GPG support for emails. Let's assume you have a perfectly secure plugin such as one I described above. Even in this case, the server-driven JS still could send unencrypted data from the DOM up to the server, before crypto operations have happened. The trust boundaries are nonexistent here. >> “Javascript lacks a secure random number generator.” > While Javascript does not ship with a secure random number generator, [...] Let's just stop here. Doing a CSPRNG right is hard. Very, very hard. Thankfully, browsers are starting to implement this as part of the browser directly, making it much less likely that JS code can skew results. This should be a solved problem soon, if it isn't already. Edit (based on edited OP): They now mention the CSPRNG built into modern browsers. As mentioned, this is 99% a solved problem. >> “Javascript cryptography hasn’t implemented well-known standards such as PGP; such a high-level language can’t be trusted with cryptography.” This is one point from the original article that I think is specious. If you have the proper lego blocks, you should be able to put together things like PGP securely. But those blocks don't exist. > However, the ultimate problem with browser cryptography is that there is no standard for innate, in-browser encryption. Very much like HTML5 and CSS, there needs to be an international, vetted, audited, cross-browser standard for browsers to be capable of securely encrypting and communicating sensitive information. There’s no denying the urgent need for such a standard , considering the ridiculous rate in which the browser is becoming pretty much the mainstream central command for personal information. This I agree with. However, every approach so far has really, really, really sucked. See also: https://news.ycombinator.com/item?id=4549504 https://news.ycombinator.com/item?id=4549504 To do this properly, we need a standard for high-level crypto operations, which is incredibly hard to pull off, and we need sane trust boundaries to prevent the server from skewing operations and stealing data. I hope someone will get it right eventually. Edit: Forgot to respond to one point. >> “JavaScript’s ‘view-source transparency’ is illusory.” > It is the case in every cryptography implementation that the implementation will need to be reviewed by an expert before being declared secure. This is no different in JavaScript, C, or Python. There are a few issues here: 1) Generally speaking, the fact that JS source is pushed down on every access means that there's no way for you to actually review it. 2) Even if the crypto code is isolated and completely reviewed and found to be bulletproof, the trust boundaries are still screwed. C.f. the Gmail example above.