Op-ed: Lavabit’s primary security claim wasn’t actually true

Moxie Marlinspike is a cryptographer, software developer, and security researcher who regularly appears at the Black Hat security conferences. His critique of HTTPS Web encryption has led browser makers to change the way they implement it. He is also developer of the TextSecure and RedPhone Android apps for encrypting text messages and voice calls. In 2011, Twitter bought his encryption startup Whisper Systems for an undisclosed sum. The pseudonymously named Marlinspike originally posted this editorial on his ThoughtCrime.org blog.

In August of this year, Ladar Levison shut down his e-mail service, Lavabit, in an attempt to avoid complying with a US government request for his users' e-mails. To defy the US government's gag order and shut down his service took great courage, and I believe that Ladar deserves our support in his legal defense of that decision.

There is now an effort underway to restart the Lavabit project, however, which might be a good opportunity to take a critical look at the service itself. After all, how is it possible that a service which wasn't supposed to have access to its users' e-mails found itself in a position where it had no other option but to shut down in an attempt to avoid complying with a request for the contents of its users' e-mails?

The guarantee

This was the front page of Lavabit in July, the month before its shut down:

The front page proudly claims Lavabit is "so secure that even our administrators can't read your e-mail." That sounds like exactly what one wants from an encrypted e-mail provider, so let's drill down and see what the details are on that "secure" link:

Again, this sounds awesome. They advocate that in today's world, a service which merely promises to respect its users' privacy with a policy statement isn't enough. Users should demand technical solutions which employ the use of cryptography to protect their privacy. This is the critical difference between a service that "can't read" and one that "won't read" your e-mail, which was presumably the draw for many of Lavabit's 40,000 users.

The mechanics

But how did it actually work? And if, as Lavabit said, it wasn't capable of reading its users' e-mails, how could it have been in a position to provide those plaintext e-mails to the US government?

Unfortunately, Lavabit's primary security claim wasn't actually true. As Ladar himself explained in this blog post, the system consisted of four basic steps:

At account creation time, the user selected a login passphrase and transmitted it to the server.

The server generated a keypair for that user, encrypted the private key with the login passphrase the user had selected, and stored it on the server.

For every incoming e-mail the user received, the server would encrypt it with the user's public key and store it on the server.

When the user wanted to retrieve an e-mail, they would transmit their password to the server, which would avert its eyes from the plaintext encryption password it had just received, use it to decrypt the private key (averting its eyes), use the private key to decrypt the e-mail (again, averting its eyes), and transmit the plaintext e-mail to the user (averting its eyes one last time).

Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext.

The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server's control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all. Whether it was or not makes little difference.

Measuring up

A typical (unencrypted) e-mail provider has three main adversaries:

The operator who has access to the server.

An attacker who can get access to the server.

An attacker who can intercept the communication to the server.

Despite the use of cryptography, Lavabit is also vulnerable to all three, just like a conventional (unencrypted) e-mail service. The operator can, at any time, stop averting their eyes, an attacker who compromises the server can log the password a user transmits, and an attacker who can intercept communication to the server can obtain the password as well as the plaintext e-mail.

Even though Lavabit's security page went on at length about how, in the age of the PATRIOT act, users shouldn't accept a Privacy Policy as enough to protect them, that is almost exactly what it implemented. The cryptography was nothing more than a lot of overhead and some shorthand for a promise not to peek. Even though it advertised that it "can't" read your e-mail, what it meant was that it would choose not to.

Perhaps we're just not reading between the lines, and all this handwaving was a ruse designed to trick the legal system (by claiming it was "unable" to respond to subpoenas) rather than a ruse designed to trick Lavabit's users. That could have been a plausible experiment to try, but Hushmail already tried the exact same experiment a decade earlier and met the exact same fate.

It's not clear whether the Lavabit crew consciously understood the system's shortcomings and chose to misrepresent them, or if it really believed it built something based on can't rather than won't. One way or the other, in the security world, a product that uses the language of cryptography to fundamentally misrepresent its capabilities is the basic definition of snake oil.

The big question

In the end, the US government requested Lavabit's SSL key. One big question is why the government didn't just get a CA to make it its own.

Maybe it was just lazy and assumed that since Lavabit previously complied with government subpoenas, the company wouldn't resist this one. The other possibility, however, is that the government was more interested in past e-mails than future e-mails. If the government wanted access to e-mails that might have already been deleted, its own SSL certificate wouldn't help it.

We know that the US government stores large amounts of ciphertext traffic, and since Lavabit wasn't preferring perfect forward secrecy SSL cipher suites, the government would have been able to go back and decrypt previous traffic with Lavabit's SSL key.

When Lavabit did eventually provide the SSL key (albeit in really tiny font!), perhaps that's exactly what the US government did. Any user who signed up thinking they were using some kind of special secure e-mail was compromised.

The quest for secure e-mail

I think we should celebrate and support Ladar for making the hard choice that he did to at least speak out and let his users know they'd been compromised. However, I think we should simultaneously be extremely critical of the technical choices and false guarantees that put Ladar in that position. There is currently an effort underway to release the Lavabit infrastructure under an open source license, which I worry will result in more of the same. Given its technical foundations, I wouldn't advocate supporting the continuation of the Lavabit project.

Rather than funding Lavabit, if you're interested in supporting a secure e-mail project, I have two alternate recommendations:

Mailpile: Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world. The first precondition for developing a usable and forward-secure e-mail protocol is a usable mail client, and I currently believe that Mailpile is our best shot at that.

Leap Encrypted Access Project: This is a secure e-mail project by people who fundamentally understand the challenges, the history, and the politics. They've been working on an incremental plan for developing a secure e-mail system with some really smart people, and I think we'll all benefit from their work.

Trevor Perrin has also been doing some excellent work on an asynchronous protocol for secure e-mail, which I encourage everyone to take a look at and follow along.

Promoted Comments

"Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world."

Sure it is. Anything a stand-alone client can do, a browser can do....

Exactly. The author either doesn't understand that you can implement stuff client side (Javascript for example) or he is making the leap that because doing so could potentially be too slow (in execution cycles) to be usable equates to "not possible"

If you start doing the decryption with javascript, then there are a number of issues that make it impractical and not totally secure. The question of where the private key is stored still exists. For practical and usability reasons, it's most convenient for the service to maintain the keys on their servers. It's possible that those keys can be password protected to provide limited protection against snooping, but users are notoriously bad at picking good passwords. Alternatively, you have to find some way to let the user store the private key themselves, leaving them wholly responsible for keeping it secure and backed up.

But assuming you have a workable solution for private key storage, you also need a way for the browser to perform the decryption of the email content, which is separate from normal decryption performed as part of the SSL/TLS connection. If, as you suggest, this is done by some JavaScript in the page. Then that exposes a huge security hole.

If you give the JavaScript access to the key and the user's password for decrypting the key, then it is also possible for that script to send a copy of the password and/or decrypted key back to the server. You have to have a certain level of trust in the service provider that they won't do this. But, that is exactly what HushMail did, and they were forced to snoop the credentials of some specific users in order to turn over unencrypted emails to the authorities.

It's also, unfortunately, the approach taken by services like LastPass when you log in via the website, rather than the extention, or use their security check tool. Users have to trust that LastPass is never going to send any javascript for the purpose of stealing their credentials. But they could certainly do so if they were ordered to. They could theoretically even direct this malicious version of the script to a specific IP address or user account, so no-one else could possibly notice it.

But, let's assume you've solved the key storage problem and you have enough trust in the service provider to believe their scripts that they are sending you are not malicious, the next problem is that by having all mail encrypted, you basically lose all ability to search your email. You're limited exclusively to client side searching, and performing that in the browser is completely infeasible. You would have to download all encrypted mail from the server, decrypted it, index it and search it all with javascript, which runs in a single process in a web browser. Good luck solving performance issues with that.

The only way to solve this problem would be to run your own trusted private server with which you can entrust your private key, so that it can store, index and search all your mail for you, where you would have to be running your own private instance of a "webmail" service. But for all intents and purposes, doing that is, from the perspective of your email service provider, functionally equivalent to you running a standard IMAP client and receiving PGP encrypted mail.

I can see how this might be more heavily encrypted... But wouldn't this only encrypt what you send yourself? How does this help if all other mail server on the planet would send you plaintext when email is travelling through them?

I agree with philhanson. Still, we need to be a population passionate about its privacy before a secure email service will gain traction. And unfortunately, the momentum is pushing that. It won't matter that a secure email service is easy to use unless it can simultaneously be "cool".

Well he's correct, as usual (Moxie never really gets this stuff wrong). Their mistake was trusting SSL/TLS for anything. There has simply got to be a better way that doesn't rely on sketchy ass CAs. I know Moxie tried an implementation in FF that bypassed the CAs altogether (Convergence.io). I liked it as a proof of concept, but removed it after it stopped working. Now if we could, perhaps with something other than Convergence, achieve the "trust agility" that Moxie described when he launched the project, that would eliminate the CAs and the NS"we hate the US tech industry"A couldn't steal your SSL key, because there would be no key to steal.

I agree with philhanson. Still, we need to be a population passionate about its privacy before a secure email service will gain traction. And unfortunately, the momentum is pushing that. It won't matter that a secure email service is easy to use unless it can simultaneously be "cool".

I think the only real problem is that encryption good enough that the provider can never read your email means that Gmail can't serve targeted ads to you, and people have come to expect that email is free. You have to convince people that the encryption really is sound and that privacy really is worth paying for.

A few weeks ago Leo Laporte had Ladar Levinson on his Podcast Triangulation. I suggest you listen to this, as Ladar gets somewhat technical on how and, more or less why, he had given his SSL keys to the FBI and what has been done since then.

"Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world."

Sure it is. Anything a stand-alone client can do, a browser can do. You just have to do all the crypto client side, in the browser, and never give your keys to the server, but rather carry them with you yourself from machine to machine.

For a long time I used email on Linux. When the SPAM got too bad I wrote my own SPAM filter. But it was a never ending arms race. I had to constantly update my SPAM filter. I finally gave up, got an account on GMail and changed the MX records to forward my email. GMail has an excellent spam filter. Although every spammer in the known Universe has my email address, I rarely see any SPAM. Without the GMail filter I could not use email.

Perhaps the point here is to use this crypto-email only for other encrypted email and all free text email would be rejected. But then you'd have to have too email accounts, one for common open text email and one that was only used for encrypted communication.

Most people are not going to go to this trouble. You would have to have something really covert to say. A more usable course would be to have email that can do both encryption and open text. But then this runs into the SPAM problem.

For a long time I used email on Linux. When the SPAM got too bad I wrote my own SPAM filter. But it was a never ending arms race. I had to constantly update my SPAM filter. I finally gave up, got an account on GMail and changed the MX records to forward my email. GMail has an excellent spam filter. Although every spammer in the known Universe has my email address, I rarely see any SPAM. Without the GMail filter I could not use email.

Perhaps the point here is to use this crypto-email only for other encrypted email and all free text email would be rejected. But then you'd have to have too email accounts, one for common open text email and one that was only used for encrypted communication.

Most people are not going to go to this trouble. You would have to have something really covert to say. A more usable course would be to have email that can do both encryption and open text. But then this runs into the SPAM problem.

I went to see Levinson speak at CNET a couple weeks ago. He seemed to consistently conflate Diffie-Hellman with perfect forward secrecy.

My understanding is that PFS uses a variant of DH, while normal DH is otherwise is used all over the place in normal public key crypto systems.

PFS isn't a protocol, it's a property that a protocol might have.

DH is the key-exchange method used by OTR (Off the Record), which is the probably the most common/well-know protocol that provides PFS. Other protocols with other key-exchange methods may also provide PFS.

Is the kind of ideal security being asked for in this article even possible with email? I was under the impression that email is fundamentally insecure

The metadata is fundamentally insecure as long as we continue using the SMTP. PGP is pretty sound for encrypting the contents, but has to be performed entirely on the sender's computer, and the recipient has to also use PGP, which is more complicated than most people are willing to put up with.

Is the kind of ideal security being asked for in this article even possible with email? I was under the impression that email is fundamentally insecure

Email, as it currently exists, is fundamentally insecure. I think part of the point is that we need to work on that.

Think about it like this: snail mail is secure so long as no-one takes the effort to look at it between you and the sender. The same holds true for email.

If you want secure snail mail, the most secure way is to cipher it. But when you do that, you have to be able to securely exchange keys; say, basing the cipher around the same printing of a book.

The same is basically true of email: it can be secured, but there are additional steps. And people won't take those steps until they're easy, something as simple as checking the "encrypt email" option in an email client.

That _is_ possible...just not under the current email system. Unless people suddenly get up in arms about email security, it's going to be a long and painful transition.

Interesting. So, did Snowden (he himself!) not understand this either? A chink in the all-knowing armor? Doesn't really matter, but it's interesting. When things are laid out as they are in this article, it seems obvious. No one understood this service until today? Odd, that.

None of this matters until an implementation is created which is as easy for people to use as Gmail. IE. Not needing a FAQ or detailed, multi-page instructions for setting up email with encryption.

Maybe you don't like what the NSA did, but the fact is we don't really know what they were after or why and whether they had probable cause or not. I definitely don't like it that under the current laws, they didn't need it, and that's definitely a problem.

But that does not excuse Lavabit for tricking their customers into thinking they were getting secure email when Lavabit was either completely incompetent or intentionally committing fraud.

If what the article says was is true, not only should Lavabit be shut down, but its principles AND its programmers should be going to jail for fraud.

A few weeks ago Leo Laporte had Ladar Levinson on his Podcast Triangulation. I suggest you listen to this, as Ladar gets somewhat technical on how and, more or less why, he had given his SSL keys to the FBI and what has been done since then.

None of this matters until an implementation is created which is as easy for people to use as Gmail. IE. Not needing a FAQ or detailed, multi-page instructions for setting up email with encryption.

Maybe you don't like what the NSA did, but the fact is we don't really know what they were after or why and whether they had probable cause or not. I definitely don't like it that under the current laws, they didn't need it, and that's definitely a problem.

But that does not excuse Lavabit for tricking their customers into thinking they were getting secure email when Lavabit was either completely incompetent or intentionally committing fraud.

If what the article says was is true, not only should Lavabit be shut down, but its principles AND its programmers should be going to jail for fraud.

In fairness to Lavabit, I don't see any difference between their claims and the representations Apple has made about its purported inability to read people's iMessages. At one level, the problem here involves the semantics and what the word "can't" means.

In any event, I think it's hyperbolic to suggest anyone from Lavabit has committed fraud.

A few weeks ago Leo Laporte had Ladar Levinson on his Podcast Triangulation. I suggest you listen to this, as Ladar gets somewhat technical on how and, more or less why, he had given his SSL keys to the FBI and what has been done since then.

I disagree with the premise of this article a bit, especially after hearing Ladar Levinson talk directly about the issue. I got the impression the media has been putting words in his mouth, other people claimed Lavabit is secure. He never did.

He was quite clear that Lavabit was never intended to be as secure as a proper solution like PGP. He just wanted his service to be something customers could trust as being as secure as can be done without huge usability compromises.

Also, from the sounds of it he has some ideas how to actually achieve PGP-level security in a future version of Lavabit, which might be open source and something you run on your own server. He didn't go into many details, but it sounds interesting.

None of this matters until an implementation is created which is as easy for people to use as Gmail. IE. Not needing a FAQ or detailed, multi-page instructions for setting up email with encryption.

Webmail in its current form didn't spring forth from nothingness. There were decades of shitty clients/servers requiring FAQs and detailed multi-paged instructions to setup and connect to the wider world.

I understand you may be disappointed because you don't think you'll see anything with enough critical mass to be usable in your life time, but this DOES matter and IS important because it lays the foundation for the free super easy encrypted email of the future.

Implementing an easy-to-use encrypted messaging application is a considerable challenge. I took on that challenge in 2009 and my site, ThreadThat, is still running today. My goal was to create something that anyone could use - without reading a manual or installing anything. I believe I accomplished what I set out to do. What I learned, however, is that there are relatively few email users who either understand the risks of not encrypting or would change anything even if they understood the risks. I offer my site for free because it is not worth the effort for such a small user community. Because I don't charge anything I cannot afford to advertise. So, people find the site via searches and word-of-mouth. My implementation is very similar to that of Lavabit except that shared content never passes through a mail server. Making the site easy-to-use required "user trust". All encryption/decryption is done server-side. All users must trust that the code is doing what the FAQ says it is doing. Any nefarious programmer could create a site that claims to do A, B, and C, and then actually does D. All they need to do to be successful is get some well known, respected, site to mention the service and many people will "believe".

I created ThreadThat with good intent. I am not a nefarious programmer. But why should anyone believe that my site is not a CIA honeypot? This is the challenge. Users must trust "me" without ever having met me. I am convinced that the site will never be mainstream, but since my hosting provider has donated a VPS to run the site, I will continue to support it and make it better. Although I applaud their efforts, I cannot imagine widespread adoption of encrypted email in my lifetime. That's just my opinion.

In fairness to Lavabit, I don't see any difference between their claims and the representations Apple has made about its purported inability to read people's iMessages. At one level, the problem here involves the semantics and what the word "can't" means.

While this may be technically true, the difference is that Apple never used iMessage's security as a selling point - iMessage had been out for two years (?) or so before Apple made its one-off comment about iMessage security.

Lavabit, on the other hand, existed only to provide secure e-mail. Quoting the immortal John Goodman, that was it's goddamn raison d'etre. Lavabit talked extensively about the security of the their e-mail, and their encryption, and the reason for using encryption. So I think that they should be held to a much higher standard.

Lavabit, on the other hand, existed only to provide secure e-mail. Quoting the immortal John Goodman, that was it's goddamn raison d'etre. Lavabit talked extensively about the security of the their e-mail, and their encryption, and the reason for using encryption. So I think that they should be held to a much higher standard.

Their website is offline now, so it's hard to know exactly what they said (I never used the site before they shut down), but wikipedia has this:

"Lavabit was founded by Texas-based programmers who formed Nerdshack LLC, renamed Lavabit LLC the next year, allegedly prompted by privacy concerns about Gmail, Google's free, widely used email service, and their use of the content of users' email to generate advertisements and marketing data."

Lavabit absolutely achieved it's stated goal of keeping your data out of the hands of advertising companies. There were no false claims.

"Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world."

Sure it is. Anything a stand-alone client can do, a browser can do. You just have to do all the crypto client side, in the browser, and never give your keys to the server, but rather carry them with you yourself from machine to machine.

(For broad values of "can" and "just".)

I think his point was that if a server can be compromised, then the crypto software you load from that server can be compromised, too. Any solution to this dilemma would either be too much work for the average end user, or the result would not resemble what we typically consider to be a web application.

Lavabit was virtually unknown to most internet users up until they shutdown. Then they magically reincarnated themselves for 72 hours, and after that asked for $200,000 in donations for "dark mail" but in reality who knows the money is for. Now we find they weren't exactly honest about their security?

They've found a great way to get free publicity and free money, but considering the few facts I mention above, why would anyone trust them with a dollar let alone private and secure email?

Is the kind of ideal security being asked for in this article even possible with email? I was under the impression that email is fundamentally insecure

The metadata is fundamentally insecure as long as we continue using the SMTP. PGP is pretty sound for encrypting the contents, but has to be performed entirely on the sender's computer, and the recipient has to also use PGP, which is more complicated than most people are willing to put up with.

Yes, but encryption can easily be built into email clients and email can then be encrypted and signed. The only thing that needs to be unencrypted is the to address.

Lavabit, on the other hand, existed only to provide secure e-mail. Quoting the immortal John Goodman, that was it's goddamn raison d'etre. Lavabit talked extensively about the security of the their e-mail, and their encryption, and the reason for using encryption. So I think that they should be held to a much higher standard.

Their website is offline now, so it's hard to know exactly what they said (I never used the site before they shut down), but wikipedia has this:

"Lavabit was founded by Texas-based programmers who formed Nerdshack LLC, renamed Lavabit LLC the next year, allegedly prompted by privacy concerns about Gmail, Google's free, widely used email service, and their use of the content of users' email to generate advertisements and marketing data."

Lavabit absolutely achieved it's stated goal of keeping your data out of the hands of advertising companies. There were no false claims.

If i were a customer i would demand total refund . Because they not only lied about their own service with those fraudulent and deceiving claims , they also made inaccessible the data for their own customers .

Really, stop with the victimization of this company and its CEO. All this melodrama is getting too cheesy

The increasing centralization of networked services places user data at considerable risk. For example, many users store email on remote servers rather than on their local disk. Doing so allows users to gain the benefit of regular backups and remote access, but it also places a great deal of unwarranted trust in the server. Since most email is stored in plaintext, a compromise of the server implies the loss of confidentiality and integrity of the email stored therein. Although users could employ an end–to–end encryption scheme (e.g., PGP), such measures are not widely adopted, require action on the sender side, only provide partial protection (the email headers remain in the clear), and prevent the users from performing some common operations, such as server–side search.

To address this problem, we present Secure Searchable Automated Remote Email Storage (SSARES), a novel system that offers a practical approach to both securing remotely stored email and allowing privacy–preserving search of that email collection. Our solution encrypts email (the headers, body, and attachments) as it arrives on the server using public–key encryption. SSARES uses a combination of Identity Based Encryption and Bloom Filters to create a searchable index. This index reveals little information about search keywords and queries, even against adversaries that compromise the server. SSARES remains largely transparent to both the sender and recipient.

Lavabit, on the other hand, existed only to provide secure e-mail. Quoting the immortal John Goodman, that was it's goddamn raison d'etre. Lavabit talked extensively about the security of the their e-mail, and their encryption, and the reason for using encryption. So I think that they should be held to a much higher standard.

Their website is offline now, so it's hard to know exactly what they said (I never used the site before they shut down), but wikipedia has this:

"Lavabit was founded by Texas-based programmers who formed Nerdshack LLC, renamed Lavabit LLC the next year, allegedly prompted by privacy concerns about Gmail, Google's free, widely used email service, and their use of the content of users' email to generate advertisements and marketing data."

Lavabit absolutely achieved it's stated goal of keeping your data out of the hands of advertising companies. There were no false claims.

If i were a customer i would demand total refund . Because they not only lied about their own service with those fraudulent and deceiving claims , they also made inaccessible the data for their own customers .

Really, stop with the victimization of this company and its CEO. All this melodrama is getting too cheesy

Thanks for the link to archive.org. What "fraudulent and deceiving" claims did they make? The homepage never even mentions encryption, only privacy. If you drill down into the site the strongest claims they make are:

* "we support and encourage the use of Secure Sockets Layer (SSL) encryption."* "once a message is stored on our servers in this fashion, it can’t be recovered without knowing a user's password."

All of that is perfectly reasonable and clear.

I've heard they are going to issue refunds, but they're waiting a bit longer first, because there is still a chance the court will quickly rule in their favour and allow them to bring the site back online in the next month or so.

Mailpile: Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world. The first precondition for developing a usable and forward secure e-mail protocol is a usable mail client, and I currently believe that Mailpile is our best shot at that.

I don't quite get what he is saying here. "Secure webmail is not possible, thus I recommend this webmail client." I'm obviously missing something.

Lavabit, on the other hand, existed only to provide secure e-mail. Quoting the immortal John Goodman, that was it's goddamn raison d'etre. Lavabit talked extensively about the security of the their e-mail, and their encryption, and the reason for using encryption. So I think that they should be held to a much higher standard.

Their website is offline now, so it's hard to know exactly what they said (I never used the site before they shut down), but wikipedia has this:

"Lavabit was founded by Texas-based programmers who formed Nerdshack LLC, renamed Lavabit LLC the next year, allegedly prompted by privacy concerns about Gmail, Google's free, widely used email service, and their use of the content of users' email to generate advertisements and marketing data."

Lavabit absolutely achieved it's stated goal of keeping your data out of the hands of advertising companies. There were no false claims.

If i were a customer i would demand total refund . Because they not only lied about their own service with those fraudulent and deceiving claims , they also made inaccessible the data for their own customers .

Really, stop with the victimization of this company and its CEO. All this melodrama is getting too cheesy

Thanks for the link to archive.org. What "fraudulent and deceiving" claims did they make? The homepage never even mentions encryption, only privacy. If you drill down into the site the strongest claims they make are:

* "we support and encourage the use of Secure Sockets Layer (SSL) encryption."* "once a message is stored on our servers in this fashion, it can’t be recovered without knowing a user's password."

All of that is perfectly reasonable and clear.

I've heard they are going to issue refunds, but they're waiting a bit longer first, because there is still a chance the court will quickly rule in their favour and allow them to bring the site back online in the next month or so.

Mailpile: Despite what anyone tells you, end to end encrypted e-mail is not possible in a webmail world. The first precondition for developing a usable and forward secure e-mail protocol is a usable mail client, and I currently believe that Mailpile is our best shot at that.

I don't quite get what he is saying here. "Secure webmail is not possible, thus I recommend this webmail client." I'm obviously missing something.

I agree with philhanson. Still, we need to be a population passionate about its privacy before a secure email service will gain traction. And unfortunately, the momentum is pushing that. It won't matter that a secure email service is easy to use unless it can simultaneously be "cool".

Not everyone will go to college for an IT security degree. We need people who are interested enough in it (or paranoid) to help provide the service. That's why we pay for it. An open-source implementation that can be used by people who only know a little bit about web design is even better.

You've got to see a need before you can fill a need, whether for security or piracy.