the vuln was not that the JS was bad or untrustworthy, but that the passphrase was sent to the server.
If the entire connection to the server is secure, and the JS is loaded from the secure server and is auditable/checksummed, then the risk is minimal. You either trust the code or you get out.
That doesn't make sense. Who would audit the code and how would you get the checksum?
If you only run code that matches a static, hardcoded checksum then there's no point in downloading it. Might as well just store a copy of it because now you have a client application. On the other hand, if you already have a secure method of receiving a checksum you can trust, you might as well just use that other, magically incorruptible communication channel for downloading all the code (and all your email, for that matter).
> the vuln was not that the JS was bad or untrustworthy, but that the passphrase was sent to the server.
Which is one of the most commonly cited vulnerabilities with web-based crypto. The fact that no JS was involved doesn't really change anything.
> If the entire connection to the server is secure, and the JS is loaded from the secure server and is auditable/checksummed, then the risk is minimal. You either trust the code or you get out.
I assume you're referring to client-side, JS-based encryption. The problem is that the server can always slip a backdoor into the webpage, and your browser will dutifully execute it. It doesn't matter if the JS is sent via SSL. A compromised server can deliver compromised JS, and SSL provides no protection against that.
You can't practically audit for this. You could theoretically read the JavaScript. But performing a thorough audit on a cryptosystem is a big undertaking. And then how do you know it hasn't changed the next time you visit the page? You mentioned checksums, but how are you going to do that? Are you going to manually MD5 the JS file on every visit?
Even if you did, the JS file is just one of many ways a compromised server can backdoor your browser. For example, we recently learned about HTML5 timing attacks (http://www.contextis.com/files/Browser_Timing_Attacks.pdf). And that's just the tip of the iceberg. Checksums aren't going to tell you if these sorts of things are happening.
A compromised server can compromise any data entered into webpages it serves. There is no known way around this.
You cannot trust the code. You cannot trust the code because the supplier could be forced to include a backdoor, and thus you have to audit the code before every session.
If the entire connection to the server is secure, and the JS is loaded from the secure server and is auditable/checksummed, then the risk is minimal. You either trust the code or you get out.