[handsomeransoms]

Whether or not this is acceptable depends on your threat model. If you believe your adversary might compromise or coerce the service operator, then you cannot trust in-browser encryption even if it is served over https - the code sent to you could be modified to be malicious, and you have no way to prevent or even detect that this is happening. See the Tor Freedom Hosting [0] incident for an example of how LEA already do this.

So, the inability to guarantee integrity of a web application remains a problem. TLS helps, but falls short if your adversary can MITM TLS or compromise/coerce the service operator. Web applications unfortunately make this a very convenient attack vector, since their code gets reloaded from the server so frequently and remote code execution (RCE) is trivial to achieve on the web platform (XSS, browsers are full of exploitable bugs).

[0] http://www.wired.com/2013/09/freedom-hosting-fbi/

[Spearchucker]

GP's questions are (respectfully) being skirted around. The same reasoning applies to compiled, client-side code. Recent events show that open source code is as vulnerable as closed source. App stores may mitigate things somewhat, but not completely. It's probably easier to verify client-side encryption in a browser than it is to audit a thick client app, no?