It sounds like it'd add an additional layer of complexity to my situation without an obvious up-side over my existing solution.
Sure, they claim they are open source and that the infrastructure was audited, but this does not prevent them from just configuring their auto-update server to serve a very special update to user at a specific IP.
This is false. The decryption code was run on the server, which means the password was sent to the server briefly. Hushmail simply stored the password for a few accounts. No client code was modified nor any auto-update changed. In fact, if the criminals had used the Java applet, they'd likely have gotten away with it (assuming they didn't update it)
>However, installing Java and loading and running the Java applet can be annoying. So in 2006, Hushmail began offering a service more akin to traditional web mail. Users connect to the service via a SSL (https://) connection and Hushmail runs the Encryption Engine on their side. Users then tell the server-side engine what the right passphrase is and all the messages in the account can then be read as they would in any other web-based email account.
>The rub of that option is that Hushmail has -- even if only for a brief moment -- a copy of your passphrase. As they disclose in the technical comparison of the two options, this means that an attacker with access to Hushmail's servers can get at the passphrase and thus all of the messages.