Slashdot Mirror
Why Open Source Matters For Sensitive Email
Jason Baker writes Can you really trust your email provider? And even if you self-host your email server, can you really trust its security if you can't see the code? Over on Opensource.com, Olivier Thierry makes three cases for using open source to power your email solution: The power of numbers, the value of trust, and the importance of leverage.
We've seen over the last year many open source, power in numbers projects have critical vulnerabilities waiting to be exposed. Those defects were sitting there for years, yet being open source didn't magically fix them. I use many open source tools, but I've never inspected the code myself. Even if I did, I'm not going to be finding these hard-to-find defects that the people in the project can't find. I'm not going to implicitly trust an open source project just because it's open source. How do I know who's really contributing? At least if Apple is doing something naught with my iCloud email, at least in theory I can join a class action lawsuit and get a free download from iTunes. If the NSA is inserting nefarious code into an SSL project, there's really no recourse for action. Over the last year, I've learned that the key to internet security is that it doesn't exist. If there's something that really so sensitive, maybe you shouldn't email it.
Open source is a source licensing model. It has no magic powers for creating secure solutions to anything.
Stupid headline: Why open source matters for sensitive email
Stupid headline: Why closed-source matters for sensitive email
Smart headline: Why security matters for sensitive email
Code audits for security defects can happen regardless of source licensing model.
Coders authoring a service, no matter how security conscious, and no matter how many eyeballs they have, will likely miss many exploitable defects.
Even beyond that, e-mail can be encrypted client-side when necessary, meaning you don't have to trust anyone. There's no reason to trust your e-mail provider in the first place if the contents are truly sensitive. For everything else, e-mail should be considered about as secure as a postcard.
If you need to protect the metadata as well as the content, then e-mail shouldn't even be used for that sort of correspondence. E-mail has never been secure. It probably never will be either, at least not for what we consider "e-mail" today, because there's too much legacy crap that would break if we lock it down (at least if we are trying to secure metadata).
If we're OK with simply encrypting content as needed, then there are ways of building that sort of infrastructure into the system. We're seeing a lot of 3rd party messaging solutions that are using very good "trust no one" client-side encryption technologies and methods, such as What's App (now that they've integrated Open Whisper Systems security) or Threema.
Irony: Agile development has too much intertia to be abandoned now.