Easy Email Encryption

First, the good news. There's been a lot of progress toward letting people talk to each other securely. Signal is amazing, and it showed the world that strong cryptography can be clean and easy to use even for our smart but nontechnical friends. It proved that end-to-end encryption is not just for nerds who use PGP and Linux and go to "keysigning parties".

WhatsApp is rolling out end-to-end encryption to 800 million people, most of whom have never heard the word "cryptography" and have no idea what a "key" is. It's incomplete and imperfect, but still a huge step forward.


Unfortunately, while been lots of progress for messaging apps, email is still insecure. This sucks because email is the system of record. Messaging apps come and go. The messages themselves are often ephemeral as well. If you lose your phone, all your SMS and all your Signal messages are gone. Messengers deal in plain text... sometimes you can add pictures or emoji.


Email is more real. It's an open standard. It lasts forever. It's global. It supports rich text and attachments and everything. It's the modern replacement for mail, for quills and parchment and envelopes. Here in America, the Fourth Amendment guarantees people

The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures

That there could be a big building where bureaucrats rip open every letter, read it, reseal it, and send it on to its destination, like in East Germany, sounds ridiculous. We're a free country, that's not how we roll. And yet that extra letter, the e in email, the implementation detail where mail is sent digitally rather than on literal paper, seems to void those protections. In countries like China and Kazakhstan, people are even more vulnerable. It's a chilling thought: a democracy movement, like the one that liberated Chile 25 years ago, might be impossible today because we've accidentally made it easy for states to read all mail.

 

To fix this, end to end encryption must be the default--not just for WhatsApp, but for email. We also need metadata security. To protect freedom of association, an observer shouldn't be able to tell who's talking to whom.


An idea...

1. You install a new mail app on your laptop. It's open source and well vetted.

2. You log into Gmail, your university mail, all the accounts you have. The app syncs your mail. You have a modern mail client with a nice UI and fast search, even when you don't have internet.

3. Bob installs the app as well. The next time you send him an email, it's automatically encrypted, signed, decrypted, & verified.

I want to do for email what Signal did for texts: I want to make end-to-end encryption easy.


Under the hood

Key exchange is automatic and centralized, like Signal. Encryption using Axlotl provides forward secrecy.

Finally, we want metadata security. We don't want to leak who's talking to whom, so we'll send all encrypted mail with a hardcoded From and Subject.

Of course, Bob's app will show him the real, decrypted From and Subject.

The last piece of the puzzle: we can’t just connect to our outgoing mail server directly. That would let it see your IP address and your recipient’s email address, again revealing both sides of the conversation.

Instead, we'll send all outgoing encrypted mail thru Tor.

Easy to use encrypted email, with modern crypto, providing both content and metadata security.


Could this work? Would you use it?

Let me know your thoughts!

Playing to Lose

Ever since the Citizens United Supreme Court decision in 2010, you can give as much money as you want to political candidates. $1000, $1m, $100m, any amount at all, through the pretty thin legal fig leaf of a Super PAC.

So people worry about corruption: about donors buying elections. Lots of people have already written about that. Glenn Greenwald wrote about it especially eloquently. I've got nothing to add there.

However, I noticed a second, more subtle bit of fuckery: donors not buying elections.

Check out this sweet graphic of all the big 2016 donors. The usual suspects, like Jeb Bush, have lots of them: Ray and Nancy Hunt gave him $2m, Trever Rees-Jones of "CHIEF OIL GAS LLC" gave him another $2m, and so on for another 45 big donors. Presumably they're hoping that he'll become president and then remember them as his supporters. In short, they're trying to buy an election.

(Not that it worked, in this case. Bush is at 3% in the latest polls, in sixth place, right behind Rand Paul. LOL!)

Bobby Jindal, by contrast, has just one single big donor: a guy named Gary Choest, who have him a nice round one million dollars. But unlike Jeb, Bobby Jindal was never expected to win. He was never in any danger of becoming the Republican nominee, let alone president --- so why would someone discard $1m like that on an extreme long shot?

Gary Choest's company gives a clue: EDISON CHOEST OFFSHORE. Offshore means offshore drilling, and a lot of that happens in the Gulf of Mexico. Sure enough, they're based in Louisiana, where Bobby Jindal is governor.

Unlike Donald Trump, who will presumably go back to playing golf and banging his Slovenian supermodel third wife in a gold plated hotel suite if this president thing doesn't work out, Bobby Jindal is a serious politician with real local clout. Jindal has already ended his presidential run and is back to governing. He has veto power over new Louisiana laws. He decides where bridges are built (hint: to the offshore oil hub of Port Fourchon, using some of the BP oil spill settlement money).

My guess is that Mr. Choest knew that Mr. Jindal wasn't going to be President, and gave him $1m anyway! Because running for President is fun. It flatters the ego. And it's cheap! A mere $1m wouldn't get you into Jeb Bush's top 10 donors, but with Jindal it makes you his one big supporter, the one who made the whole adventure possible. 

And for the CEO of a big offshore oil services company in Louisiana, that's got to be worth something.

Lot going on here

Nylas N1 is a slick, modern email client. It is built to be extensible. All of that is awesome.

It's also staggeringly complex for a program that shows you your email.

  • It’s built as a thin client, with the actual IMAP syncing handled on separate servers

  • The server-side Sync Engine is written in Python and uses MySQL under the hood, with a lot of scaling complexity because it has to handle potentially millions of accounts.

  • The “thin client” is an Electron app, which means it bundles pretty much all of Chromium

  • The client is written in Coffeescript+React+Flux+Electron and uses Sqlite3 to cache the same data on the client. Totally different tables than the ones in MySQL on the server, though.

  • The client is a lot more complex than a typical React app, since it has a custom package architecture, complete with “ComponentRegistry”, “roles”, and so on

Cherry on top: N1 comes with its own custom ORM written in Coffeescript, complete with SQL highlighting so that it prints pretty logs.

Long story short, here’s the game of telephone that happens to show you your inbox:



How can we simplify?

Auto Pwn

Once upon a time, a software upgrade was a physical box with a CD. It looked like this:



Then the internet happened, and companies started using “update managers”.



Things got spammy. Every time you’d turn on a computer, it would ask you if you want to update Java and please upgrade to the latest Adobe Acrobat Reader.

A lot of people just ignored the upgrades, leading to version skew. (That where people are using many different versions of the same software.)



So if you made a web app as recently as 2011, you had to make sure it works in Internet Explorers 9, 8, 7, and best of all 6. Fun!

But in 2008, Google shipped Chrome with a new invention to fix this problem.

As Chrome developer Ben Goodger explains,

Autoupdate is one of Chrome's killer features. [...] Long before we launched publicly in 2008, the autoupdate project was one of the very first we started working on. The idea was to give people a blank window with an autoupdater. If they installed that, over time the blank window would grow into a browser.

How cool is that! 

No more version skew. No popups. Every time you run Chrome you get the latest greatest version. 

There was just one problem.

It worked so well that auto update became ubiquitous. Today, the thermostat where I live auto updates itself, over WiFi. Things that used to be simple are now complex and flaky. For example, my phone will occasionally just grow a new bug one morning and, say, the camera stops working. Not all teams are nearly as reliable and careful and awesome as the Chrome guys.

Not all teams are as trustworthy as the Chrome guys, either, which means there's a much bigger problem:


Through ubiquitous auto updaters, we’ve totally pwned ourselves.

There are now probably 10+ separate organizations that can run arbitrary code on my laptop whenever they want. Same for my phone. Fundamentally, that’s how most auto update mechanisms work.

Most updaters connect to a central server, and if there’s a new version available, they automatically download it and run it.

That’s convenient, but now you're at the mercy of whoever controls that server and has that signing key (assuming they even sign updates, which not all of them do). Just last week, Kazakhstan announced they’re going to MITM all HTTPS traffic in their country. Other governments with similar impulses but a bit more subtlety can leave HTTPS alone but compel their companies to issue an autoupdate. If they want to be sneaky, they can serve a clean version to most users and a compromised version only to specific people, filtered by IP. Compelling Google to do that for you is probably hard, but what about some dude who wrote a Notepad++ plugin?

A popular program with an autoupdater is a lot like a botnet. The owners can push some code. Within a few days and without any more human intervention, millions of computers are running it. The difference is users install them by choice!


How can we fix this?

Autoupdaters aren't going anywhere. They're too useful. So the question is not "how do we get rid of autoupdaters", it's "how can we make a secure autoupdater".


If we must have autoupdaters, I’d like mine to use multisigs and deterministic builds.

It works like this: multiple people have to sign each update, say four out of a list of six trusted keys. Those are held by six different people, ideally spread across different countries. Trustworthy people and organizations, the same ones who are doing the code reviews and audits. When a new version is ready, each of those six checks out the code and builds it themselves. Because it’s a deterministic build, if they’re all using the same commit hash, they’ll all get the same binary, byte for byte. Finally, they sign with their key.

This makes pwning people thru the auto updater a lot harder. There’s no single private key that one person can lose, giving an attacker that power. Getting four out of the six signers to sign an update with, say, a backdoor, is a lot harder than one.

Finally, it would add some accountability. Companies, auditors, and open source developers would be signing their name to each release. I’d like to know which people have the power to run code on my machine. Today, there are a lot of people who have that power, and I have no idea who they are.


Let's fix it!