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.
I wonder how long this project will run until it suffers the same fate that Hushmail did...
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."
I don't want my mail in a big pile.
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.
This is just another email client, is it not? From the original description it seems that they aspire to give everybody an email server - I am totally confused.
Somebody, please explain how this is better than Thunderbird with PGP!
Trouble with the certificate system is the NSA has access to the US Cert authorities and can man-in-the-middle encrypted traffic. The G20 meeting leaks suggested they'd done this for a lot of intercepts on world leaders.
I'd prefer the end to end first-key-exchange that SSH uses when you connect to a server.
1. Public keys are attached to all outgoing messages
2. When you receive an email with a key you can choose to accept the key as valid
3. Email to that recipient is now always encrypted with that key
4. They can send you their public key via a different route (e.g. USB key) and you can enter the key that way to ensure it has not been tampered with
5. If you receive an email with a different key, the client warns you of the potential intercept. You can confirm/reject the change of key by other routes (e.g. ring them up and ask them)
6. You can lock keys in place as trusted to reject all further fake keys if you are sure the key is correct.
7. The mailto HTML tag is extended to include the public key, so banks, governments etc can post their email addresses on https sites, not ideal since https can be MITM'd if the NSA/GCHQ has packet intercept ability on the route, but that would be at least as secure as a TLS connection.
8. Windows machines may not be trustable at this point, see the PRISM and SKYPE documents, and Microsofts liaison department helping the NSA solve any encryption problems they have attacking Windows PCs. So this email client should work on all Open Source OS's and should take steps to protect the keystore.
(since AC cannot upvote)
I'm still amazed that with all the focus on transport encryption nobody has focused on storage encryption. Why can't i give a public key to a email provider, and after receiving a email via TLS or alike they encrypt the email for me before storing. PGP is all well and good but the majority of my email that i wish to protect isn't from people who would USE PGP to encrypt it in the first place (think service providers etc). If someone wants to send me something that warranted encryption they certainly wouldn't use email.
Why do their screenshots show "1-5 of 2546", but then actually show 6 messages, not 5?...
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.
Make every unknown contact solve a CAPTCHA upon sending an email to you; that will kill the economics of spammers.
Leave it the fuck alone. The last thing we need is a room full of hornrimmed-glasses-wearing Haskell programmers humping some E-mail 2.0 inflatable doll and telling us how hot "she" is.
I can't think of a faster way to runaway piston-fuck society to death. SMTP is fine. Learn to use it before you start running your dumbfuck 19-year-old mouth about how things ought to 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...