Either will work for the given scenario. The only difference I see is that with client-side crypto you can't accidentally write the key into a server log file, where as with server-side crypto it is possible.
But then again at some point you will add some logging to client-side code as well, so the point will be moot - you will have to sanitize logs at point of production.
Another thing is that it makes much better messaging - "the encryption key never leaves your machine".
Why do you think the other method does not have the same weaknesses? If the browser is compromised the key that users enters into the web page is leaked, regardless of whether you use client-side or server-side crypto. The fact that in client-side crypto in addition to the encryption key the code itself could have been tampered does not add anything to the threat... does it? The key is already presumed to have been leaked, and things can not get any worse than that.
As far security is concerned, the two are equally (in)secure. And client-side crypto still has the advantage that key management is much easier to explain to the user, thus the app is more likely to be used.
> Why do you think the other method does not have the same weaknesses?
Trivially: JavaScript encryption is vulnerable to MITM attacks that SSL is not. The only solution to this is to deliver your JS over SSL, but browsers will complain if you try to mix https and non-https elements in a page, and you might as well serve the whole page over https anyway. If you do that, then you still don't need JavaScript. (As one example; I know there are others but I just came in from the yard and my brain is a little melty right now.)
> As far security is concerned, the two are equally (in)secure.
This is a statement which flies in the face of the recommendations of some very smart people in the security field, some of whom have written extensive posts which have been linked to in this thread.
Even if I didn't (barely) know enough to evaluate your claims on my own, I could conclude that you might be right ... but I wouldn't bet on it.
Look, this subject has been discussed to death and nauseum, including here on HN. There have been extensive essays written about it. If you don't want to believe me, I'm OK with that. Go read their stuff, and see if it makes more sense to you.
If, after reading all of that, you still think you have some new insight in the field that everyone else has overlooked, and you can show why JavaScript is "equally (in)secure" to SSL + server-side encryption, then make your own blog post or essay about it. Make it good and in-depth, link to it from HN, tell everyone about it. I'd be happy to read it.
Otherwise you and I are just going in circles and not getting anywhere.
But then again at some point you will add some logging to client-side code as well, so the point will be moot - you will have to sanitize logs at point of production.
Another thing is that it makes much better messaging - "the encryption key never leaves your machine".