Volker.tex

\chapterwithauthor{Volker Krause}{Twenty Years of Email}

\authorbio{Volker Krause joined KDE in 2002, and primarily contributed to KDE's email and personal information management infrastructure and applications. He works as a software engineer, consultant and trainer at KDAB.}

\noindent{}On October 14, 1996 Matthias Ettrich started KDE, with an RFC822 message, the same message format still in use today two decades later, with just minor fixes and extensions for supporting non-ASCII text. We all know this as email.

Shortly after, still in 1996, KDE's own email client, KMail, was started. While it mutated heavily several times in its almost twenty years of history, you can still find traces of its founders in the code today.

Email has always been an essential component of KDE, although a lot has changed, and will continue to change. It is interesting to look at the developments and challenges in this way, as these are also reflected in many other areas of KDE, and beyond.

\section*{Enabling Access}

Back when KMail was started, the prevalent way of using email was downloading and storing it locally on a single personal computer, with ISPs or universities providing POP3 accounts that buffered incoming emails until the user had a chance to fetch them. With email becoming popular and important on a larger scale, various companies tried to push their proprietary variants, such as Lotus Notes and Microsoft Exchange.

Therefore the first challenge was to provide free access to email, both free of cost and with the freedoms guaranteed by Free Software. This might seem odd from a present point of view, where we are used to finding Free Software applications for pretty much any use case.

In the first years of KDE, Free Software as such was not yet universally accepted. On the contrary, it had to face massive opposition, in particular from Microsoft. It took years to prove that Free Software was a development model that could provide high quality and innovative applications, something that is hardly questioned anymore by now. Even Microsoft is contributing actively to Free Software today.

KMail, together with many many other Free Software applications, proved the opponents of the GPL wrong, having become a competitive product, with some of its innovations such as the missing attachment warning having found their way into many other email clients. And it has found a balance between purism regarding open standards and pragmatism when it comes to compatibility with proprietary applications, still an ongoing discussion in the Free Software world.

In order to enable free access to your data, free applications are essential. As the world changes however, this is challenged over and over again, and free applications are not the only piece in the puzzle any more.

\section*{Clouds}

As computing equipment, and email with it, became more and more ubiquitous, a new challenge arose at the beginning of the century. With the availability of laptops, and later smartphones, email needed to be available on multiple devices simultaneously; the old download model did not work anymore.

With the widespread availability of permanent internet connectivity in the wake of the dot-com boom, the solution turned out to be server-side storage and online access, an approach that years later became associated with the term “cloud”.

IMAP, the protocol for server-side email storage and access was standardized, and KMail received support for it. While solving the problem in theory, the limited availability of email providers offering affordable IMAP hosting at the time did not really help though.

Instead, advertisement-based webmail providers started to appear and became popular, offering cost-free email hosting with access from a browser, and a few megabytes of storage space. That entire market got swept away with the appearance of Gmail in 2004 though, which offered an (at the time) audacious one gigabyte of storage space, and a stream of innovations in the user interface. Gmail has since become the de-facto standard for consumer email.

The implications of this were not immediately recognized by everyone, and the inside perspective tends to be skewed. We understand the risks and implications of the cloud approach (“there is no cloud, just other people's computers”), and we have access to alternatives, but that is not what the average user sees when looking at Gmail. It is a solution to a very real and pressing problem, and even seemingly free of cost.

KMail, of course, has dedicated support for Gmail and its various non-standard extensions nowadays. But regarding having control over your own data, is that really the way we envision our communication infrastructure?

How and where data is stored and how it is accessed have become just as important as having a free application to access it, and this is more than providing a Free Software server implementation. We also need to offer solutions for secure and reliable hosting and deployment. “Just run your own email infrastructure” is not a viable solution for most users. Finding convincing and practical answers to this will be an important challenge for the Free Software community in the coming years, KDE included.

\section*{Small Screens}

In 2007 the iPhone started the age of the smartphone. A year later, Android followed. By 2012 a billion devices had been sold, making a small touch screen with barely more than a ten centimeter diagonal the world's primary communication interface.

First attempts to give KMail a smartphone-compatible interface happened in 2010, with limited success. The way we organize and use email is inherently tree-based. Folders, message threads and inline conversations can all get deeply nested. Tree-based interfaces however only work poorly on small screens, either being very cumbersome to use or imposing severe restrictions on the nesting depth.

Not only KMail was affected by this challenge though. This situation contributed to the rise of a new style of communication approach: messenger apps. By linearizing conversations, they avoid the user interface challenges email poses on small screens, quickly gaining hundreds of millions of users.

Unlike email however, the messengers, no matter if using proprietary or open source clients, are not using standardized and interoperable protocols, turning them into communication islands relying on vendor-hosted server infrastructure.

Gmail and proprietary messengers are challenging conventional email clients, in particular in the consumer space. Even heavyweights like Thunderbird struggle with this. Solutions that allow you to regain control over your communication data, without losing the convenience and functionality proprietary solutions provide right now, have yet to be found.

\section*{Silos}

The smartphone platforms also made application bundles a widely-used technology, to support their application stores and increase security on the devices. Application bundles since then have also become relevant on all other major platforms.

Isolation from broken or malicious applications and straightforward deployment and cleanup make application bundles a very attractive choice.

On the other hand, application bundles lead to the creation of silos. Data and functionality is only available to a single application, and the rest of the workspace cannot benefit from it.

Because the KDE community acts as both application vendor and a platform vendor in this model, the KMail team is faced with a dilemma. In order to be easy to deploy on the most widely-used platforms (Windows, Android) an application architecture that allows the creation of an application bundle would be needed. On the Plasma workspace however, deep integration would be desirable, providing access to email communication for the entire platform.

KMail has chosen to go “all in” on the platform integration side, with a multi-process architecture enabling data sharing and non-exclusive data access. This is a prerequisite to offering a free and privacy-honoring answer to the personal digital assistants for example.

Other KDE applications are focusing on application bundle compatibility instead. There is no right or wrong here, but finding a way to serve both scenarios will be a major technical challenge for many KDE libraries and applications going forward.

\section*{Privacy and Freedom}

Providing secure communication can be traced back to the early days of KMail. Support for PGP encryption was added in November 1997, and support for transport encryption followed soon after. Growing interest in security, also in the form of public funding, resulted in the joint Gpg4Win project together with the GnuPG community, with KDE providing the Kleopatra certificate manager.

In May 2013 Edward Snowden gave the world a glimpse of the extent of global mass surveillance. What were once considered paranoid speculations suddenly looked naive, and unless you took measures to protect your privacy, privacy itself turned out to be only an illusion.

Not only is all your communication intercepted and recorded, it is also automatically analyzed by machine learning algorithms that decide what is “normal” and what is suspicious. You lose your freedom to be different, and uncontrollable machines decide the consequences of that. It has become very apparent that privacy is an essential prerequisite for freedom.

Free Software is well positioned to ensure privacy when it comes to your digital footprints. Free Software is probably the only way to ensure that. And without conflicting commercial interest in KDE getting in the way, our users are not our product, and we can truly follow the “privacy by default” maxim.

As news about the extent of the mass surveillance spread, demand for Gpg4Win tripled, with monthly downloads crossing the 100,000 mark. KMail also saw a renewed interest in improving encryption features, in particular by making them easier to use. “Privacy by default” also means the software needs to do everything it can to ensure privacy if the user does not understand the intricate details of public key encryption and certificate trust chains.

Today KDE technology is helping millions of users to protect the integrity and privacy of their email content. There is still more to do though. Content encryption is only addressing part of the issue, and protecting metadata of email communication is an equally important and still unsolved problem.

\section*{Conclusion}

Matthias got what he had asked for, and so much more. What KDE in particular and Free Software in general achieved in the last two decades is beyond what would have been imaginable in 1996.

People have questioned the relevance of the desktop, the relevance of email or that of KMail in today's world. All this of course might or might not change in the future. That is not the most important question going forward though. It is who will have control over your data. And that is not just affecting email. What is the point of Calligra if your documents are locked in a proprietary Google or Microsoft cloud? What is the point of our scientific and educational software if you cannot afford the corresponding textbooks? What is the point of our communication software if the world uses proprietary messengers?

Obviously free applications will stay a key element for this, but we also need to look at the bigger picture and continuously reevaluate if we still provide a valid solution to whatever the original problem has evolved into by now. With ubiquitous connectivity and software so deeply embedded into every aspect of our lives, we cannot look at applications on their own anymore. We need to look for solutions for today and tomorrow's use cases that allow you to retain and regain control of your data, striving for a world in which everyone has control over their digital life and enjoys freedom and privacy.