One of the points not mentioned in the article is that this analysis is useful even if (like me, tptacek, and many others) you don't trust Javascript crypto.
That's because Mega is designed as simply an API that any client (including one distributed as a desktop application) could implement. However, another client implementing this same spec would have the same weaknesses. It's important that we get the design improved now. Then we can go on to build open source clients outside of the perils of the JS runtime.
Edited to add: If anyone is interested in building such a open source desktop client in Python, I could help by making our (SpiderOak's) toolchains, packagers, and installers available.
Edited again to add: Assuming a solid design and implementation is eventually produced in Javascript, you could probably re-use most of the code and avoid the JS runtime dangers by repackaging it as a desktop app with something like http://appjs.org/ Remember that of course your privacy is based not just on you using a secure client, but everyone you share data with doing likewise.
Paying customer here, thank you for a wonderful product and service!
One question I have is why SpiderOak client is not open-source? As I understand, it is Python and decompiling it for analysis is not too much trouble, but still...
Thanks for your interest in SpiderOak! Indeed we will open source the SpiderOak desktop client one day. We've been saying that for a long time, but we're very close. One of the reasons we haven't done so previously is how open source products often get spammed with copycat repackagers, like the VLC guy was explaining the other day.
I should also note that the crypto code in SpiderOak is in one specific module, and we have repeatedly paid for careful audits of that code.
Lastly, we have a new crypto product in the works which we will announce at RSA in February, which is 100% open source, and of particular interest to developers in addition to SpiderOak customers. Please stay tuned!
That's because Mega is designed as simply an API that any client (including one distributed as a desktop application) could implement. However, another client implementing this same spec would have the same weaknesses. It's important that we get the design improved now. Then we can go on to build open source clients outside of the perils of the JS runtime.
Edited to add: If anyone is interested in building such a open source desktop client in Python, I could help by making our (SpiderOak's) toolchains, packagers, and installers available.
Edited again to add: Assuming a solid design and implementation is eventually produced in Javascript, you could probably re-use most of the code and avoid the JS runtime dangers by repackaging it as a desktop app with something like http://appjs.org/ Remember that of course your privacy is based not just on you using a secure client, but everyone you share data with doing likewise.