Because it is impossible to achieve, by design of the web, without trusting your server or installing something on your machine.

Let's say your encryption application comes from your server. If you have to trust your server anyway, why make a huge effort to try to put it into the web browser?

You can't tell your web server, as it controls what you see in your web browser, won't just make the web page transmit an unencrypted version of whatever message you are reading or authoring, somewhere you wouldn't want it to go. So the browser silently allows the server administrator to watch over your messaging. You MUST trust your server. It's inevitable.

The entire architecture of HTML and Javascript is intended to be so flexible, that you cannot ensure the safety of crypto operations. The existence of plenty of dedicated crypto APIs and libraries does not solve this chicken/egg issue of trust: A web server can make it look like everything is fine and you can't tell something is going on behind your back.

Even the developers of Javascript crypto solutions admit it themselves, that their tools are only useful if the server is trustworthy: "A person getting access to your server can modify Javascript code and public key of the receiver."

There's also the possibility for a man in the middle to insert malicious Javascript designed to redirect copies of your unencrypted messages elsewhere. Maybe even your passwords and private keys, so he only needs to do this once. Thanks to the complete unreliability of the X.509 certification infrastructure it is only a question of money for a man in the middle to view or modify anything you send or receive over HTTPS.

A web browser just isn't suited for 100% private communications as it is built to do what the web server tells it to.

Then it can be okay. If the website you are using is actually entirely installed on your device and all communication to the web server is exclusively done via something like secushare, or in the case of traditional web servers, via AJAX-like technologies over encrypted HTTP, the way hellais does it for GlobaLeaks. Most smartphone apps are somehow implemented that way: in the form of "static" web applications that get downloaded to your phone and stay there.

Unfortunately, for end users installing a serverless web interface on the local computer is just as complicated as installing an actual software package, so there is no advantage in choosing a work-around if you could have a dedicated and properly designed end-to-end communication tool without unnecessary drawbacks.

One thing that is slightly easier to install than custom software is a browser plugin like Cipherbox. Still, Cipherbox provides for a quite simple attack vector: Once the message has been decrypted and inserted into the HTML document, a drive-by Javascript can steal the decrypted message and send it wherever you don't want it to be.

The only solution to truly provide end-to-end encryption in that case is to have unencrypted data only appear in the custom user interface of the add-on, never in the web page. That usually destroys any intended usability and you can no longer say your application is actually web-based. It is quite impractical and makes it pointless to not use a dedicated and secure software package from the very start. That's why there apparently doesn't exist any such add-on.

In the case of secushare you of course get a lot more than just what a browser add-on could offer, since a web browser wouldn't be able to do sybil-attack resistant cryptographic routing, or other of the magic described on this website, to dramatically improve your privacy in communications.

Unfortunately not. Please restart from the homepage of this website, you can either read the paper or let the cartoon explain it to you. We presented this thinking at the 28C3 conference and the hackers and experts on location agreed with us that servers are no longer to be considered safe for your private data if not encrypted by you before it gets there. Yes it is new thinking to consider servers evil in general and we might have to hold separate security paper presentations just on that topic.

It's a logical fallacy. A technical impossibility. A bad idea. A very bad idea. But there's nothing as strong as a bad idea whose time has come, so you will hear of this a while longer until somebody hits their nose bleeding on it.