Privacy Software

What are you looking at?
What are you looking at?

As a means to give our work direction and a clearer purpose, KDE is currently in the process of soul-searching. Here’s my proposal of what we should concentrate and focus on in the coming years. I’d welcome any feedback from the community to make this proposal better, and rally up more support from the community, and others interested.

So here’s the Big, hairy, audacious goal that — in my opinion — KDE should focus on, and should adapt its strategy for:

“In 5 years, KDE software enables and promotes privacy”

Privacy is the new challenge for Free Software. KDE is in a unique position to offer users a complete software environment that helps them to protect their privacy. KDE, being community-driven and user-focused, has the opportunity to put privacy on top of the agenda, arguably, being in this position, KDE has the obligation to do this, in the interest of the users.

The effect is expected to be two-fold:

  • Offer users the tools to protect privacy and to lead a private and safe digital life without compromising their identity, exposing their habits and communications
  • Setting a high standard and example for others to follow, define the state of the art of privacy protection in the age of big data and force others to follow suit, thereby increasing pressure on the whole industry and eco-system to protect users’ privacy better

Leaking user data, allowing users to be tracked, collecting their most private information in databases across the world means that users lose control of their identity and what parts they want others to know, and what they want to keep for themselves. Worse, collecting data in so many places, often commercially, but also by governments means that the user has little way of knowing what is known about him or her, let alone being able to determine who should be able to control what. Data being persistently collected means that not only today's security measures and policies are relevant, but also the future's. This poses multiple great risks.

KDE adds a 5th Freedom to the 5 principal software Freedoms:

The freedom to decide which data is sent to which service”.

Personal Risks for Users

Orwell's 1984 is not an instruction manual
Orwell’s 1984 is not an instruction manual

Risks that individual users run are, among others:

  • The more data that is collected, the bigger the risk of Identity Theft becomes
  • More collected data means that decisions will be made for the user based on skewed or incomplete information (imagine insurance policies)
  • Collected data may end up in the hands of oppressive regimes, posing risks to the user when travelling, or even at home
  • Blackmail
  • User's most private secrets may end up in the wrong hands

Socio-economic Effects

Socio-economic effects that effect how society, national and international communities work, are:

  • Free speech is compromised
  • Journalists need tools to communicate secretly, lacking that, freedom and independence of press cannot be guaranteed
  • Trade-secrets cannot be kept, free markets cannot function without tools protecting privacy
  • Sovereignty of nations cannot be guaranteed
  • Cyber-attacks may lead to shift in power

What it will take?


  • Security
  • Privacy-respecting defaults
  • Offering the right tools in the first place


We can only guarantee privacy if we also value security.
Possible approaches:

  • Functioning code-review
  • Quick turn-around times for software updates, especially security fixes
  • Prefer to use encrypted communication where possible, prefer HTTPS over HTTP where possible, avoid unencrypted connections
  • Storing sensitive information only in an encrypted way
  • Moving away from inherently insecure technologies, i.e. default to Wayland instead of X11
  • Avoiding single points of failure and centralized control

Privacy-Respecting Defaults

KDE software supporting this goal should:

  • Only collect and send data when necessary and clear and sensible from within the context. No hidden telemetry sending user stats, not HTTP connections downloading content, no search queries to online services without the users explicit consent (or where it's entirely clear from the context, e.g. web browsers, software updater, etc.).
  • Use anonymity where it is possible, for example by using Tor connections for things like weather updates that don't require user identification
  • No collection of privacy-relevant data without clear purpose.
  • Conservative defaults: a user should not have to make changes to the software configuration to avoid leaking data. Secure and private by default. (Software may be configured to be more leaky if that benefits the user, but the risk to that should be clear, either from context or explicitely stated.)
  • Use clear and consistent UI and design language around network-related options

Offering the Right Tools

KDE needs to make an effort to provide a comprehensive set of tools for most users' needs, for example:

  • An email client allowing encrypted communication
  • Chat and instant messenging with state-of-the art protocol security
  • A webbrowser (self-provided) that has private default settings
  • File storage and groupware solutions
  • Other tools that allow offline operation and independence from popular cloud services
  • Support for online services that can be operated as private instance, not depending on a 3rd party provider
  • State-of-the-art support and integration for services like Tor, Matrix, Zeronet, etc.


  • KDE e.V. allows anonymous donations via bitcoin (or other crypto currencies)
  • Adaption of blockchain where useful

How we know we succeeded

Static and runtime analysis tools:

KDE software can be audited for compliance with common, security related standards, such as:

  • NIST Cybersecurity Framework (NIST CSF)
  • ISO 15408
  • RFC2196
  • Cyber Essentials (UK Government Standard)
  • … etc.

"Soft" criteria include:

  • Press and 3rd party refer to KDE as carrying the gold-standard for such software
  • Journalists prefer KDE software for their work
  • The NSA hates KDE
  • The CCC loves KDE ♥

The full proposal has a little more details and pointers (and may still be updated, it’s not final yet), but I’d like to keep it at this for my weblog, and also add a note here: Coincidentally, shortly after starting the work on this proposal, KDE’s Plasma team was contacted by Purism who are building a privacy-focused phone. I was immediately excited since I think privacy is more or less an extension of the core values of Free software and the librem5 could provide a really valuable target for KDE’s privacy efforts, I see a fantastic degree of synergy there.

6 thoughts on “Privacy Software

  1. Re: privacy

    Applications should not leak their names and versions, operating system name and version and system’s locale and time zone (local time) unless it’s really necessary. This is important for web browsers, mail clients, torrent clients, chat applications etc. (all aplications connecting to the Internet). This not only ruins privacy but also security, as an evil internet service could serve an exploit for particular application or system.

  2. Honestly, no thanks. I’d prefer my DE to be as lean as possible. I don’t at all feel the need for my DE to go out of its way to try and make things more private.

    KDE’s focus, IMO, should be making Plasma and other KDE applications as lean and efficient as possible. Work on getting rid of having to install 50+ dependencies for most KDE applications (even when I’m running KDE Plasma as my DE).

    I love KDE Plasma and KDE apps, but their dependencies are honestly a huge mess. In order to install kdevelop on KDE neon User Edition 5.10.5, I have to install an additional 60 packages. I can’t even imagine how many packages someone running a different DE would have to install to use kdevelop.

    1. The number of dependencies is in fact what is making it lean, because it is much more fine grained than one monolithic library that includes everything and lots is stuff you don’t need. We have been there, and the modularization that we introduced with KDE Frameworks a few years ago had a huge impact on footprint.

      Number of deps is simply a very poor metric. It’s a lot more complicated than “my package manager wants to install 13 additional packages”. Performance is impacted for example by number of symbols, lib size, amount of shared memory, and probably most of all: how much stuff do you have to load that you won’t need: all of these suggest to split into more, smaller libs, effectively overweging thee number of deps (but dressing footprint).

      Imagine a cake: if you eat the whole cake in one piece or eating half of it cut into 6 pieces. You eat a lot less cake in the latter scenario, but a lot more pieces. The same applies to library splitting.

  3. One thing that is often left out when trying to promote privacy as a valuable feature (which I fully support) is the language that is used to frame ( the concept. For instance, a lot of people don’t know the difference between privacy and secrecy. This often results in discussions where we want to promote privacy, but end up defending secrecy i.e. “I’ve got nothing to hide”. And while this might be negligible at the discussion level (everybody has their opinions) these nuances can get in the way when we try to achieve something a bit more meaningful – e.g. like Purism’s Librem 5 campaign (which I also supported and really hope that it succeeds).

    Looking at their campaign page it becomes quickly apparent that they have a difficult time identifying and addressing their actual target audience. Of course, in hindsight it’s easier to identify the target audience (free software enthusiasts complain about it not fully being free, common folks don’t know about its existence or couldn’t care less because they’re still stuck and not properly grasping what is meant by privacy – which leaves us, the slightly more pragmatic desktop Linux users, knowing that we can’t start with perfection (fully free), but we’d be excited to get what we are used to on the desktop in a meaningful way on our phone – thank you plasma mobile, ubports, pmOS etc. – and gradually move towards a more ideal situation with respect to freedom.)

    The reason I bring this up here is because as another “What it will take”-criteria we finally need to start adopting an interdisciplinary approach to integrating privacy into our tech i.e. computer and social sciences need to start to work more closely together. And we gotta leave marketing out of it – our ideals are worth more than buzzwords and dumbed-down concepts. Rather, we need to break down the complexities behind these ideas in a more meaningful way, for instance by translating them using relevant rhetoric devices or by connecting them to social and personal situations that aren’t just based on fear (“protection”).

    Finally, if this resonates with someone, I’d gladly help out whichever way I can. In the meantime thanks for all the hard work.

  4. One first target is easy: always try to support the standard and open way of doing things first, only then try to provide integration with proprietary tracking services.

    A glaring example: if you try to connect to a regular IMAP account that unfortunately is provided by Google, KDE’s akonadi simply switches to “Google mode” and tries to go full in with the proprietary API for authentication. That should be left for the user to choose.

    Maybe a quick guideline such as; “first provide integration with open services that the user could host herself at home, and then provide support for proprietary services that track the users (all others, actually)”.

Comments are closed.