Seven years ago, we started building Tutanota, an encrypted email service with a strong focus on security, privacy and open source. Long before the Snowden revelations, we felt there was a need for easy-to-use encryption that would allow everyone to communicate online without being snooped upon.
Figure 1. The Tutanota team's motto: "We fight for privacy with automatic encryption."
As developers, we know how easy it is to spy on email that travels through the web. Email, with its federated setup is great, and that's why it has become the main form of online communication and still is. However, from a security perspective, the federated setup is troublesome—to say the least.
End-to-end encrypted email is difficult to handle on desktops (with key generation, key sharing, secure storing of keys and so on), and it's close to impossible on mobile devices. For the average, not so tech-savvy internet user, there are a lot of pitfalls, and the probability of doing something wrong is, unfortunately, rather high.
That's why we decided to build Tutanota: a secure email service that is so easy to use, everyone can send confidential email, not only the tech-savvy. The entire encryption process runs locally on users' devices, and it's fully automated. The automatic encryption also enabled us to build fully encrypted email apps for Android and iOS.
Finally, end-to-end encrypted email is starting to become the standard: 58% of all email sent from Tutanota already are end-to-end encrypted, and the percentage is constantly rising.
Figure 2. Easy email encryption on desktops and mobile devices is now possible for everyone.
As open-source enthusiasts, our apps have been open source from the start, but putting them on F-Droid was a challenge. As with all email services, we have used Google's FCM for push notifications. On top of that, our encrypted email service was based on Cordova, which the F-Droid servers are not able to build.
Not being able to publish our Android app on F-Droid was one of the main reasons we started to re-build the entire Tutanota web client. We are privacy and open-source enthusiasts; we ourselves use F-Droid. Consequently, we thought that our app must be published there, no matter the effort.
When rebuilding our email client, we made sure not to use Cordova anymore and to replace Google's FCM for push notifications.
GCM (or, as it's now called, FCM, for Firebase Cloud Messaging) is a service owned by Google. Unfortunately, FCM includes Google's tracking code for analytics purposes, which we didn't want to use. And, even more important: to use FCM, you have to send all your notification data to Google. You also have to use Google's proprietary libraries.
Because of privacy and security concerns, we didn't send any info in the notification messages. Therefore, the push notification mentioned only that you received a new message without a reference to the mailbox in which that message has been placed.
We wanted our users to be able to use Tutanota on every ROM and every device, without the control of a third-party. That's why we decided to take on the challenge and to build a push notification service ourselves.
When we started designing our push system, we set the following goals:
We've researched how others (Signal, Wire, Conversations, Riot, Facebook and Mastodon) have been solving similar problems, and we had several options in mind, including WebSockets, MQTT, Server Sent Events and HTTP/2 Server Push.
We settled for the SSE (Server Sent Events), because it seemed like a simple solution. By that, I mean "easy to implement, easy to debug". Debugging these types of things can be a major headache, so one should not underestimate that factor. Another argument in favor of that solution was relative power efficiency. We didn't need upstream messages, and constant connection was not our goal.
SSE is a web API that allows a server to send events to connected clients. It's a relatively old API, which is, in my opinion, underused. We'd never heard of SSE before the federated network Mastodon, which uses SSE for real-time timeline updates, and it works great.
The protocol itself is very simple and resembles good old polling. The client opens a connection, and the server keeps it open. It's different from classical polling in that we keep this connection open for multiple events. The server can send events and data messages, they're just separated by new lines. So the only thing the client needs to do is to open a connection with a big timeout and read the stream in a loop.
SSE fits our needs better than WebSocket would (it's cheaper and converges faster, because it's not duplex). We've seen multiple chat apps trying to use WebSocket for push notifications, and it didn't seem power-efficient.
We had some experience with WebSocket already, and we knew that firewalls don't like keepalive connections. To solve this, we used the same workaround for SSE that we did for WebSocket. We sent "heartbeat" empty messages every few minutes. We made this interval adjustable from the server side and randomized it not to overwhelm the server.
In the end, we had to do some work—I could describe loads of challenges we had to overcome to make this finally work, but maybe some other time. Yet, it was totally worth it. Our new app is still in beta, but thanks to non-blocking IO, we've been able to maintain thousands of simultaneous connections without problems. Our users are no longer forced to use Google Play Services, and we've been able to publish our app on F-Droid.
As a side-note: wouldn't it be great if the user could just pick a "push notifications provider" in the phone settings and the OS managed all these hard details by itself, so every app that doesn't want to be policed by the platform owner didn't have to invent the system anew? It could be end-to-end encrypted between the app and the app server. There's no real technical difficulty in that, but as long as our systems are controlled by big players, we as app developers have to solve this by ourselves.
Our app release on F-Droid really excites us, as it proves that it is possible to build a secure email service that's completely Google-free, giving people a real open-source alternative to the data-hungry market-leader Gmail.
This is a remarkable step, as so far no other email service has managed (or cared) to publish its app on F-Droid. The reason for this is that, in general, email services rely on Google's FCM for push notifications, which makes an F-Droid release impossible.
The F-Droid team also welcomed our move in the right direction:
We are happy to see how enthusiastic Tutanota is about F-Droid and free software, having rewritten their app from scratch so it could be included. Furthermore, they take special measures to avoid tracking you, and the security looks solid with support for end-to-end encryption and two-factor authentication.
We are very excited about this release as well. And, we are thankful for the dedication and hard work of the numerous F-Droid volunteers helping us to publish our app there. We are also proud that the new Android app finally comes without any ties to Google services. As a secure email service, this is very important to us. We encourage our users to leave Google behind, so offering a Google-free Android app, therefore, is a minimum requirement for us.
Figure 3. The new Tutanota client comes with a dark theme—a nice and minimalistic design that lets you easily encrypt email messages to every email address in the world.
We've been using Tutanota ourselves for a couple years now. The new Tutanota client and apps are fast, come with a nice and minimalistic design, enable search on encrypted data, and support 2FA and auto-sync. Since we've added search, there's no major feature missing for professional use any longer, and we've noticed the numbers of new users rising constantly. We recommend that everyone who wants to stop third parties from reading their private email to just give it a try.
—Matthias Pfau