The article does not assume SSL isn't used. The article addresses JS cryptosystems in the presence of HTTPS/TLS from top to bottom.
But we also go out of our way to discuss JS cryptography as an alternative to HTTPS, because that is how many people use it; for instance, to do challenge-response authentication for "secure login" without needing SSL.
But that's a sideshow on this thread. The article squarely addresses exactly the application you've built, and in detail.
The article lists three reasons for why "JS crypto is bad" at the beginning:
- Secure delivery of Javascript to browsers is a chicken-egg problem.
- Browser Javascript is hostile to cryptography.
- The "view-source" transparency of Javascript is illusory.
The first issue is addressed by using SSL and controlling the page 100%. The third issue becomes a matter of trust, as many users trust closed-source vendors, so in an environment where closed-source vendors are truested (e.g. a typical accounting firm), the third issue becomes not about JS crypto but about vendor reliability.
That leaves the second issue. The article expands it as:
- The prevalence of content-controlled code.
- The malleability of the Javascript runtime.
- The lack of systems programming primitives needed to implement crypto.
- The crushing weight of the installed base of users.
The first and second sub-issues, again, are more or less addressed by using SSL and controlling the page, I believe. One can argue that because JS is so "malleable", it is very easy to add malicious code to a page. Yes, it is easy if you have access to it (via third-party scripts/XSS), but it is _harder_ to infect a JS crypto page that is properly set up than a regular online-banking page, for example, as most online banking pages have links to third-party advertising (often over plain HTTP!). So in the world where people and companies do online banking, the "malleability" does not seem to add a lot of issues.
The third sub-issue is being addressed in HTML5 and/or, via SSL, round-trips to the server (for random seeding, for example).
The fourth issue is, again, not much different from online banking.
In summary, it seems we are using somewhat different criteria of what "secure JS crypto" means. You seem to be saying that storing data in aes.io is less secure than in a truecrypt volume. I agree 100%. But what I am saying is that for an accounting firm that does online banking on a daily basis, using aes.io as opposed to a cloud collaboration service without client-side encryption would probably be a great idea.
The rebuttals you're making are addressed in the article you're commenting on, in detail.
The problem here is that the core value proposition of services like this one are "you can put your documents here even if you don't trust the operators".
But that, as it turns out, simply isn't true. You are exactly as reliant on the operators of aes.io as you are on the operators of Dropbox.
But we also go out of our way to discuss JS cryptography as an alternative to HTTPS, because that is how many people use it; for instance, to do challenge-response authentication for "secure login" without needing SSL.
But that's a sideshow on this thread. The article squarely addresses exactly the application you've built, and in detail.