> 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.
You're wrong. If a JavaScript app is structured properly, especially one delivered as a signed browser plugin, it can run completely client-side with no capability to _execute_ remote JavaScript code from a server whatsoever.
Simply executing and parsing XMLHttpRequests does not mean that the JS app is executing arbitrary code from a remote server. It may simply be parsing JSON payloads. This is completely up to whatever code is delivered as part of the browser add-on, and cannot be remotely overridden by the server.
You are correct that XSS is an issue, but as mentioned elsewhere, so are buffer overflow attacks in compiled code. Any crypto implementation will have "issues" that need to be engineered around. That's the purpose of independent review and open source code.
The original claim by the Matasano article was that JS crypto is "doomed," which I believe is patently false linkbait. While no one would agree that JS crypto is "ideal," I believe Nadim has raised very good arguments to say that, at the very least, it can be done properly.
We have mesothelioma and car insurance meta tags, but they're encrypted in such a way that you can only see them if you finish all 48 challenges. Why not sign up and see how you do?
In a perfect world, you're absolutely right. In practice, you couldn't be more wrong.
> You're wrong. If a JavaScript app is structured properly, especially one delivered as a signed browser plugin, it can run completely client-side with no capability to _execute_ remote JavaScript code from a server whatsoever.
It is absolutely possible to engineer an application in that way, but that is not how the vast, vast, vast majority of applications work. Most of them throw data straight into the DOM, they include scripts from the server, etc, etc. It's possible to do this right, but I rarely see it.
> You are correct that XSS is an issue, but as mentioned elsewhere, so are buffer overflow attacks in compiled code. Any crypto implementation will have "issues" that need to be engineered around. That's the purpose of independent review and open source code.
XSS is easy to find, easy to exploit, and exists everywhere in real-world web apps. This is comparing the danger of a car heading towards you at 200mph to a baby coming towards you in a stroller. They're just worlds apart.
At the end of the day, nearly every single web application I've tested (hundreds, if not thousands) has fallen to the same issues. This trend hasn't changed, and I don't expect it to do so any time soon.
Matasano's claim is that JavaScript is fundamentally "doomed" for crypto. You are saying that it is possible to engineer a JS crypto app properly, but almost nobody does.
There's a big difference between a technology being fundamentally broken and engineers simply not using it correctly.
This same sort of problem applied to PHP years ago. The default behavior of the language made it easy to write horribly insecure code, and many developers did. But it has always been possible to engineer a PHP app in a secure manner. You just had to work a bit harder at it in the past.
You are absolutely correct that most people don't write secure JS code today. But the web is an evolving platform, and as standards and engineering awareness improve, this will change.
The need for better in-browser crypto standards is clear. In spite of this, Nadim has proved that it is possible to build secure JS apps today. It is specious to simply dismiss his contributions because most other engineers don't write secure code.
You're wrong. If a JavaScript app is structured properly, especially one delivered as a signed browser plugin, it can run completely client-side with no capability to _execute_ remote JavaScript code from a server whatsoever.
Simply executing and parsing XMLHttpRequests does not mean that the JS app is executing arbitrary code from a remote server. It may simply be parsing JSON payloads. This is completely up to whatever code is delivered as part of the browser add-on, and cannot be remotely overridden by the server.
You are correct that XSS is an issue, but as mentioned elsewhere, so are buffer overflow attacks in compiled code. Any crypto implementation will have "issues" that need to be engineered around. That's the purpose of independent review and open source code.
The original claim by the Matasano article was that JS crypto is "doomed," which I believe is patently false linkbait. While no one would agree that JS crypto is "ideal," I believe Nadim has raised very good arguments to say that, at the very least, it can be done properly.