New, Privacy-Oriented, FOSS Web-mail: Mailpile 116
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."
antiquated system (Score:2, Interesting)
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.
Re: (Score:1)
> make a better protocol
what protocol or protocol changes do you propose?
Re:antiquated system (Score:5, Funny)
what protocol or protocol changes do you propose?
In this day and age, isn't that obvious? We need to listen to what the majority of the computing public wants. It should be:
* Proprietary, closely controlled by a single large company
* All email must go through their servers.
* Have unavoidable advertising added to all emails.
* The protocol must be centralized rather than distributed
* The possibility to run your own servers should be removed.
* It should be limited to very short messages of no more than a few lines.
* It should only be available on locked-down devices
Most people have succeeded in getting some of those features by using gmail, but we're not all the way there yet, so there is still room for improvement.
Re: (Score:2)
Re: (Score:2)
Re:antiquated system (Score:5, Interesting)
I've been considering a kickstarter for a new version of SMTP, while at least for the moment leaving IMAP alone. Specifically, the way headers are appended to mail in transit is unsupportable in a secure environment. The things I'm considering is that there doesn't have to be a flag day, you just need the vendors of several heavily used MTA's to support it as an option, then once 99% (or whatever number your company deems appropriate) of your email uses the new format you turn off the old.
This was poopoo'd in the past because there were 10s if not hundreds of thousands of email servers. Now people have pretty much stopped hosting most email and turned it over to google, yahoo, microsoft or one of the other major players. Therefore you're no longer faced with trying to get everyone to change things. You only need 5 major companies to change, and hopefully they're interested in the new protocol as well (nobody likes SMTP as it is, the question is can you get everyone to agree to some consensus of next generation email then move forward with it)
DJB's pull based email thing could be a part of this, maybe not the exact idea but something along those lines:
DJB's IM2000 (http://cr.yp.to/im2000.html). While I don't think all mail should be stored on the originating server, I think a mix could be used to provide more flexibility. Mailing lists could leave all the mail on the server, since a bunch of readers never read every message there isn't a point of exploding it out to thousands of mailboxes (except for reliability, and that could be gained by mail->nntp for public mailing lists)
Requiring domain keys could also be useful, since headers wouldn't be modified, just appended and signed.
If people are interested in crypto/privacy aspects, emails that aren't delivered but instead picked up by the recipients don't leak metadata like To, From.
It's probably best to approach this through the IETF, despite failures to make broad sweeping changes in the past, a new working group might be the best choice to get the interested parties involved.
Tangent here:
I also think that email clients need to be brought back and worked on. Thunderbird died because of two reasons: 1. Mozilla couldn't find a way to monitize it, and 2. Their biggest email competitor (gmail) and biggest contributor (google search) had already found a way to monetize email and thunderbird wasn't seeing significant updates at that point.
Other stuff I'd like to see in thunderbird:
Contact pictures on email (not something I think I would use, but nice for people used to facebook/twitter/etc). Integrated IM/Skype/Phone so you can effortlessly change the medium you're communicating through. Also the ability to send calendar events through IM or SMS would be nice.
Real synchronization. That includes plugins and every setting via a service like weave that is secure. This would also sync your passwords and gpg keys. Actually a generic weave-like framework that could be integrated with pidgin, thunderbird and other open source apps to sync across machines would be great. That would also fix major issues with pidgin's OTR.
So the reason I never kickstarted it is the same reason Mozilla doesn't work on thunderbird anymore. I have no idea how to monetize it in a way that would be long term sustainable. Users hate adds, they hate paying for software. Maybe an addon store, but that just means you're subbing the good development work to other people and then making the users pay to fix the things wrong with your app.
Re: (Score:3)
Given that most large E-mail providers add massive amounts of privacy-invading info to E-mail headers (like the IP address where you wrote the message), I doubt the problem here is a limit on technology.
For monetizing, though, there's a simple solution: sell whatever you come up with embedded in a piece of hardware. A self-maintaining "E-mail plug" you just connect to your home network lets you charge for the software as part of the hardware. Other companies have been doing that, for example the Tonido Plug
Re:antiquated system (Score:5, Interesting)
Mail clients died because webmail is more convenient for most people. I had been using mail clients since I first got online but then I went on holiday and decided to just use Gmail for three weeks. I realized it wasn't that bad and never bothered to go back to Thunderbird.
Re: (Score:2)
Your comment is rated 5 and you deserve that because you're hitting upon probably the most single important thing that will block these guys from wide spread usage if they finish writing everything. I'm going to go a step further. You cannot have secure email if you do not have a client and operating system that you can trust. Today's environments are migrating to a place where we can not trust that our emails are not intercepted and read even if we're told it is secure. If we go online and read our ema
Re: (Score:3)
I have talked about the same goal several times, but any new system must be backwards compatible because there are around 14 million (SWAG) businesses that rely on free SMTP.
While you're chewing on that, Thunderbird is absolutely critical in that process. Most businesses don't want to think about email, calendaring, and shared address books but they get that with Exchange and Outlook. I've been interested in moving our company off of Exchange for some time but we're addicted to Outlook and need a simple to
Re: (Score:2)
The problem with Bitcoin (and blockchain based currencies) is that they don't really deal well with microtransactions. Since each transaction has to be sent and confirmed by a bunch of nodes, they impose a lot of strain on the miners. Eventually we should see rising transaction fees, which will probably kill such systems.
Re:antiquated system (Score:5, Insightful)
No need to replace SMTP. Just add "more" stuff on to it. Not necessarily on top of other extensions, feel free to supersede them. But you need to support SMTP for the foreseeable future, and it's kind of nifty to have such a dirt-simple interface to mail for those cases in which it is useful, such as inside your organization for alerts and whatnot. I don't automate anything based on email these days, but it's still not useless.
Re: (Score:2)
I think there's a big problem here that isn't really about protocols or technical matters. Taking a step back from specific proposals for replacing protocols, part of the problem is that we can't agree on a vision for email in the future. Some people want really complicated formatting and media embedding, while others want to return to a text-only world with attachments. Most of us want to do away with spam, but lots of big companies still want to be able to market to us through email. Some people want
Re: (Score:2)
I'm not sure we need SMS, email, and IM as three different protocols of communication. Maybe we just need different interfaces depending on the situation in which we're using them, but they can all pass through the same communication gateways using a consistent protocol.
This is something I've thought about fairly often as well. It seems like someone could come up with a standard for this and then implement it in an enterprise solution, which if adopted would then drive demand for open and interoperable implementations.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You seriously underestimate the number of small and medium sized businesses who run their own email servers.
Re: (Score:1)
There you go. Let's tie e-mail to Facebook.
Users hate paying for SHITTY software. Write software that isn't SHITTY and you'll have no problem monetizing it.
Free clue: tying e-mail to Facebook = shitty. Have a nice day.
Leave e-mail alone.
Re: (Score:2)
Therefore you're no longer faced with trying to get everyone to change things. You only need 5 major companies to change, and hopefully they're interested in the new protocol as well
Umm.. there is something in the region of half a billion corporate mailboxes in MS Exchange alone, per estimated done by the Raticati Group a few years ago ( and I'm sure it was on Slashdot that I read it ). That's more than any one webmail vendor.
Re: (Score:1)
Re: (Score:2)
If you make something else, that's great. But it won't be email. The adoption rate will be very low.
Re: (Score:1)
Email was around long before SMTP and will be around long after SMTP and all of it's anachronisms are dead and buried.
"whois" makes a good point above -- most of the world's mailboxes are controlled by Google, Microsoft, and Yahoo. (Plus IBM/Lotus and a few other providers) If only three key people start talking, the entire email infrastructure could be replaced within a few years.
Re: (Score:3)
That email has been around for a long time doesn't automatically mean it's "antiquated" or in need of a rewrite. It fulfills the most important goals:
-- send & receive messages over a secure connection
-- use any client we want, whether local, networked, web, in a remote shell...
-- read & send when it's convenient (non-live)
-- email back-and-forth right away (eg. if chat services aren't allowed)
-- style the letter as a document via WYSIWYG editor or hand-coded HTML
-- or send plain text, no formattin
Re: antiquated system (Score:2)
That happened in the past, too, and then we got sendmail - the middleman between all of them. Writing sendmail.cf by hand was a rite of passage! Over time SMTP appeared as the winner, which enabled far simpler tools to emerge on the server side and more powerful clients to send mail directly.
Re: (Score:2)
>-- send & receive messages over a secure connection
What definition of secure are you using? Current protocols make no guarantee that mail will be delivered at all, and transmit everything as clear text which makes interception and/or manipulation trivial for anyone so inclined. You may be using an encrypted link between your terminal and server, but from that point on everything is plain text, so it's really only your password which is secure (a big step up from when that was plain text as well, b
Re: (Score:2)
TLS.
Re: (Score:2)
TLS is fine until you reach the MTA. Then you have no guarantee that the message won't be passed as plain text. And even if TLS is used on each hop (unlikely), you still don't have a real end-to-end secure connection, just a chain of many connections, with middle men who can see all the emails.
Re: (Score:2)
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.
People who find it intolerable for those reasons that are already using whatsapp, etc
Re: (Score:2)
So good luck on getting a new something new that helps the consumer in anyway.
Re: (Score:1)
The real problem is that email is antiquated, are far more complicated than it needs to be. I
Yes, it would be much better if it was like all the recently developed IM protocols:
"See you on kik?"
"No, can't, sorry I use yahoo."
"I can't either... I'm on skype."
etc
Email is one thing: standard. Everyone on every type of device can use it. And what in the hell do you mean by "far more complicated than it needs to be?" I agree the protocol could be improved, but complicated? You enter the recipient's email address, or more likely just click it from your address book, type your message, and push "send"
Re: (Score:1)
And what in the hell do you mean by "far more complicated than it needs to be?" I agree the protocol could be improved, but complicated? You enter the recipient's email address, or more likely just click it from your address book, type your message, and push "send". How much easier can it get?
i guess he means complexity of setup: to use an email client you have to point it to a mail server. for a vast majority of users this simple concept is one too much if they can simply log into gmail and not have to worry about shit.
Re: (Score:2)
It gets worse. I'm starting to see people who started out using webclients like yahoo, but are increasingly failing to grasp the www itself. When their cheap smartphone breaks Facebook (which has PM-esque emails)*, they have no idea how to pick up their ball on the webbrowser, and that they can just enter their credentials there. The level of lock-in is ridiculous, because people cannot tell the difference between the App and the web version of anything, other than "ooh, I like it on my phone better..." Sim
Re: (Score:2)
Not in the least. Just because you don't have an attention span long enough to read past a 4 word tweet doesn't mean the rest of us doesn't.
Sure, email isn't appropriate for everything ( never was, that's why god made telephones and meetings ) but its still appropriate for many things, especially in the business world.
Re: (Score:2)
Email is precisely as complicated as it needs to be.
Self Host with Roundcube (Score:4, Informative)
Or you could run Roundcube [roundcube.net] 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.
Re: (Score:2)
GPG/PGP support has been worked on a few times. This is one of the latest attempts:
http://lists.roundcube.net/pipermail/dev/2013-January/022123.html [roundcube.net]
Re: (Score:2, Flamebait)
Re: (Score:1)
PHP is not the problem with rcmail or squirrelmail or any of the other freely available web-based email systems, most of which run on PHP or even better, ASP or ASP.NET. They are their own problems. None of them are half as usable as gmail. Some of them are almost half as usable as a typically bad desktop email client. But PHP is not even a slight impediment, because you don't need anything out of PEAR or what have you in order to run any of these. You just need typical modules dealing with mail, e.g. imap.
Re: (Score:2)
Are there any remote hosts you can really trust? Sounds like the NSA/GCHQ have their claws into pretty much everything and are good at leaning on companies to silently comply with their demands.
Re: (Score:2)
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.
More powe to them, but... (Score:5, Interesting)
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.
Re: (Score:2)
The first has a now-standardized solution in the shape of TOR.
That's assuming the feds aren't running a sufficiently large amount of TOR nodes such that the chances they will have enough nodes on a route to compromise anonymity are fairly high.
Re: (Score:3)
Re: (Score:2)
Well, enigmail isn't that great. It hung when my wife tried to generate her key. Also, when I send her my public key, it didn't recognize it (I sent it as a .asc). It also adds some bogus "begin encrypted mail" headings around the encrypted text.
And It actually was a hassle to get working.
Re: (Score:2)
It has never been claimed that encryption is an anonymization solution.
Re: (Score:3)
Just attach your public key to every outgoing email, and then clients that support it can automatically collect and start using it.
Re: (Score:2)
And how does that client know the key hasn't been replaced by someone else's? Yes, the message can be signed. But if you don't have the key, you can't verify the signature either, so that can be faked too.
Re: (Score:2)
In that case the sender's email account is compromised. That isn't the problem encryption is designed to solve.
Re: (Score:2)
Or the email was tampered with in transit. The old key was stripped and a new key was added.
Of course every subsequent encrypted message will have to go through the man in the middle to avoid detection, but that's not too hard if they can tamper with the email in transit in the first place.
This part right here is really the hardest part of proper encryption. Secure key exchange is hard. Secure in-channel key exchange between clueless users is nearly impossible.
Re: (Score:2)
That's why if you really care about identity you either exchange keys in person or verify with a third party that you trust. Your scenario also requires the MITM to intercept the very first message containing a copy of the public key, or it will be obvious that at some point the key changed and the client software should flag that up.
The point here is not really to verify identity, it is to encrypt email end-to-end. GCHQ and the NSA don't care much because they already have root access to the webmail server
Re: (Score:1)
PKA works now, but the clients have to be told to use pka manually, so its of limited value in its current state until adoption gets a little wider. Sadly leaves GMail and friends out in the cold (unless th
Using existing services as a transport layer? (Score:2)
Bitmessage (Score:1)
Anyone following such developments should look into bitmessage [bitmessage.org]. An encrypted p2p messaging system that takes the complications out of using tools such as GPG.
Some nice ideas, but... (Score:2)
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.
Re: (Score:2)
Running your own server is what everybody used to do before Google gave people the offer of free unlimited storage that they couldn't refuse.
I don't know about everybody, but most of the people I know (including me) started with the ISP-provided email, then moved to Hotmail or Yahoo and finally to GMail.
Re: (Score:2)
What if I mail you some kittens? Wouldn't you want big pile of cute little kittens?
Re: (Score:2)
Not sure who the market is here? (Score:5, Interesting)
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.
Re:Not sure who the market is here? (Score:5, Interesting)
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.
An answer to that is that even though only 0.1% of users can read source code, ...
Given this, it's quite likely that if an open source tool contains malicious code, and it is widely used, this will be revealed eventually. Of course there is no 100% guarantee. But this claim is far from worthless. You can have much higher confidence that an open-source tool does not have hidden snooping compared to closed-source, and this even if you can't or won't read the source code yourself.
Where in hell are you getting these numbers? (Score:2)
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.
Re: (Score:2)
Very well. How about this [wikipedia.org]: 100% know somebody who knows somebody who knows somebody who knows somebody who knows somebody who knows somebody who can read code.
Incidentally, I wonder how many degrees of separation in the meta-data it takes for the NSA to consider someone suspicious.
Re: (Score:2)
Knowing how to "code" isn't enough, you need to study the codebase. A tiny fraction of those who know how to code have studied the mailpile codebase enough to catch a backdoor. I would say, practially speaki
Re: (Score:2)
Knowing how to "code" isn't enough, you need to study the codebase. A tiny fraction of those who know how to code have studied the mailpile codebase enough to catch a backdoor. I would say, practially speaking... 0 outside the core developers.
Right now, you're probably right. As far as I can see it's not much used yet. But as usage grows, so would the number of contributors looking at the code, to add a new feature of fix a bug, each time increasing the chance malicious code or vulnerability would be found.
Backdoors or snooping are best hidden with plausible deniability. Even if you discover one, it won't be obvious that it was intentional, it will be no more newsworthy than a typical vulnerability report.
Right. Open source does not magically guarantee the absence of vulnerabilities (accidental or intentional). But it makes them easier to detect by the community, and harder to hide malicious code. Take the snooping revealed to be happening in
Re: (Score:2)
Re:Not sure who the market is here? (Score:4, Insightful)
I disagree that the normal user has accepted their email is not secure. I'm fairly certain that most normal user's have no idea that email is insecure.
Re: (Score:2)
Re: (Score:1)
If you use "cloud" e-mail and Facebook you ain't no geek, son.
Re: (Score:1)
The biggest obstacle to a true email replacement is every online registration under the sun already requires email as we already know it, but offers no alternative, for account communication. Until Facebook logins, which are probably far worse in the long run.
No, what we need is a system of encryption-required communication and a way to proliferate keys in a way that they can be confirmed in some way instead of sent as attachments that could be as false as what they're attached to. And we definitely need
Who hosts? (Score:2)
That is still a security problem. You want end-to-end encryption on the client, and not store it somewhere else, even encrypted.
Re: (Score:3)
"Self Hosted
Mailpile is a modern web-mail you run on your own computer.
You can host your install of mailpile on your laptop, desktop, Raspberry PI or a server in the cloud. Or put it on a USB stick and carry it in your pocket. It's your choice."
From the front page of their site.
I note that antispam is "under development" (Score:2)
Re: (Score:2)
^^^^^^^ THIS!
18 years ago, my work email was pretty much spam free, and my private email was 50% spam. Fast forward to today, and my private email is **totally** spam free, and my work email is deluged (90% spam). Why? Because gmail reads millions of emails and filters better due to comparing people's mail, whereas my work email only has a small pool of mail messages to work with.
While I like the concept of email security, I am unwilling to part with "spam free" service.
Privacy-enhanced mail (Score:2)
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 [ietf.org] 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 outpu
Re: (Score:1)
Two things to be aware of (Score:2)
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 st