Ask HN: Why doesn't someone provide JS encrypted webmail
I think there is a market for someone to provide client side passphrase encrypted webmail, that is truly secure both from intruders and the mail hosting servers. Why don't webmail companies or a startup provide that?
64 comments
There are two very good reasons why nobody should bother doing this.
First: browser Javascript is the most hostile possible environment in which to implement cryptography. From actual experience: you are better off trying to implement crypto in a microcontroller, with kilobyte-denominated space for code storage, no cold-start entropy, and a few tens of bytes headroom for negotiation. Seriously: do that first, before trying (and inevitably failing) to run the Javascript gauntlet[1].
Second: the security economics of mail drastically favor Google over anything you come up with, even if you're really good. That's because the cost of a sitewide compromise at Google is stratospheric. Google is maximally incented to protect their service and has the resources and mindshare to do so. Nobody cares about someone else's bespoke mail service. People who care about mail security but don't trust Google just VPN to a private mail server.
Incidentally, Fortune 500 companies grappled with this problem many moons ago, and have adopted the strategy of "things that need to be sent over secure email will instead send links to an HTTPS web application we run onsite and call 'secure email' even though it's really just 'private file sharing'". Which makes it doubly hard to pitch this as a product idea: most of your market has already rejected the model you're considering.
This is a bad startup idea. Avoid it.
[1] For starters: in browser JS, every function call can be redefined arbitrarily many times before it gets key material, web content is allowed to influence or even rewrite that code, there's no effective way to verify code before running it, code is pulled from multiple sites, there are browser "chrome"-level security flaws still being discovered, there's no solid secure random number generation, functions are timeable, there are solid implementations of only a very few algorithms, and what remains to be implement is hazard-prone. Writing crypto code in JS is hubris, pure and simple.
First: browser Javascript is the most hostile possible environment in which to implement cryptography. From actual experience: you are better off trying to implement crypto in a microcontroller, with kilobyte-denominated space for code storage, no cold-start entropy, and a few tens of bytes headroom for negotiation. Seriously: do that first, before trying (and inevitably failing) to run the Javascript gauntlet[1].
Second: the security economics of mail drastically favor Google over anything you come up with, even if you're really good. That's because the cost of a sitewide compromise at Google is stratospheric. Google is maximally incented to protect their service and has the resources and mindshare to do so. Nobody cares about someone else's bespoke mail service. People who care about mail security but don't trust Google just VPN to a private mail server.
Incidentally, Fortune 500 companies grappled with this problem many moons ago, and have adopted the strategy of "things that need to be sent over secure email will instead send links to an HTTPS web application we run onsite and call 'secure email' even though it's really just 'private file sharing'". Which makes it doubly hard to pitch this as a product idea: most of your market has already rejected the model you're considering.
This is a bad startup idea. Avoid it.
[1] For starters: in browser JS, every function call can be redefined arbitrarily many times before it gets key material, web content is allowed to influence or even rewrite that code, there's no effective way to verify code before running it, code is pulled from multiple sites, there are browser "chrome"-level security flaws still being discovered, there's no solid secure random number generation, functions are timeable, there are solid implementations of only a very few algorithms, and what remains to be implement is hazard-prone. Writing crypto code in JS is hubris, pure and simple.
1) "Second: the security economics of mail drastically favor Google over anything you come up with, even if you're really good. That's because the cost of a sitewide compromise at Google is stratospheric."
This cannot be a serious answer: Some chinese already compromised Google a few months go - they stole the "Gaia" source code. Gaia is the single-sign-on solution for all Google services! Just because they are not unsing it on a big scale you can be sure there are people using exploits found from the source code to log into Google accounts.
2) "People who care about mail security but don't trust Google just VPN to a private mail server."
A VPN in general can be considered secure. If configured properly. Same for a mail server and for the network behind the VPN. In general: I would recommend a secure file sharing environment focussed on security & encryption. And no, that´s not Dropbox or box.net.
There is no better solution than GnuPG/PGP client encryption. Or at least partially secured file sharing offers like datainherit.com or cloudsafe.com
This cannot be a serious answer: Some chinese already compromised Google a few months go - they stole the "Gaia" source code. Gaia is the single-sign-on solution for all Google services! Just because they are not unsing it on a big scale you can be sure there are people using exploits found from the source code to log into Google accounts.
2) "People who care about mail security but don't trust Google just VPN to a private mail server."
A VPN in general can be considered secure. If configured properly. Same for a mail server and for the network behind the VPN. In general: I would recommend a secure file sharing environment focussed on security & encryption. And no, that´s not Dropbox or box.net.
There is no better solution than GnuPG/PGP client encryption. Or at least partially secured file sharing offers like datainherit.com or cloudsafe.com
You think I trust "DSwiss.com", the "Swiss bank for information assets", founded in 2006, more than I trust the largest technology company in the world --- and presumably one of the top 10 spenders on software security worldwide?
Sorry, no, I don't. Maybe you can name one person I'd have heard of who has assessed any piece of their source code?
Sorry, no, I don't. Maybe you can name one person I'd have heard of who has assessed any piece of their source code?
Not that I have any interest in this as a startup idea, but could the issues with Javascript be avoid by using Flash instead?
So basically, you'd be taking all the security obstacles of browser Javascript, and adding to them: having two Javascript interpreters to worry about, having an additional set of interfaces to secure (between the browser and the plugin), and never being entirely sure of what the attack surface for the Flash plugin is, since it's closed-source.
No, probably not a win.
No, probably not a win.
Was wondering, thanks.
I'm not worried about Google being compromised by a third party. I believe my mail host should not be able to read my email. VPN to a private mail server is good, but I dont want to have to trust the mailserver. It might be a bad startup idea if you expect people to pay you 5 bucks a month for an account (may be). But what if it runs like any other mail host, and lives through advertising? Or better still is build on top of one the free vanilla insecure hosts?
This is the sort of thing PGP was invented for. Why not use that?
I agree about the JS issues. Surely, someone out there has an idea to tackle these issues?
[deleted]
It's hard to implement securely.
Think about this: if encryption/decryption is performed client-side (JavaScript), then any cross-site scripting (XSS) or cross-site request forgery (CSRF) could potentially leak sensitive information to an attacker. (Where are private keys stored? How can Javascript prevent client-side attacks from leaking keys/passphrases?)
That said, client-side hashing and sending of passphrases is not a new concept. This HN post (http://news.ycombinator.com/item?id=1750468) from a few days ago goes over some of the intricacies and possible security implications of client-side hashing.
As far as actual client-side crypto (meaning the algorithm itself): Javascript is simply too prone to tampering. The problem is that, let's say the user is phished or man-in-the-middled. They will then implement (edited and flawed) crypto that will appear to them to be genuine, while in fact their passphrase and ciphertext were probably just leaked all over the Russian hacker underground.
Now, I'm not saying that it's impossible to implement client-side crypto or even that those that do will immediately get hacked... I just think this is why someone hasn't really provided it as a service yet.
Oh, and one more thing--if it's client-side encrypted email, how does the plaintext get from the email server to the client? Over the web in plaintext or HTTPS?
Think about this: if encryption/decryption is performed client-side (JavaScript), then any cross-site scripting (XSS) or cross-site request forgery (CSRF) could potentially leak sensitive information to an attacker. (Where are private keys stored? How can Javascript prevent client-side attacks from leaking keys/passphrases?)
That said, client-side hashing and sending of passphrases is not a new concept. This HN post (http://news.ycombinator.com/item?id=1750468) from a few days ago goes over some of the intricacies and possible security implications of client-side hashing.
As far as actual client-side crypto (meaning the algorithm itself): Javascript is simply too prone to tampering. The problem is that, let's say the user is phished or man-in-the-middled. They will then implement (edited and flawed) crypto that will appear to them to be genuine, while in fact their passphrase and ciphertext were probably just leaked all over the Russian hacker underground.
Now, I'm not saying that it's impossible to implement client-side crypto or even that those that do will immediately get hacked... I just think this is why someone hasn't really provided it as a service yet.
Oh, and one more thing--if it's client-side encrypted email, how does the plaintext get from the email server to the client? Over the web in plaintext or HTTPS?
I don't know why anyone would have downvoted this comment; clientside hashing is also bad, and CSRF isn't really the dealbreaker that XSS is, but it's a decent survey of the issues.
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.
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.
I suspect because nobody can be bothered to encrypt mail anyway? I've tried to establish pgp links with friends several times, but eventually we always fell back to unencrypted mails.
Of course some super-companies might require encrypted mail, but that might not be a good enough use case to base a business on.
Of course some super-companies might require encrypted mail, but that might not be a good enough use case to base a business on.
I think people don't use pgp because you have to install a client. People want to be able to access their mail from their home PC, work PC, laptop, friend's laptop and the library. Also, we want to remember our own pass-phrase rather than a private/public key.
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.
True, but can't there be a way to certify the complete client side source (HTML + JS)?
S/MIME encryption on Mail.app is pretty close to transparent, once you grab a personal cert. It's what I'd recommend to a small team that wanted the easiest secure mail solution.
(We use PGP).
(We use PGP).
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?)
(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?)
True, its just that the client software should be able to run on many computers etc. i.e., one should be able to use their friends laptop to check email for 5-10 minutes, AND be secure. (disregarding key loggers and the like)
What keeps the webmail company from supplying you with modified client-side JS code which forwards the keys you enter to $three_letter_agency?
Right, and they only have to give it to you once to steal the passphrase, and only have to give it to one or two persons of interest, not necessarily everyone, so it can be very difficult to detect. If they were smart, they'd also check headers and other info to try to prevent serving the trojaned page to someone who might be auditing.
Exactly, and I think that's a potential problem with hushmail (but those guys are to be commended for some honesty). How about a number of independent, hacker type, or FSF type communities certify the client side JS through md5 digests on the client side code or the like?
But how do I verify that the JS code being served to me in this moment is the version audited by the trusted party? AFAIK, mainstream browsers have no button to compute a hash over the contents of a website.
(And it's not just reusable JS libraries one would have to audit and checksum; the HTML code of individually rendered message pages could also contain JS code to subvert the security).
(And it's not just reusable JS libraries one would have to audit and checksum; the HTML code of individually rendered message pages could also contain JS code to subvert the security).
Take a look at Aldo Cortesi's AppHash for one impl of verification of code right when it loads on the page.
Cortesi doesn't have a solution to this problem for unmodified browsers. If you get to modify the browser, you're no longer talking about "web mail"; you might as well just write a real secure mail client, and use HTML5 for your cross-platform UI.
I find Cortesi's promotion of his web crypto tools pretty close to the "dishonesty" line. He's not dishonest. But whether he knows it or not, he's coming as close to the line as he can. People keep telling him, browsers can't safely do the things he's telling people they do. He keeps disregarding them.
I find Cortesi's promotion of his web crypto tools pretty close to the "dishonesty" line. He's not dishonest. But whether he knows it or not, he's coming as close to the line as he can. People keep telling him, browsers can't safely do the things he's telling people they do. He keeps disregarding them.
Yes, but a firefox add-on is easier than a mail client. Cortesi's solution still leaves out the problem of asymmetric encryption, and storing private keys though.
Hush mail has the benefit of being located in Canada, meaning they aren't beholden to the Patriot Act (i.e. they aren't forbidden from telling you if someone wants your mail), and the FBI, etc. have to go through the RCMP to get a warrant.
Now, someone just breaking into their servers, on the other hand, is another matter.
Now, someone just breaking into their servers, on the other hand, is another matter.
Good question. Right now I guess from a cryptographer's point of view all our emails are basically as public as Twitter messages, if anyone cares to read them.
Technically I think a purely passphrase-encrypted webmail would not be very secure, because if you used an asymmetric algorithm, the private keys would no longer be private, and if you used a symmetric algorithm you'd either have to change the pass-phrase each time or deal with a key-vulnerability. But I might be wrong.
Finally the demand could probably be created if it were implemented in a user-friendly way. I think it has to, somehow, eventually. It will not be difficult to convince people to use it once it works in a simple, transparent way. After all, everyone got used to logging in everywhere, as well.
In the long run, now matter how cool clients like GMail are, we should not leave our private communication to others and especially not to companies.
Perhaps it requires a person similar to Mark Shuttleworth with a lot of resources and a philantropic drive to start thinking about a solution.
Technically I think a purely passphrase-encrypted webmail would not be very secure, because if you used an asymmetric algorithm, the private keys would no longer be private, and if you used a symmetric algorithm you'd either have to change the pass-phrase each time or deal with a key-vulnerability. But I might be wrong.
Finally the demand could probably be created if it were implemented in a user-friendly way. I think it has to, somehow, eventually. It will not be difficult to convince people to use it once it works in a simple, transparent way. After all, everyone got used to logging in everywhere, as well.
In the long run, now matter how cool clients like GMail are, we should not leave our private communication to others and especially not to companies.
Perhaps it requires a person similar to Mark Shuttleworth with a lot of resources and a philantropic drive to start thinking about a solution.
If the private keys were stored pass-phrase encrypted it could work, and the weakest link of your private key/passphrase defines your security.
Yes but then you'd also have to store them across all installed clients/browsers and, when accessing from another computer, first transport the keys to that computer.
That's why I think public keys would be the user-friendly way. Public = Only passphrase protects the key.
That's why I think public keys would be the user-friendly way. Public = Only passphrase protects the key.
Right, that's what I meant actually. It seems like something that should already exist.
Working on this exact problem myself: https://droplettr.com - the encryption uses Firefox Sync crypto module in an extension, so the crypto is done by the browser outside the scope of content JS. The rest of the app is pure JS and HTML, with a Python/Django REST-style server.
This looks cool. Is there a way to know that the client side code has not been tampered with? I'd like to see more people comment on this one.
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.
Also, the number of people who even know what you're talking about is vanishingly small, and few of them would pay.
How about advertising?
Because if you're actually concerned about the privacy and security of your messages then webmail ain't ever gonna cut it.
I don't care at all about the privacy and security of the already encrypted and signed blobs that I would be sending to webmail, in this hypothetical scenario. Why would I? They're already encrypted and signed.
The trick is getting encrypted webmail that's actually secure, without also being so hard to use that almost nobody actually does it.
The trick is getting encrypted webmail that's actually secure, without also being so hard to use that almost nobody actually does it.
It would be trivial for anyone with access to the webmail provider's server to steal your password and decrypt your mail. So you don't really gain much by having it encrypted there in the first place.
I was assuming that my private key would be stored locally. And the encryption code, too. As I said, doing this securely and usably would be hard.
I have been working on this for few months now. It is a CR/FF/SF browser extension which should work with gmail/yahoomail/hotmail. Please get in touch with me if you like to be notified - skommoori (at) gmail.com
Recently, I have pitched the idea to few people both in angel community and some of my friends and tc disrupt visitor friends that I met. As few users have mentioned in the comments, it really boils down to people having awareness. People who are familiar with the encryption see the value immediately and people with no knowledge start to question why they need security. I have decided to go release the product. It is encouraging to see someone really cares about this stuff.
When I saw the gmail/china hacking fiasco, it is so much frustrating to see how dumb found we as users are left even though matured standards (rfc822, SMIME, OpenPGP)exist. Hopefully, what I am working would solve the exact issue we have been facing and no one is working on this non sexy item.
On the technical/details side, not just encrypting the text, it is more important to encrypt the whole message including attachments. Rightnow I have the prototype which works for text message and trying to expand it to cover attachments. The problem with FireGPG or few other things that I tried include how painful it is to setup and maintain - I also think, that being the reason for not getting popularity. There are already quite a few libraries for RSA, AES, HMAC(pick your language of choice). Implementing the plugin with Javascript has serious performance and security (good luck supporting OpenPGP). So core items need to be implemented in compiled language - for me they are in C/C++. I would love to share more details about the core crypto stuff if you want to.
Recently, I have pitched the idea to few people both in angel community and some of my friends and tc disrupt visitor friends that I met. As few users have mentioned in the comments, it really boils down to people having awareness. People who are familiar with the encryption see the value immediately and people with no knowledge start to question why they need security. I have decided to go release the product. It is encouraging to see someone really cares about this stuff.
When I saw the gmail/china hacking fiasco, it is so much frustrating to see how dumb found we as users are left even though matured standards (rfc822, SMIME, OpenPGP)exist. Hopefully, what I am working would solve the exact issue we have been facing and no one is working on this non sexy item.
On the technical/details side, not just encrypting the text, it is more important to encrypt the whole message including attachments. Rightnow I have the prototype which works for text message and trying to expand it to cover attachments. The problem with FireGPG or few other things that I tried include how painful it is to setup and maintain - I also think, that being the reason for not getting popularity. There are already quite a few libraries for RSA, AES, HMAC(pick your language of choice). Implementing the plugin with Javascript has serious performance and security (good luck supporting OpenPGP). So core items need to be implemented in compiled language - for me they are in C/C++. I would love to share more details about the core crypto stuff if you want to.
When you talk about "RSA, AES, HMAC", you leave me to wonder whether you're actually implementing a standard like PGP or S/MIME, or whether you've invented your own encryption scheme. I hope for your sake it's former, and not the latter. Know that most large companies do use encrypted mail, and have a standard that their partners must use.
Yes. I am going to support OpenPGP. As you said, inventing own encryption is not a smart thing to do.
Great to know someone is working on it. If it is in C/C++, the user has to download a program, and it is not simple webmail. Secondly, what about the private keys? Do we have to remember them? The reason pgp has not caught on for most people is because we dont want to go through a complicated mail client installation. If your solution is simpler/easier to install, that's a plus. However, I should be able to access my secure mail through computers not my own. Is your compiled solution open source or can it be certified secure? i.e., that it is not sending the unencrypted private key or passphrase to some backdoor? These are all issues to keep in mind. Would love to see your product. Good luck!
It is an extension that you download for the browsers - Chrome/FF/Safari are targeted. Yes you can access your encrypted mail from your computer, friends computer, etc..
Generating and Managing keys and all other logistics are something I think we will add to the value of already existing OpenPGP protocol. I will definitely go through app signing and code verifying by outside agencies(so users are sure of authenticity)
My motto is, even grandma should be able start encrypting emails :)
My motto is, even grandma should be able start encrypting emails :)
I have thought about this, and I would pay for a well engineered solution for which the operators are open about the inevitable limitations.
The issue of JavaScript being manipulated by the operator to steal your passphrase/key is tricky, as mentioned by others. You might be able to do the crypto part in a separate scripting context via code stored in HTML5 local storage after you've reviewed it once, and using window.postMessage() in some way? The plaintext could be displayed in an IFrame running in that local context.
Then there's the issue of unencrypted incoming mail. You'd need to trust the SMTP server operator to encrypt any incoming mail with your public key and then destroy any record of the plaintext.
Metadata is also an issue: you'd want to encrypt headers as well as the body, as knowing when you communicate with whom is almost as valuable as knowing the content of said communication. Encrypting it is easy, indexing it for efficient access less so.
Still, this could exist as a self-hosted package for the more paranoid as well as SaaS.
The issue of JavaScript being manipulated by the operator to steal your passphrase/key is tricky, as mentioned by others. You might be able to do the crypto part in a separate scripting context via code stored in HTML5 local storage after you've reviewed it once, and using window.postMessage() in some way? The plaintext could be displayed in an IFrame running in that local context.
Then there's the issue of unencrypted incoming mail. You'd need to trust the SMTP server operator to encrypt any incoming mail with your public key and then destroy any record of the plaintext.
Metadata is also an issue: you'd want to encrypt headers as well as the body, as knowing when you communicate with whom is almost as valuable as knowing the content of said communication. Encrypting it is easy, indexing it for efficient access less so.
Still, this could exist as a self-hosted package for the more paranoid as well as SaaS.
The encryption should really take place in a scope that content JS cannot access. I also think a system like this should be built completely parallel to email systems. Email is crap and needs to be re-invented as a web app with pseudo-anonymity and Public Key Encryption on by default. Users should not even know they are using encryption.
You can start a new startup from technology or from a market need. Start with market first, the question you should be asking is "who needs to communicate privately, wants to pay for it, and was not able to do that so far in a satisfactory manner?". Once you figure it out you might realize that most of the "it's impossible to do perfect, hence no point in doing it at all" concerns while generally valid do not apply to your target market. And from there it's perfectly doable and might be a good business too.
edit: doesn't have to be about email either - the need is first and foremost. it could be well just a private messenger platform.
edit: doesn't have to be about email either - the need is first and foremost. it could be well just a private messenger platform.
Probably because it's a feature, not a viable business of its own. So existing web mail providers would have to do it, but they won't because it runs counter to their ad targeting practices.
I was thinking something similar recently. Not necessarily a web-app, but an app that encrypted message in the client, and was only decrypted on receipt. So even if the mail/message server/store was hacked, none of the messages would be readable.
There are grease monkey scripts that do this. Maybe because there is very little demand?
If more people became aware how much of their profile resides with ISP's, DNS providers, and email hosts, I think many would prefer such a thing. Google, by the way is a DNS provider, search gateway, email host, AND an advertiser. It might be popular if it was free (you can still have some advertising), and actually secure. I'd imagine at least a portion of the hacker community would gravitate to it.
Are you talking about this? http://www.langenhoven.com/code/emailencrypt/gmailencrypt.ph...
I'll check it out, though I thought it had some issues with the latest version of FF.
Are you talking about this? http://www.langenhoven.com/code/emailencrypt/gmailencrypt.ph...
I'll check it out, though I thought it had some issues with the latest version of FF.
That link looks like it could be what the OP is after. The _only_ caveat is you need recipients to tell you where their key is stored. It would be good if there was a service that stored public keys keyed by email.
A GnuPGP-extension for Firefox (or Chrome), enabling encrypting or signing any text boxes. Sounds possible, don't know how well it would react with rich editing forms.
edit: complemented with a web-service storing your keys in the 'cloud'.
edit: complemented with a web-service storing your keys in the 'cloud'.
There's FireGPG. It's kinda meh in practice. I ended up going back to using Thunderbird for signed emails (invoices, generally) because it was so fiddly and sometimes just didn't want to work, especially with attachments.
I rememember there was someone on HN working on that a few years back. There was a nice discussion around it.
I can't find the thread, perhaps someone else has better luck?
FireGPG recently shut down, put used to provide this.
If you make it, I'll would use it.
This already exists: www.epostalservices.com
Outlook only. The original post was about webmail, sorry.
Our webmail installation encrypts the password on the client side, it's never sent in plain and we never know what it is. It's not hard, various crpyto libs are available for Javascript. I've written multiple HTML based login systems that never require knowledge of the plain text
Is that what you mean ?
Edit: Oh, you mean we never know the plaintext of the email.
You mean like this : http://www.hanewin.net/encrypt/
http://46dogs.blogspot.com/2007/11/encrypting-to-pgp-gnupg-g...
http://stackoverflow.com/questions/2802541/pgp-encryption-in...
tl;dr - too slow
Is that what you mean ?
Edit: Oh, you mean we never know the plaintext of the email.
You mean like this : http://www.hanewin.net/encrypt/
http://46dogs.blogspot.com/2007/11/encrypting-to-pgp-gnupg-g...
http://stackoverflow.com/questions/2802541/pgp-encryption-in...
tl;dr - too slow
No, the OP is talking about encrypting the data (the mail), not the credentials (the password).
EDIT: oh, you caught on
EDIT: oh, you caught on