Description

"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 a great 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

Risks that individual users run are, among others:

• The more data that is collected, the bigger the risk of Identity Theft becomes
• Profiling
• Blackmail
• Users' private data may end up in the wrong hands
• Targeting of users (e.g. marginalized users are more at risk)

Threat Models

Public Wifi

Assume anyone can see your Wifi network traffic (e.g. you are connected to the same WPA2 network). Using your device in such an environment should be safe and not compromise your privacy any more compared to using a wired network at home.

Possible counter-measures: Only connect to encrypted services, Connect through an encrypted tunnel to a computer on your home network (e.g. wireguard on a raspberry pi for example)

Stolen Device

Assume your device gets stolen in a switched off or locked screen state. This should not result in a disclosure of personal data.

Possible counter-measures: Full Disk Encryption (e.g. LUKS, ZFS), secure-delete tools (sswap, sdmem)

Mega Corporations ("Google")

It should be possible to enjoy the benefits of state-of-the-art consumer electronics, communication and content without individual companies creating detailed user profiles.

Possible counter-measures: Free, accessible, end-to-end encrypted alternatives to proprietary services. (e.g. Signal, Briar)

Global Surveillance ("NSA")

A global passive adversary is the most commonly assumed threat when analyzing theoretical anonymity designs. But all practical low-latency systems, like Tor, do not protect against such a strong adversary. Instead, they assume an adversary who can observe some fraction of network traffic; who can generate, modify, delete, or delay traffic; who can operate onion routers; and who can compromise some fraction of the onion routers. More detail in the Tor design document.

Possible counter-measures: Only use end-to-end encrypted services (Tor onion services, Signal, Briar), use the Tor network when possible, Minimize network traffic

Targeted Surveillance ("Snowden")

Could be politically motivated or industrial espionage, by an actor with significant skill and resources.

Possible counter-measures: Reproducible builds, Clear separation of trust boundaries and documentation thereof (e.g. 'can installing a theme make my system more insecure?', 'what does this plasmoid have access to?), Apply the principle of least authority (it should be clear what a particular component has access to and able to revoke it, for example a plasmoid needs to request access to the network or the home directory), Regular security audits (not just of KDE software but also of popular third party plasmoids for example)

Rogue local software

Assume you run any kind of software not coming from a trusted source or trusted software parses data that is not trusted. E.g. you install a plasmoid from the KDE store. It should be easy to protect your personal data, kwallets, browser history, etc. and local network from that code.

Possible counter-measures: Easy and configurable sandboxing of untrusted binaries (including plasmoids and themes) and binaries that parse untrusted data (such as video/media players), Application firewall to catch and stop network egress (e.g. Subgraph Firewall, Easy rollback of destructive changes using atomic changes/snapshotting (e.g. btrfs, ZFS, ostree)

The adversary enter at your place

You have few seconds to try to secure your data by pressing a "panic button" (locally or remotely, by e.g. kdeconnect).

Possible counter-measures: pushing the "panic button" locks the screen, unmounts all Vaults/Veracrypt disks and clear the password/keyfile cache, writes zeros to RAM and swap using sdmem and sswap, securely removes (srm) critical files, call sweeper, run sfill, propagates the panic signal to all other nodes in the network, forces an ACPI shutdown, etc. Inspired by https://github.com/0xPoly/Centry

What it will take?

TLDR;:

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

Security

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

• Functioning code-review
• Regular security audits
• Quick turn-around times for software updates, especially security fixes
• Prefer to use encrypted communication where possible, offer Tor onion services for KDE services, prefer HTTPS over HTTP where possible, avoid unencrypted connections
• Encryption at rest of sensitive information
• Moving away from inherently insecure technologies and using more secure technologies, i.e. default to Wayland instead of X11, Keep supporting privileged user namespaces for sandboxing, Strong defaults for seccomp filtering, AppArmor and cgroups
• 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 and using a vetted privacy-preserving methods (e.g. rappor which is used by Chrome and Firefox). 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 telemetry and weather updates which don't require third party user identification (because we cannot control third party services and if they will behave)
• No collection of privacy-relevant data without clear purpose and without doing the best we can to preserve your privacy (for example by using differential privacy)
• Privacy-preserving 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 (Signal Protocol and derivatives like Briar and Matrix)
• A webbrowser that has private default settings
• Allow users to easily scrub metadata from files (e.g. dolphin integration of MAT)
• Other tools that allow offline operation and independence from popular cloud services (e.g. File storage and groupware solutions)
• Support for online services that can be operated as private instances, not depending on a 3rd party providers
• State-of-the-art support and integration for projects like Tor, MAT, secure-delete tools, etc.

How we know we succeeded

Static and runtime analysis tools, such as:

• Wireshark
• gdb
• [...]

KDE software can be audited for security vulnerabilities by security experts, organizations, and firms, such as:

• Mozila Open Source Support https://www.mozilla.org/en-US/moss/secure-open-source/
• Open Crypto Audit https://opencryptoaudit.org/
• Cure52 https://cure53.de/
• Least Authority https://leastauthority.com/
• NCC Group https://www.nccgroup.trust/
• Radically Open Security https://radicallyopensecurity.com/
• Trail of Bits https://www.trailofbits.com/

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)

"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 ♥

Relevant links

• General reading about cyber security standards: https://en.wikipedia.org/wiki/Cyber_security_standards
• NIST CSF: https://en.wikipedia.org/wiki/NIST_Cybersecurity_Framework
• RFC2196: https://tools.ietf.org/html/rfc2196
• Tor Project: https://www.torproject.org
• https://reproducible-builds.org/
• https://trustable.gitlab.io/
• http://blog.martin-graesslin.com/blog/2013/08/floss-after-prism-anonymity-by-default/
• https://blog.martin-graesslin.com/blog/2013/08/floss-after-prism-privacy-by-default/
• Schneier On Security; advocate, security professional: https://www.schneier.com/

I am willing to put work into this

• Andre Heinecke (@aheinecke)
• Bhushan Shah (@bshah)
• Ivan Čukić (@ivan)
• Jens Reuterberg (@jensreuterberg)
• Martin Flöser (@graesslin)
• Sandro Knauß (@knauss)
• Sebastian Kügler (@sebas)
• Valorie Zimmerman (@valorie) (writing, promo)
• Volker Krause (@vkrause)

I am interested

• Adrián Chaves (@adrianchavesfernandez)
• Aleix Pol
• Frederik Schwarzer
• Gregor Mi (@gregormi)
• Jacky Alcine (@jackyalcine)
• Lays Rodrigues (@laysrodrigues)
• Marco Martin (@mart)
• Nathaniel Graham
• Neofytos Kolokotronis (@neofytosk)
• Nicolas Fella (@nicolasfella)
• Olaf Schmidt-Wischhöfer
• Rishabh Gupta
• Sagar Hani (@sagarhani)
• Scott Harvey (@sharvey)
• Thomas Pfeiffer

see also T7050 for discussion about the sprint goal