Slashdot Mirror
New, Privacy-Oriented, FOSS Web-mail: Mailpile
New submitter Juggler writes "Mailpile, a new Free Software project out of Iceland, launched at the #OHM2013 hacker festival in Holland today. The talk's brief demo garnered rounds of applause and was followed by the launch of an Indiegogo campaign which, if funded, will allow them work full time on building a modern e-mail/web-mail client. The team's main goals are to address the usability issues that prevent non-technical folks from taking advantage of secure e-mail today, bring new life to FOSS e-mail development and provide a realistic alternative to keeping e-mail in the cloud."
The real problem is that email is antiquated, are far more complicated than it needs to be. Instead of bolting a new face on it, make a better protocol.
Or you could run Roundcube on a host you trust. Setup Postfix to use TLS to send/receive mail from your trusted friends who also run their own email systems.
There are a couple of tough problems to solve. One, defeating traffic analysis. Encryption is just a first step. Encrypting everything, no matter how trivial, will be important, and certainly helps, but it's not enough to keep listeners from knowing who is talking to who.
Second, bringing the public at large into the fold. Noone will use an email system that can't be used to send email to all their friends and family, most of which aren't going to be switching anytime soon. One thing that might help is a system that automatically knows when the recipient is encryption-capable, encrypts when it is, but when it's not, inserts a warning message that their email is not secure and may be stored by third parties and governments-- essentially an advertisement for switching to a more secure email system. This would help us all educate our friends and keep them reminded every time they get an email from us as to the issues. It could help convince them that it's worth switching.
Anyone following such developments should look into bitmessage. An encrypted p2p messaging system that takes the complications out of using tools such as GPG.
How many users would really able to use this? Running your own server seems kind of extreme for the average user, and setting up maildir seems like a non-starter.
There's no -1 for "I don't get it."
What if I mail you some kittens? Wouldn't you want big pile of cute little kittens?
That already happens on the Internet. That's why it filled with cats. Email is no different. Cats cats cats!!!
Why is Snark Required?
Given that the average e-mail user has already accepted that their communications aren't secure, I have a problem visualising how said average user can be convinced that a 'replacement' for traditional e-mail is any more secure than the existing offering, or if said security even matters.
First, there's absolutely no way you can build trust. What are you going to do? Tell them it's secure because of X, Y or Z? The point here is that your average e-mail user doesn't understand encryption, PGP keys or any of that. It just translates as blah, blah, blah; give us your e-mail so we can snoop through it just the same as the other guys do. Oh? You can read the source code and confirm that it's all legit? The average user can't read source code! These claims are all worthless.
Second, if there's already an acceptance that having your e-mail open for analysis somehow prevents your child from being blown-up at a bus stop, you're not going to be very fond of encouraging the adoption of a product that could aid terrorism, let alone use it yourself.
So, if you can't build trust, and your potential user base can be put off your product by the spectre of terrorism, then what's your business model? If the user can't be convinced they'll have any more privacy without the expense of a potential surge in terrorism, there isn't one. You can only preach to a choir that would already be using PGP, etc. if they cared enough to do so.
But you can't even get widespread adoption in the geeks! Most of us use cloud e-mail services, Facebook, etc. and just don't care enough, let alone would ever truly trust your product, regardless of how transparent you attempt to make it.
tl;dr: there are better uses for the developers' time here than building a baseball field nobody will ever play on.
Agent: We're from the US government and we're here to help ourselves to your users data. ... Do you want to ftp back to my sever?
Admin: Their servers dead, that's what's wrong with it?
Agent: So it is. 'Ere's some money and a couple of holiday vouchers.
Admin:
Agent: I thought you'd never ask.
Domestic spying is now "Benign Information Gathering"
An answer to that is that even though only 0.1% of users can read source code...
- 5% know somebody who can read code;
- 30% know somebody who knows somebody who can read code;
- 100% know a newspaper who would publish the story if a single expert read the source code and discovered there is snooping hidden in it.
The geek's made-up stats do not inspire confidence.
They are worth the cheap instant mod up to +4 or +5, "Insightful" here.
That is still a security problem. You want end-to-end encryption on the client, and not store it somewhere else, even encrypted.
---- Booth was a patriot ----
I'll be deeply curious to see if they actually manage to produce a viable antispam solution. I find the thing that almost everyone walks past when talking about antispam is that it requires reading other people's mail. gmail takes advantage of economies of scale to notice that the same phrase is appearing repeatedly in multiple messages from different names, for example. Spammers are clever and will figure out ways past everything eventually, so I like to ask people if they're willing to trade infinite spam for total email privacy.
From the site, there's not enough info to tell what security properties this proposal has. Mostly, they're just begging for money.
It might not be that hard to do privacy-enhanced mail today. Both browsers and some mail clients (i.e. Thunderbird) accept plug-ins, so doing encryption and decryption on the client side is possible even for web mail. You could still use Gmail, but all Google would see are big strings of random-looking text. Your browser plug-in would decrypt that when displaying Gmail output. Of course, Google's indexing and ad matching wouldn't work.
The big problem is publishing and finding the recipient's public key. The 1993 PEM scheme wanted to do this with SSL-type certs, but that never caught on. Self-signed certs are vulnerable to man-in-the-middle attacks. But suppose that you published your public key on some social network (Twitter, Flickr, Facebook...) and your mail client checked your own key at random times. Then you'd detect if someone was messing with your public key. It's not airtight, but it's better than nothing, and any widespread tampering with public keys would be noticed.
None of this requires any cooperation from, or trust in, mail servers. It's entirely client-side, where it should be.
Flexible Funding
This campaign will receive all funds raised even if it does not reach its goal. Funding duration: August 03, 2013 - September 10, 2013 (11:59pm PT).
Second, there seems to be a bit of a contradiction on the timeline for this funding. The developers mention the following:
Our goal is to fund two to three man-years of full time work on Mailpile, with our first milestone in January 2014, when we will deliver an alpha version ...
Yet later they say (emphasis mine)
This is the Mailpile business model. As long as members of our community are willing to fund development (we will ask you to renew your membership in a years' time), we will dedicate ourselves to Mailpile and build the secure web-mail client you want.
Regardless of these inconsistencies, If they stick to the schedule then there should be a stable 1.0 release out during the first year of funding/development.
Following our alpha release, we will spend another 6-9 months fixing bugs, fleshing out features, responding to user feedback and getting the user interface translated to languages other than English. Our goal is to have a stable 1.0 release ready in the summer of 2014.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
Another sticking point is that most of my friends will just roll their eyes if they have to change their gmail or yahoo mail addresses. Even if everything else was painless, they don't like having to notify the whole known universe of the change. So what if whatever mechanism is used, it could be made compatible with gmail, etc. if they could be pressured to comply with it, or maybe even whether or not they are? If all everyone had to do was use a special client tied to the gmail api, similar to how the mail aggregator apps in, say iOS operate, and layer the encryption at least, on top? Maybe this is already the plan? Uses existing servers as transport but keeps the encription off the servers, etc...