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.
The Open-Source Email Service to Get Rid of Google
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.
The Challenge to Replace Google’s FCM
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:
- It must be secure.
- It must be fast.
- It must be power-efficient.
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.
So, What Is SSE?
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.
Tutanota Is the First App of an Email Service Available on F-Droid
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.
A Privacy-Focused Email Service for Everyone
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.
As operators continue to experience growing demands on their networks in the lead up to 5G, the need for high-bandwidth, flat, and super high-speed Optical Transport Networks (OTNs) is greater than ever. Combined with an increasingly global market, there is a clear need for service providers to work across international boundaries and provide end-to-end services for their customers that is carrier and geographic-agnostic.
