[ComputerGuru]

We use JS encryption heavily in a number of our webapps, so I'm not unfamiliar with its advantages. But relying on JS encryption to provide "security" over unencrypted HTTP is just asking for trouble. It's the "secure on paper, broken in practice" kind of thing that ends up being a huge liability.

[pdx]

Why do you speak of unencrypted HTTP? Who cares? Only AES-256 encrypted data is sent and it's decoded locally. You could publish it on the front page of the New York Times (if anybody reads that anymore) and be secure, because you are publishing encrypted content.

It's really unclear what your point is here.

[iancarroll]

Your unencrypted (or just unauthenticated) HTML page might suddenly start sending the password you enter elsewhere...

[pdx]

Really, how? Because somebody compromised the server? So what? If they did that, all bets are off.

[dpark]

No, because someone MITMs your insecure channel and serves you a malicious page that steals your password and the unencrypted data.

[gjjrfcbugxbhf]

The OPs point is very clear. Js encryption has a lot to do to prove itself before it should be trusted with production secrets.

Furthermore weak encryption is worse than no encryption if it encourages dangerous behavior.

I would add that dropping ssl because you are using something like this would be dangerous behavior.