I could even use gmail as the pop3/smtp server, if the mails are encrypted anyway.
Anyway if you control the host, and it communicates with you through SSL using a self-signed certificate, and you make sure you have no awkward browser extensions installed then your attack vectors are dwindling fast.
Ofcourse once the machine is compromised it can trick you into giving it the key, but there are also countless scenarios where that is not possible. It is really an improvement onto your security.
Lets not pretend that read-protected memory is such a secure way of storing private keys.
In other words, if the host is sitting on your desk. Chances are good that you have more control over the computer you type your messages on than some server you set up. What makes you think that the rack mount you left in your mom's basement is not being tampered with while you are away?
"your attack vectors are dwindling fast"
Now you need to trust both the host and your client machines, while before you only needed to trust your clients.
Wow really? I don't think those chances are good at all.. I'm not sure how often it happens that a running server is tampered with physically but I don't think that chance is as high as my client system running any malware beyond my control.
With Chrome, Firefox, and Safari, it is possible to deliver web apps as signed, local browser plugins, applications and extensions. This greatly helps with solving the problem. In fact, I believe that it is necessary to deliver JavaScript cryptography-using webapps as signed browser extensions, as any other method of delivery is too vulnerable to man-in-the-middle attacks to be considered secure.
Let us for example say that I have a server which you are fairly certain that noone will compromise, but you do have a concern that someone might physically steal it. In such a case you might be more likely to trust the javascript it serves than you are to trust it with storing your actual private key.
(Yes, I realize that someone who gets physical access to the machine will be able to modify its code, etc. Yet, while it might be fairly easy for someone to physically break into a building it might be harder to do so without leaving any traces behind, alerting you of possible tampering.)
By the way, my trust example above is fairly similar to the use of ssh-agent forwarding; where you trust a machine enough not to abuse an active forwarding, but without having to trust it to actually store your private ssh key.
Neither do I understand why you appear to say that SSL would provide a comparably security. OpenPGP will definitely provide a stronger transport security than the possibly of there being SMTP StartTLS being done. Likewise might OpenPGP matter for the recepient, especially if that person are doing the decryption locally on a workstation/laptop, saving that person from having to trust his/her mail provider.
Here is why it might actually be a good thing:
1. Encrypting in the browser provides a more audit-able process. You still can't audit the webmail provider's server security, you can't ensure that they won't start serving borked Javascript in a month, but you can audit your data exposure assuming they do that correctly (which you have to assume anyway). Example: you have no way of verifying that <webmail-provider-X> isn't storing backups of your email on a publicly accessible endpoint (say, a public Dropbox). With PGP in browser, you may not care about that oversight.
2. Your trust in a provider is somewhat revokable. The webmail provider is able to launch an on-line attack against you by serving different Javascript, but they may not (depending on how the code is implemented) be capable of acquiring historical user data. This could be useful if, for example, an incident occurs where you no longer trust a provider (for example, after an event occurs, like Skype being sold to Microsoft, you could change providers safely assuming that Skype pre-Microsoft was 'safe').
3. Exposing a webmail PGP interface makes it easy for less technical people to communicate with people who may not trust their provider. For example, you may believe that gmail isn't going to do anything bad, and therefore have no interest in setting up Thunderbird+Enigmail. However, you may want to send email to a person who is forced to use an untrustworthy provider (and therefore uses a 'correct' PGP setup like Enigmail).
4. Exposing a webmail PGP interface allows people to play with PGP and become familiar with it before investing the time in a more robust software configuration.
The government can subpoena your emails on gmail, but I think they might have a more difficult time convincing google to change their javascript to add a $.post to steal your decrypted emails.
Also, these attacks rely on the user actively logging in. So if you are in jail or dead , your data will be safe.
This is an example of cargo cult thinking: well, cryptography is good, right? It protects me. I wish I had ENCRYPTED WEBMAIL, wow!
But seriously, think for a second what the threat model is.
Do you trust the webmail host to securely store your data and only give it up under warrants, etc? If so, then ordinary plain text communication over SSL is fine.
Do you not trust the host? Then them saying "oh, look at us, we're encrypting your emails" shouldn't make you feel any better. I mean, if you use the site to view your damn emails, then THEY'RE SITTING THERE "DECRYPTED" ON THE PAGE, and the host that you don't trust can do a simple $.post(...) of its contents, for example.
I seriously fail to see any example where this library is useful. Anyone have suggestions? In your suggestion be sure to note whether you trust the host or not, and if so why not just use SSL, and if not, why the host can't just bypass it with a line of jquery.