-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
by Javantea
May 5, 2017
On Thursday of this week (May 4, 2017) I released a mail client. It's pretty humble, but I've been using it for a decade and so it was worth it to me to iron out a handful of bugs and make it good enough for other people to use. Currently it won't be much use to you if you run Windows, Mac OSX, don't run your own mail server, or don't understand what fetchmail is*. But those things are fixable and I intend to fix them in the months to come. That means this blog post doesn't have to cater to end users, so I won't attempt to. This blog post will be about how I came to write a mail client and why it makes sense in 2017.
* The wording of that sentence was pretty bad so I'll reverse it. BikeIM-0.5 is usable to you if you run Postfix, if you run Dovecot, if you run OpenSMTPD, if you run fetchmail, if you use GnuPG, if you use Mutt, if you run Linux or *BSD, if you use Git, and understand how to report bugs.
First let's talk about e-mail in 2017. People still use it to get stuff done. Mailing lists still exist. Open source software is developed on massive mailing lists. People communicate about their daily lives over e-mail. Amazing, right? Not everyone uses web mail because not everyone wants a corporation to run their e-mail. The number of people using e-mail clients is signficant. Amazing, right? Mozilla had an okay mail client but they decided to abandon it. Why? Because people like me were going to eat their lunch. And who wants to be that guy? An e-mail client in Python makes way more sense than an e-mail client in JavaScript. Why? Because JavaScript doesn't come with anything. Python comes with e-mail libraries and a lot more. People still run their own servers**. Running your own servers is work, but it means that you don't have to rely on a corporation to store your mail. Amazing, right?
** I run two Postfix mail servers. If you send e-mail to *@altsci.com it goes to me. Not Google, not Yahoo, not my ISP, not my hosting provider. Specifically it goes to Dmitry (I control it) and then to Suzy (I control it). If you run your mail server, an e-mail from you goes to your mail server, then Dmitry, then Suzy. An e-mail from me goes from me to Suzy to Dmitry to your mail server, then to you.
A lot of competitors to e-mail have popped up recently. Why do you think that is? Is there a profitable business model for end-to-end encryption? Of course. Is there a death knell sounding for PGP? Perhaps. We'll find out. But until that happens, it's pretty obvious that people are going to still need e-mail. It doesn't hurt if they can do so securely with PGP. Moxie Marlinspike, a competitor to GnuPG and outspoken critic himself says: "Today, journalists use GPG to communicate with sources securely, activists use it to coordinate world wide, and software companies use it to help secure their infrastructure."
Around 2006 I had a good idea for a private instant messenger service. I wasn't the only person with a similar idea. Hundreds of programmers started working on competitors to AIM, Jabber (aka Google Chat), and so on. Some had funding, some had teams of developers. I had a good name, a logo, and a firewall bypass technique, I named it BikeIM. I helped a friend with an IM client that was well-funded and it didn't turn out. I wrote a VoIP client that I thought would compete with Skype, but the quality of competitors and lack of quality of my software meant that it couldn't even get released. Instead, I wrote a simple UDP protocol and stopped there. My research into VoIP led me to some interesting conclusions but that's another story.
In 2007 I started writing a simple mail client so that I could read and compose e-mail while working at a coffee shop. My mail client (KMail) didn't support reading e-mail on the road, so my mail client picked up the slack in that important little space. In 2011 I had problems with my mail client. It worked really well between 2006 and 2011, but stopped working rapidly. Why couldn't I use the mail client I wrote for use on the road while I was at home? So I seamlessly transitioned from using KMail to using my mail client which I affectionately named mail1. Why didn't I release the client I wrote in 2011? Well, it wasn't very good back in 2011. As far as mail clients go, it was only a little better than the now defunct SquirrelMail project. Eww, right? Why would I use something that bad? Well, in 2011 it was around 1000 lines of code. Compared to any other project mail1 was a delight to write and debug. I am releasing what it looked like in ~2014 (with vulnerabilities) in the contrib/ folder of bikeim-0.5 so that you can see the humble beginnings. It is not a good choice for new web mail client design. By 2015 it ballooned to 1442 lines of code. In case you're curious, 1442 lines is a tiny program. A person can read 1442 lines critically in a matter of hours.
Around the same time in 2011, I used an IRC bot code and a bit of html to make a simple bug tracking project and used the BikeIM name for it. It never caught on and had a few vulnerabilities, so I took it down this year when I released BikeIM, a simple e-mail client that shares very few properties with the original BikeIM idea from 2006. For one, this BikeIM doesn't auto-negotiate end-to-end cryptography. BikeIM mail client supports end-to-end cryptography (PGP) but key exchange is a hard problem and won't be solved in a few weeks. Until it is done, we have e-mail, http, keyservers, keybase.io, and other semi-automatic protocols. None of these are easy to understand and use; don't blame me, dozens of hackers and software developers got it wrong long before I showed up. All of these protocols can allow you to exchange keys, none of them automatically. As we solve the key exchange problem, BikeIM will become the private instant message service it was originally intended to be. Limitations that e-mail has that an instant message service over UDP would not have include:
- Size limitation
- Speed limitation
- Censorship limitation
- Pseudonym limitation
- Spam limitation
- Server maintenance
So why have I chosen to release a mail client with all of these limitations when I could have put the same amount of time into an IM which would have none or at least fewer? I put a lot of time and effort into an IM and it is now obvious how long it will take to do it correctly. Once the protocol is done, a user interface is needed. And what type of user interface is needed? A message-style interface which is intuitive for users to understand and interact with. The mail client for BikeIM is the interface that will make the private secure IM possible. The protocol may end up not looking like SMTP, but the packages that flow over the network might look similar. They might even use MIME (though I am considering making it a subset of machine parsable flat MIME so that compatible clients will be encouraged not to send junk like HTML, recursive forwards, or massive gobs of headers). Instead of sending e-mail to you@example.com you'll send an IM to you@destination. How do we prevent confusion between the two protocols? That's just a feature that must be written. How do we ensure that the entire UDP communication is encrypted? Key exchange by x25519. How do we authenticate? PGP, RSA, or ECDH. How do we encrypt UDP packets? AES-CTR or a similar cipher with HMAC. How do we verify the key? TOFU with fingerprint checking. How do we deal with spam? No push, only pull.
So why download a mail client that will eventually become an IM? Because the success of the mail client and the success of the IM will be parallel. If the mail client becomes popular, the IM will benefit. If the IM becomes popular, the mail client will benefit. The design is such that if you like the mail client but don't want the IM, unlike other products you won't have to use the IM. If you like the IM but like your mail client, you can use the IM without fetching any of your mail. The project is designed so that the interface is shared but the transport is not. The mail client will have significant limitations, the IM will take time to develop. Both are important in their own and will have a place in the future.
Now you might be saying "Secure IM? Didn't Moxie already do that?" Yup, Open Whisper Systems, Silent Circle, and Whatsapp have released Secure IM software among others. Before them there was SILC and Cryptocat. Many people used/use OTR with traditional IM services before that. A clear problem with any end-to-end encrypted system that relies on a centralized server is that it attracts attention from governments that want to persecute the users. How many of these end-to-end encryption systems are decentralized? OTR over XMPP is very decentralized. PGP over e-mail is very decentralized. Signal open sourced their server but refused to federate. That means they will depend on the generosity of the US government to survive. I wish the best for them, but decentralization is better for longevity. There is room for creative and unreliable solutions like PGP over BitTorrent but not for the end user. This leaves users with the options of OTR, Silent Circle, Whatsapp, or Cryptocat. Need I say more? Okay one more thing. The end user is not always the target audience. Developers and journalists put them on a pedastal because they are numerous but they are also a pain in the neck. I'd trade 10 million end users for fifty developers who keep their mouths shut except for when they find bugs. Then again, if I wanted a solution that works for developers, I have more than one. They are Apache, BitTorrent, GnuPG, and IRC.
If you're curious what the IRC/web code looked like, it can be downloaded here [sig] but remember that it's deprecated and contains unfixed bugs. It is abandonware with the only valid use being improvement or example code.
What's next for BikeIM? See the todo feature list on the wiki. Dozens of features have been implemented between March 20, 2017 and May 4, 2017 (see the git log or the calendar below). Dozens more may be implemented between May 5, 2017 and August 1, 2017.
Commits:March 2017 April 2017 May 2017 Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa 1 2 3 4 1 1 2 3 4 5 6 5 6 7 8 9 10 11 2 3 4 5 6 7 8 7 8 9 10 11 12 13 12 13 14 15 16 17 18 9 10 11 12 13 14 15 14 15 16 17 18 19 20 19 20 21 22 23 24 25 16 17 18 19 20 21 22 21 22 23 24 25 26 27 26 27 28 29 30 31 23 24 25 26 27 28 29 28 29 30 31 30
-----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEuYE3Yh0wygXiwc1/PGjI28ung+8FAlkNawcACgkQPGjI28un g+9SBxAAwqwaBG/kRnTSJTr/tYB9Y95mMctXNMAjfPdkZHYZD3a4+gW31wlZIGKG cmNKrRJBx0Gv599MyXnx+TYqQRx7BdxaurHfrNxmgj3OqNtTCEOEnHtELWKI626G ITMFV7Wra2mHO2vilL97bPO68/lUpVJDVv+jMKWXsx8BWB1gUoFdpiM5ksjFMAxk tgdUVYoxzflOoRnECDC6ji2ZvemwnxTb10dGDvvsyCZ+lEoCfddEs8Hd750EySxb iyDQN7PnM5085gXthnF6keC63rdba0lwHqJRlIz9lqeDG/R6lEkikOaTXpTvrHek Rk98C9xX8uXlNC/wJhGqNjj96I58NcevS4AVqWZrSFcPn8gsNN45BOn+mtj/8jUy ekZPFPJjkIc5LBtRqGZ20nbQFxDYzOxQLPe3vP9MOpPfs/cTPFv+74yXZPKMxVTz rKshy1qEbPH7NVpPsySiwmpQ7+nPZGaQLYrNeAXXXJVOxW/SfZsrUWnxeXay0kwY KxDV/LvMU0fdOmIagFQiM+/Hzj/Ol3ul5f6fFDyjdITiPjmBCU5bqhMNij2YbakJ 83SYPHVNanb1isv1d1+0yAFlOaDaDgGoIz/qIjU28ECLOkNqP6jkWlZE35fWLiGA 7FPFfa2agjVxp2fLXXVEohzBbIZgWsRZzXJnGJd0HnPnpBLqdnQ= =tJOU -----END PGP SIGNATURE-----Permalink
-
Leave a Reply
Comments: 0
Leave a reply »