4 ms·

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 o

by daeken 13y ago

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.

rubbingalcohol 13y ago
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.

by daeken 13y ago

rubbingalcohol 13y ago

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.