If you assume that the provider of the JS crypto has the same care of the server-side crypto, something changes. The difference:

* a well programmed host-proof hosting app garantees the user privacy
* a good programmed server-side crypto app cannot garantee it

Mantain a HPH system is more critic that mantain a server-side crypto system, it requires more attention, I know it. But I think that the choice depends from your objective.

The one thing JS crypto gets you that server-side crypto does not is client-side auditability. That’s it. However, this benefit comes with tremendous caveats that I think far outweigh it.

* The user has to be a cryptographer and can detect subtle cryptographic flaws. Note: this ignores all the malicious crypto research by Yung et al and assumes this is actually doable in reasonable time.

* The user always does “View Source” each time she connects to be sure the code is identical. If it was changed for bugfixes or whatever, she has to re-review the entire thing.

* The user always loads everything over SSL to be sure she’s getting untampered code and there is no MITM.

* The JS code does not have cache problems where users keep running old code after you’ve fixed a flaw and tried to upgrade them.

* You periodically audit all your servers to be sure they aren’t serving up malicious or outdated JS code. Note: this audit cannot be done via a client because an attacker can return different code to you than your users, based on src IP.

Since no one does all this and the disadvantages are so significant, JS crypto is worse than server-side crypto.

I didn’t point the attention on trust, but on the possibility of create a crypto system that properly uses Javascript. I am a founder of Passpack, an online password manager. We launched our tecnology in december 2006 and now we have about 70,000 users. During theese years, we haven’t have security issues. This says something.

I know that we must trust a web system, always. But a well made Host-proof Hosting system offers same advantages for the user, because safe her privacy.

To grab your data, I need to create a back door in the code. Is is a clear violation of the contract with the user and you can notice the modification.

Instead, if the encryption is delegated to the server, during the job I can make a copy of you data and you can not know it.

Javascript has no unique root of trust. Here is a “secret keeper” application that encrypts the user’s data using a password they enter into the browser. All communications are over SSL to prevent MITM.

Design #1:
A. Client gets HTML form
B. Client posts data and password
C. Server runs code that encrypts data with password and stores it

Attack: compromise server and trojan the code

Design #2:
A. Client gets HTML form and Javascript code
B. Client runs JS code that encrypts data with password
C. Client posts encrypted data to the server

Attack: compromise server and trojan the JS code

Both models have the same root of trust: the server. Everything else is just handwaving.