Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
OpenMailBox: An alternative to Gmail based on free software (perseosblog.com)
59 points by vsrev on Aug 7, 2013 | hide | past | favorite | 27 comments


Some criticisms:

Firstly, this is basically a standard UNIXy virtual mail solution with RoundCube chucked on the top. Nothing special. Does not deserve the manifesto spew. You can get this solution canned by just installing this on your own kit: http://www.iredmail.org/ (or build it yourself). Or you can get it at WebFaction and many other hosters for a small fee. You can even stick it behind your firewall and IDS on your DMZ and rejoice!

I very much doubt anyone who throws this out in no time at all actually has the capacity or planning to operate a virtual mail system. I planned and ran an 80k-user (not many!) exim/cyrus outfit for an ISP and it was a full time job and it required some serious kit at the time. To give you an idea, we had 2 SMTP front ends, COTS NFS appliance for mailboxes, 2 IMAP servers, 2 web servers, tape library, 2 redundant LDAP servers, dedicated UPS etc. The lowest CPU at the time was a dual Xeon Pentium III. The whole thing was a full 42U rack and sucked up power. Even with the progress with virtualisation and storage etc, you're going to need big iron to shift email or run a free service like that.

I doubt the security of the solution. You don't know where it is hosted, there is no motivation (in the form of cash) to actually not puke your details everywhere, there is no SLA, the software may have been modified etc etc.

No thanks.

Edit: just to add that I really like the core idea and concepts but this cannot work in the real world of capitalism, the corporate-controlled Internet and the current global surveillance situation.


The obvious question that arises with companies like this is if I don't trust Google, why should I trust you? Using open source software isn't a signal that you are trustworthy. Especially considering none of your customers can verify the actual code you are using. What would prevent a similar company from starting with open source software and inserting all sorts of evil code before deploying it on their servers?


and I ask, how is that the use of open source software can guarantee privacy? from the article

"OpenMailBox is an recently email service (June 2013), which promises to respect your privacy thanks to the exclusive use of free software "

and the business model? bills needs to get paid...


The terms of service are here: https://openmailbox.org/cgu.php

There are some typos there and they don't say much. Do I need to say more about the quality of this?


It's based in France, can't expect the creator(s) to speak perfect English


Good. The text I'm referring to is in French. Can I expect him to write perfect French on a legal document?


How comforting it is to be only subject to French surveillance: http://gigaom.com/2013/07/04/france-has-its-own-prism-like-s...



I'm not basing my judgement on where it comes from. I read the ToS and, since they're in French, I'm sharing two observations:

- there are typos there

- they don't say much

It's not good quality per se, that's it. I don't care where it's coming form.


OpenMailBox use HTTPS, and that's all well and good, but how are my emails stored on your server(s)?

EULA: "The mails are stored on our server in a directory name. Person or even administrators can not access".

I don't see any client/server encryption, so how is that no one can access and/or read my emails?


There are several security concerns here.

First of all, I didn't see any mention of encryption. Is data encrypted at all, or are you able to read everything going on in the server? If encrypted, in what way? Why should I trust you with my data if it's not encrypted? How will I hold you accountable if I'm not paying you?

Second, HTTPS is a nice start, but it's just public/private key encrypted connection. It's still susceptible to a MITM using a proxy. Most users will click through a security certificate warning generated by their browsers for the sake of convenience. Bam, there goes the HTTPS protection. Especially since all that's stated is you hold the data in a directory. So, if it's in a directory unencrypted, what's stopping someone from path traversing into that directory and either stealing my data, doing things with my credentials or taking down your entire application by shifting through file directories to root acccess? Are there auth checkpoints so you can't climb up to root privileges?

Third, you state there is "powerful antivirus protection." How powerful? Tailor-made for the application or stock bought/outsourced? Do you have an in-house team experienced in crypto working on the development? Are they carefully writing source code with security in mind or checking for it afterwards?

Attempts like this are somewhat misguided in that they're misinformed by anti-government and anti-BigCo trends. Your data is safer with Google. They pour more resources into security than this project could reasonably hope to bring in revenue in a decade. I'm not saying this because I always believe open source is always, universally less secure than proprietary, but because it's Google's GMail we're talking about. A dedicated security engineering team larger than the entire team building this OSS project.

Security is very much a game of resources. You should assume you will be hacked, at some point, inevitably, and work from there. I trust Google more with my data because I know several facts:

1. Google will only cooperate with law enforcement if there is a reasonable need requested of them - contrary to popular belief, the government has more efficient ways of stealing and doesn't have "direct access" to Google's servers;

2. It encrypts data, which is something I'd hope to see at the very least (and which I didn't see here); and

3. Considering the government can probably catch you with or without Google, I'm more impressed with its engineering team than yours. No offense.


In addition, when it comes to encryption that is intended to defeat things like XKeyscore, this isn't it. It's nice that the tunnel to the server is TLS (which is probably not really safe from the NSA), but you still generally are going to have unencrypted inbound emails coming into the server and unencrypted outbound emails exiting the server, no?


> Most users will click through a security certificate warning generated by their browsers for the sake of convenience.

This can be avoided by using HSTS.


Cloud email is cloud email. There is no open source solution to a subpoena.


While I think this is needed, the question has to be asked: How is this open? Is it open source, or open as in freedom?

There might be a promise not to sell data, but you aren't doing any client/server encryption to prevent yourselves from reading it. If a government sent a request you couldn't deny, data could still be collected. Gmail has HTTPS, but everyone agrees that only protects from MITM attacks from the hacker in the coffee shop, not the one in the datacenter.


The software used in the mail stack is purely open source software. Looks like they are running a fairly standard Postfix stack and are using roundcube for webmail [1].

I'll stick with my current solution of lavabit (which encrypts all mails stored on their server) [2] and running my own roundcube instance for when I need webmail.

[1] https://openmailbox.org/licences.php

[2] http://lavabit.com


> The software used in the mail stack is purely open source software.

Does that really matter? I don't think the solution for people wanting to move off of GMail is to set up another company that stores your email.

What I'd love is a physical box I can plug in at home which stores my email and provides all the tools which GMail does (web/mobile apps, features, etc).

Even then, I'm not sure I'd switch. This is a tough nut to crack...but it's promising to see people trying. Hope something comes out of all the work going on in this space.


I used to use Lavabit, but made the switch because of their policies and logging:

https://github.com/nylira/prism-break/issues/284


The fact that lavabit unexpectedly went down last night (and is still down) without them announcing it beforehand, or saying when it will be back up, is really annoying me right now.


This might be why... https://lavabit.com/


From the comments on the blog:

"How do you plan to avoid [turning over encryption keys to authorities]?" - Majik

Response:

"I give the informations because I do not want help criminals." - Pierre Barre

http://www.perseosblog.com/en/posts/openmailbox-an-alternati...


This is the message I got from the author:

    Don't trust Google, trust me instead!


I'd like a "here's how to host your own gmail-equivalent" (I use Kerio for this), or maybe a "here's a service which lets you have your own gmail-equivalent on your own hardware under your own control, which we can DoS but can't do anything else to without you noticing and abandoning" (technically hard).

"Trust us" vs. "trust Google" is kind of a joke, though. Yes, Google is at risk to the USG, but so is any other provider, AND Google is both amazingly technically competent (unlike unknown entities) and well resourced (so, reliable). These guys aren't.


Hoping to support this with donations seems unstable. Mail will cost about two cents per 1GB account per month if you buy your servers at the right price and if you have a good ISP with nice electricy prices. At that price, you need 1% of your users to donate 20 bucks per year. This is awfully close to freemium conversion rates, I'd expect donations to be much less.

Add more storage and it gets hairy real fast. And don't forget to add fixed costs in the end (paid sysadmins and customer support).

Hmm, ever since GReader I'm a fan of "show me your money making plan" or I'll suspect dark monetization plans.


"exodus"

I haven't heard, seen or read about any user exodus from such services potentially sharing data.


Very good initiative. How do you earn money to keep up its costs?


I'm quite sure that gmail's services are also based on open source software and operation systems.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: