Ask HN: Why doesn't someone provide JS encrypted webmail

Because we've already got pgp, and when we can get the people we communicate with to use it, we don't mind using a command-line program (or a browser plugin, though we don't even really trust that) to decrypt. We definitely wouldn't trust some webapp's javascript to decrypt for us, unless we'd written it ourselves.

Then there's the question, which someone alluded to, of how to distribute new credentials to a browser that hasn't logged on before, and how to make sure they're deleted securely after I leave. Do you store the private keys encrypted and send them to the browser so they can be decrypted with my passphrase? I probably don't trust you to store even an encrypted version of my private keys, but I guess I can use a throwaway key for your service.

What I'm most worried about is the question: who is doing the encrypting? Are people sending mail to this address required to encrypt email to me? If not, are you going to encrypt my email as soon as it hits your servers? Not good enough, you may as well leave it in plaintext and use it to serve me ads.

The biggest problem with encrypted email today is that nobody uses it, and this doesn't fix that. It makes it easier (if it works, and I'm still not convinced it does) for people who already use it to do so, but it doesn't convince people that don't use the service (which is going to be a vast percentage of the people that don't use pgp now) that they should want encrypted mail.

But then the described service is useless, because you can only trust the confidentiality of your mail in so far as you can trust the honesty of the service provider not to hide backdoors in the js they send to your browser. But then you can just do away with the clunky client side cryptograpy and talk plain https with their server that does the encryption.

If you make it, I'll would use it.

The conscientious/paranoid people who care enough to engage in encrypted correspondence will want to run their own client software.

(Typing their passphrase into the hoster's provided JS/DOM, even in a browser under their own control, is essentially the same as sending it to their server. Maybe you could work out something with a bookmarklet, which scrapes ciphertext from one page but then displays the plaintext in another window entirely, but at that point, are you still enjoying the convenience of webmail?)

Because crypto in JavaScript would likely be vulnerable to side channel attacks (timing, processor use analysis, power analysis, etc). Even FIPS certified java and .net libraries call into c code. There's a reason.

Also, the number of people who even know what you're talking about is vanishingly small, and few of them would pay.