top of page
Moderne Gebäudefassade

PRIVACY WISSEN

Wir stellen Ihnen eine kostenlose Wissensbibliothek zur Verfügung, die Ihnen dabei hilft, Ihre Privatsphäre und Ihren Datenschutz zu stärken oder wiederherzustellen. Wenn Sie tiefer in dieses Thema eintauchen möchten, bieten wir zudem individuelle Beratung, Veranstaltungen und Kurse an.

Basic-Privacy

Fußgängerüberweg in Bewegung

NEUER SCHRITT

„Kleine Änderungen können viel für Ihren Datenschutz bewirken. Schon einfache, sinnvolle Schritte bringen Sie deutlich weiter — je mehr Sie davon umsetzen, desto besser sind Ihre Daten geschützt.“

BROWSER

Viele Browser erfassen sehr viele Daten, wie man Klickt wo man wie viel zeit verbringt usw. Mit diesen Daten wird sehr viel Geld verdient. Dazu ist es ein großer schaden für die Privatsphäre. Die meisten nutzen heut zu Tage die Standard Installierten Browser oder so was wie Google Chrom. Wir Zeigen euch bessere Alternativen.

​

Mullvad Browser  [CLEARNET EMPFELHUNG]
Das Unternehmen Mullvad, bekannt für seinen Einsatz für die Privatsphäre, entwickelt gemeinsam mit dem Team hinter dem Tor-Browser einen neuen, normalen Clearnet-Browser. Dieser Browser soll Nutzern eine höhere Privatsphäre und Sicherheit im Internet bieten.
 

+ Starker Schutz vor Fingerprinting

+ Löscht Daten nach Sitzung

+ Basiert auf dem sicheren Tor-Browser
 

- Nur für Windows, macOS und Linux

- Nur im privaten Modus nutzbar

- Funktioniert nicht mit Streaming-Diensten

Webseite

​

​

LibreWolf Browser
Das Unternehmen LibreWolf, ein Fork des beliebten Firefox-Browsers, entwickelt einen Browser, der auf Freiheit, Sicherheit und Privatsphäre setzt. Der LibreWolf-Browser soll Nutzern eine Alternative zu herkömmlichen Browsern bieten, die ihre Daten und Privatsphäre respektiert.
 

+ Digital Rights Management (DRM) optional

+ Reduziert Sicherheitsrisiken

+ Löscht Daten nach Sitzung

​

- Nur für Windows, macOS und Linux

- Keine automatischen Updates

- Mit einigen Websites nicht kompatibel

​​​

Webseite

​​

​

Brave Browser
Der Brave-Browser ist ein innovativer Webbrowser, der von Brendan Eich, dem Mitbegründer von Mozilla, entwickelt wurde. Der Browser soll Nutzern eine schnellere, sicherere und privateres Internet-Erlebnis bieten.
 

+ Auf fast allen Geräten verfügbar

+ Kompatibel mit fast allen Websites

+ Basiert auf Chromium

​

- Beinhaltet Tracking und Werbung

- Erfordert viele Einstellungsanpassungen
- Beinhaltet Shitcoin (Altcoin) Funktion 

​

Webseite

 

​

Tor Browser [TOR-NETZWERK EMPFELHUNG]
Der Tor-Browser ist ein kostenloser, Open-Source-Webbrowser, der von der Tor-Projekt-Organisation entwickelt wird. Der Browser soll Nutzern eine anonyme und sichere Internet-Verbindung bieten, um ihre Privatsphäre und Identität zu schützen.
 

+ Starker Schutz vor Fingerprinting

+ Umgeht Zensur

+ Schützt vor Überwachung

​

- Keine iOS-Unterstützung

- Langsame Netzwerkgeschwindigkeit

- Websites sperren oft Zugang

​

Webseite

Einrichtung des Sicherheitsmonitors

Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say.

Edward Snowden 

SUCHE

Viele Suchmaschinen sammeln umfangreiche Daten — Suchanfragen, Klicks, Aufenthaltsdauer, Standort und mehr. Diese Daten werden oft kombiniert und monetarisiert (targeted advertising, Profilbildung) und sind ein erhebliches Privatsphäre‑Risiko. Viele nutzen standardmäßig die vorinstallierten Suchdienste oder große Anbieter wie Google. Hier zeigen wir bessere, datensparsamere Alternativen für die Suche.

​​

DuckDuckGo 
Fokus auf Privatsphäre durch Vermeidung von Nutzerprofilen; kombiniert eigene Relevanzsignale mit externen Indexquellen (vorwiegend Bing).

 

Technische, detaillierte Beschreibung
DuckDuckGo betreibt eine privacy‑first Suchoberfläche und kombiniert mehrere Ergebnisquellen: eigene Instant‑Answers (kuratierte Snippets), ein internes Relevanzmodell und Drittanbieter‑Feeds (großer Anteil aus Microsoft/Bing). Anfragen werden nicht zur Erstellung langfristiger Nutzerprofile gespeichert; IP‑Adressen und Identifikatoren werden nach eigener Aussage nicht langfristig behalten. Die Infrastruktur umfasst CDN‑Caches, API‑Integrationen für Instant‑Answers (Wikidata, OpenStreetMap, spezialisierte Datenquellen) und Tracker‑Blocking in offiziellen Extensions/Apps. Werbung wird kontextbasiert auf Suchbegriffe gematcht, nicht auf persistente Profile; Partnernetzwerke liefern Anzeigeninventar. Für Lokalisierung und personalisierte Relevanz fehlen persistente Signale, daher sind Geo‑abhängige oder Social‑kontextbasierte Treffer limitiert. Technische Schwächen: Abhängigkeit von externen Indizes beeinflusst Coverage bei Nischen‑, sehr neuen oder lokalisierten Inhalten; Ranking‑Algorithmen sind teilweise proprietär und nicht vollständig offen dokumentiert. Performance ist in Kernregionen (EU/NA) gut dank Caching, kann aber bei komplexen Proxy‑Aufrufen oder Instant‑Answer‑Aggregation mehr Latenz erzeugen. Sicherheit/Datenschutzmaßnahmen umfassen HTTPS‑Only, Tracker‑Blocking, Referrer‑Stripping bei App/Extension‑Features und eine Datenschutzrichtlinie mit minimaler Log‑Retention.

Vorteile

+ Suchergebnisse mehrheitlich von Bing

+ Werbung deaktivierbar

+ Individualisierte Darstellung möglich
 

Nachteile ​

- Beeinflusst Suchergebnisse

- Speichert Suchanfragen

- Server bei Microsoft

​

Webseite

​​

​

Startpage
Anonymer Proxy zu Googles Suchindex: Googles Ergebnisqualität, ohne direkte Weitergabe von Nutzerdaten an Google.

Technische, detaillierte Beschreibung
Startpage fungiert als Proxy/Anonymisierer vor Googles Suchindex: Suchanfragen laufen über Startpage‑Server, die Referrer, Cookies und IP‑Metadaten entfernen, bevor sie die Anfrage an Google weiterleiten. Die zurückgegebenen SERPs werden gefiltert und an den Nutzer ohne persönliche Identifikatoren ausgeliefert; zusätzlich bietet Startpage eine "anonyme Ansicht" (Proxy‑Rendering von Zielseiten) und die Option, Serverstandorte (z. B. EU vs. US) zu wählen, um Rechtsrahmen und Datenschutzverhalten zu beeinflussen. Monetarisierung erfolgt über Googles Werbeinfrastruktur, jedoch ohne Nutzungsdaten für Targeting. Technisch bedeutet die Proxy‑Schicht bessere Ergebnisqualität (Google‑Index) bei potenziell höherer Latenz und Abhängigkeit von Googles API/Index‑Änderungen. Logs werden minimal gehalten; allerdings sind Eigentümer- und Geschäftsinteressen weniger offen als bei reinen Open‑Source‑Projekten. Proxy‑Nutzung kann zu Problemen führen, wenn Google oder Drittanbieter Mechanismen gegen Scraping/Proxying aktivieren (CAPTCHAs, Sperrungen), was die Zuverlässigkeit öffentlicher Instanzen beeinträchtigen kann. Rechtlich ist die Proxy‑Architektur sensibel gegenüber internationalen Datenschutzregelungen und möglichen Anfragen seitens Behörden, je nach Sitz der Server.

Vorteile

+ Suchergebnisse von Google

+ Anonyme Ansicht von Websites

+ Serverstandort wählbar (EU/USA)

Nachteile

- Zeigt Werbung an

- Unklare Interessen der Inhaber

- Blockiert ab und zu VPN-Nutzer

​

Webseite

​​​

​

Brave Search
Eigenständiger Suchindex mit Fokus auf Unabhängigkeit vom großen Suchmaschinen‑Oligopol und integrierter Privatsphäre im Brave‑Ökosystem.

Technische, detaillierte Beschreibung
Brave Search baut einen eigenen Crawler‑basierten Index auf, ergänzt durch Aggregations‑Signale, um langfristig unabhängig von Google/Bing zu sein. Die Plattform verfolgt eine No‑Profile‑Policy: keine dauerhaften Nutzerprofile zur Personalisierung. Brave verwendet eigenständige Ranking‑Algorithmen, Community‑Feedback‑Signals und (teilweise) Maschinenlernmodelle zur Relevanzbewertung; einige Teile des Stacks sind proprietär, andere dokumentiert. Integration mit dem Brave‑Browser erlaubt zusätzliche Privacy‑Enforcement‑Pfade (z. B. lokale Blocklists, Script‑Blocking, Tor‑Integration), sowie mögliche Monetarisierungsmodelle über das Brave Rewards‑System (Token‑basierte Optionen) oder kontextuelle Anzeigen ohne Nutzerprofile. Technische Limitierungen sind der noch in Aufbau befindliche Index (Lücken bei Long‑Tail/Realtime‑Content), inkonsistente regionale Abdeckung und die Notwendigkeit, Crawler‑Kapazitäten zu erhöhen, um mit etablierten Indizes mitzuhalten. Die API‑Oberfläche bietet Suchendpunkte, aber nicht alle Datenpipelines sind Open‑Source. Performance hängt stark von Crawler‑Coverage, Cache‑Hit‑Rates und der Integrationstiefe im Browser‑Client ab.

Vorteile

+ Eigene Suchergebnisse

+ Transparente Suchergebnisse

+ AI-Zusammenfassungen und Code-Beispiele

​

Nachteile

- Zeigt Werbung an

- Einstellungen können nicht mittels Parametern gespeichert werden

- Server bei Amazon

​

Webseite

​​​

​

SearXNG oder Whoogle
Open‑Source Meta‑Suchfrontends/Proxies, die multiple Quellen aggregieren, Tracking entfernen und Self‑Hosting ermöglichen.

​

Technische, detaillierte Beschreibung
SearXNG und Whoogle sind proxy‑basierte Meta‑Suchlösungen: modular konfigurierbare Backends erlauben das Abfragen mehrerer Suchanbieter (Google, Bing, DuckDuckGo, Yandex, etc.), das Entfernen von Tracking‑Parametern und das Zusammenführen/Normalisieren der SERPs. Architektonisch bestehen sie aus Frontend‑Templates, einem Query‑Dispatcher, Source‑Adapters und einer Optional‑Cache/Rate‑Limit‑Schicht. Self‑Hosting bietet komplette Kontrolle über Log‑Retention, Konfiguration (z. B. welche Quellen, welche Parameter) und zusätzliche Plugins (z. B. Ergebnis‑Filter, Blacklists). Öffentliche Instanzen unterscheiden sich stark in Performance, Up‑Time und Aktualität. Quellen‑Aggregation reduziert Bias und erweitert Coverage, kann aber rechtliche/technische Probleme verursachen: viele Suchanbieter blockieren Scraper/Proxy‑Anfragen (403/CAPTCHA), was den Betrieb öffentlicher Instanzen erschwert. Für Selbsthoster sind nötige Komponenten: Webserver (Nginx), Reverse‑Proxy, TLS, Cron‑Jobs für Updates, Monitoring/Logging‑Stack, und ggf. ein Caching‑Layer (Redis) zur Entlastung. Sicherheitsaspekte: korrekte Härtung, regelmäßige Updates, IP‑Rate‑Limiting und Umgang mit API‑Keys (falls verwendet). Skalierung erfordert horizontale Instanzen und Load‑Balancing, besonders wenn viele Quellen parallel abgefragt werden.

​

Vorteile

+ Open‑Source

+ Selbsthostbar

+ Quellenmix
 

Nachteile

- Wartungsaufwand

- Instanz‑Qualität variiert

- Blockierungsrisiko​

Städtische Fahrradparkplätze

JETZT IM DEATIL UND BEQUEM

PRIVACY BERATUNG

PASSWORTMANAGER

Sie ermöglichen starke, einzigartige Passwörter für jede Seite, reduzieren so das Risiko von Kontoübernahmen und sparen Zeit durch automatisches Ausfüllen und integrierte Passwortgeneratoren. Viele Manager verschlüsseln den Tresor lokal oder end‑to‑end, bieten sicheren Sync zwischen Geräten und schützen vor Datenverlust. Außerdem helfen sie beim Aufräumen — sie weisen auf schwache, doppelt genutzte oder kompromittierte Passwörter hin. 

​

KeePassXC  [UNSERE EMPFELHUNG]
Lokaler, Open‑Source Passwortmanager für Desktop mit starker Verschlüsselung und umfangreichen Export/Import‑Options; ideal für Self‑Hosting und vollständige Datenkontrolle.

​

Technische, detaillierte Beschreibung
KeePassXC ist ein Fork des klassischen KeePass (Windows) in C++/Qt, der plattformübergreifend (Windows, macOS, Linux) als nativer Desktop‑Client läuft. Passwortdaten werden lokal in einer verschlüsselten Datenbankdatei (Standardformat: KDBX v4) gespeichert. Verschlüsselung: AES‑256‑CBC oder ChaCha20 (je nach Implementierung/Version), HMAC‑SHA‑256 zur Integritätsprüfung; Master‑Passphrase plus optionaler Schlüsseldatei erhöhen Entropie. KDF: Argon2id (konfigurierbare Iterationen/Memory/Parallelität) für Widerstand gegen Brute‑Force und GPU‑Angriffe. Features: TOTP‑Generierung, SSH‑Agent‑Integration, Browser‑Integration via native messaging (Extensions), Clipboard‑Timeouts, Auto‑type mit Fenster‑Selektoren, Datenbank‑Teilen via verschlüsselter Export/Sync über eigene Infrastruktur (z. B. Nextcloud, WebDAV, SMB) oder Cloud‑Speicher. Keine integrierte Cloud‑Sync‑Infrastruktur — Synchronisation erfordert externen Speicher/Tooling, was maximale Kontrolle erlaubt, aber Benutzerfreundlichkeit reduziert. Open‑Source‑Code (GPL‑3.0) ermöglicht Auditierung; Sicherheitsmodell beruht auf Sicherung des Master‑Passworts und Schutz des Geräts (OS‑level threat model). Backup/Recovery: einfache Datei‑Backup‑Strategien; Offline‑Wiederherstellung möglich. Einschränkungen: Mobile‑Support via Community‑Apps (z. B. KeePass2Android, Strongbox) mit Variationen in Feature‑Parity; gemeinsames Team‑Management erfordert Zusatzlösungen (z. B. synchronisierte KDBX in geteilten Ordnern) und ist weniger komfortabel als native Team‑Server.

​

Vorteile

+ Kostenlos

+ Benötigt keine Cloud

+ Vollständig Open-Source

Nachteile

- Keine offiziellen Android/iOS-Apps

- Synchronisierung aufwendig

​

Webseite

​​

​

Bitwarden
Open‑Source Passwortmanager mit Cloud‑Sync, End‑to‑End‑Verschlüsselung und Hosting‑Flexibilität (Cloud‑Service oder Self‑Host via Docker).

​

Technische, detaillierte Beschreibung
Bitwarden bietet Clients (Web, Desktop, Mobile, CLI) und einen Cloud‑Backend‑Service mit End‑to‑End‑Verschlüsselung. Vault‑Daten sind lokal verschlüsselt (Vor der Übertragung): AES‑256‑CBC für Inhalt, PBKDF2/HMAC‑SHA‑256 (konfigurierbare Iterationen) oder Argon2id in neueren Setups für Master‑Key‑Derivation; zusätzlich RSA für gewisse Schlüsselaustauschmechanismen (je nach Feature). Standardbetrieb: Bitwarden‑Server (hosted by Bitwarden) speichert nur verschlüsselte Cipher‑Objects; Entschlüsselung erfolgt clientseitig. Self‑Hosting: offizielles Bitwarden‑docker‑Stack (Vaultwarden als leichtgewichtigere Alternative/Community Fork) ermöglicht Hosting in eigenen Umgebungen; benötigt Reverse‑Proxy, TLS, Datenbank (MySQL/Postgres), und Background‑Workers. Features: Organisations‑Sharing mit Collections/Policies, TOTP‑Storage/Autofill, Browser‑Extensions, Enterprise‑SSO (SAML/OIDC), Audit‑Logs, API‑Zugriffe. Sicherheitspraktiken: regelmäßige Third‑Party‑Audits (extern), Bug‑Bounty‑Programme, optionale Zwei‑Faktor‑Methoden (U2F/WebAuthn). Threat‑Model: Vertraut auf sichere Master‑Passwortwahl und clientseitige Verschlüsselung; Server‑seitige Metadaten (z. B. Account‑Existenz, zeitliche Metadaten) können sichtbar sein. Performance: Cloud‑Sync schnell; Self‑Host Latenz abhängig von Hosting‑Infra. Backup/Recovery: Export verschlüsselter/backups möglich; bei Verlust Master‑Passwort ist Wiederherstellung ohne Recovery Seed nicht möglich.

 

Vorteile

+ Installation auf eigenem Server möglich

+ Einfaches Teilen mit anderen

+ Einfache Synchronisierung

​

Nachteile

- Kostenpflichtig für erweiterte Nutzung

- Metadaten auf Servern

- Komplexität beim Self‑Host

​

Webseite

​​

​

Proton Pass
Ein von Proton entwickelter, datenschutzfokussierter Passwortmanager mit End‑to‑End‑Verschlüsselung, enger Integration in Proton‑Ökosystem und starker Server‑Transparenz.

​

Technische, detaillierte Beschreibung
Proton Pass speichert Zugangsdaten verschlüsselt mit clientseitiger Ende‑zu‑End‑Verschlüsselung; Entschlüsselung findet nur auf Nutzergeräten statt. Kryptografie: AES‑256 für Daten, Argon2id als KDF (konfigurierbar/standardisiert) zur Ableitung des Master‑Schlüssels; HMAC zur Integritätsprüfung. Proton betreibt eigene Serverinfrastruktur in datenschutzfreundlichen Jurisdiktionen (Schweiz) mit strengen rechtlichen Rahmenbedingungen. Sync: Cloud‑Sync über Proton‑Server erlaubt Multi‑Device‑Zugriff; Server speichern ausschließlich verschlüsselte Objekte und minimierte Metadaten. Features: Browser‑Extensions, Mobile/Desktop‑Apps, Secure Sharing (Ende‑zu‑End‑verschlüsselte Freigaben), TOTP‑Speicherung, Password Health‑Checks, Passwort‑Generator, optionaler Passwort‑Erbe/Recovery‑Mechanismus. Enterprise-/Team‑Funktionen sind vorhanden, mit zusätzlicher Verwaltungsoberfläche. Proton legt Wert auf Transparenz, unabhängige Audits und Open‑Source‑Clients/SDKs; Teile der Infrastruktur sind proprietär, aber Kernclients und Protokolle werden offengelegt. Threat‑Model: Schutz gegen Serverkompromisse durch clientseitige Verschlüsselung; verbleibende Risiken sind schwache Master‑Passwörter, Gerätediebstahl ohne OS‑Schutz und mögliche Metadatenanalyse. Rechtliche Vorteile: Sitz in der Schweiz reduziert außenrechtliche Zugriffsmöglichkeiten; Proton veröffentlicht Transparency Reports und nutzt Privacy‑by‑Design.

​

Vorteile

+ Bietet Alias-E-Mail-Adressen an

+ Einfaches Teilen mit anderen

+ Einfache Synchronisierung

​

Nachteile

- Kostenpflichtig für erweiterte Nutzung

- Limitierte Funktionen
- Online Verbindung​

​

Webseite

MESSENGER

Sie liefern sensible Daten - Kontakte, Kommunikationszeiten, Inhalte. Viele Dienste sammeln Metadaten oder Nachrichten zur Analyse oder Werbung, was Profilbildung und Missbrauch ermöglicht. Privatsphäre ist deshalb wichtig: Ende‑zu‑Ende‑Verschlüsselung schützt Inhalte, minimale Metadatenspeicherung reduziert Rückschlüsse, und offene/dezentrale Lösungen verringern Abhängigkeit von einem Anbieter. Nutze datensparsame, E2E‑verschlüsselte Messenger mit transparentem Sicherheitsmodell, um Kommunikation sicherer zu machen.

​

Signal  [UNSERE EMPFELHUNG]
Ende‑zu‑End‑verschlüsselte, quelloffene Messaging‑App mit minimaler Metadatensammlung und starken Forward‑Secrecy‑Praktiken.

​

Technische, detaillierte Beschreibung
Signal nutzt das Signal‑Protokoll (Double Ratchet + X3DH + prekeys) für E2EE bei Nachrichten, Anrufen und Gruppen. Verschlüsselung: AEAD (XSalsa20‑Poly1305 bei älteren, XChaCha20‑Poly1305/AEAD in neueren Builds), Perfect Forward Secrecy & Zukunftssicherheit durch häufige Schlüsselrotation. Metadaten‑Minimalismus: Server speichert primär Telefonnummern (als Account‑Identifier), Verbindungs‑Logs sind minimal; Sealed Sender reduziert Server‑seitige Kenntnis über Sender/Empfänger‑Relationen. Gruppen: server‑seitig verwaltete Gruppen‑IDs mit client‑seitiger Verschlüsselung von Inhalten; zugehörige Metadaten (Teilnehmerliste) sind auf Server ersichtlich, aber Inhalte bleiben verschlüsselt. Client‑Architektur: Mobile (iOS/Android) & Desktop (Electron/Native) mit clientseitiger Schlüsselverwaltung; Sicherung: optionale verschlüsselte Backups (lokal oder Cloud, je nach Plattform). Code: größtenteils Open‑Source; regelmäßige Audits & Bug‑Bounty‑Programme. Threat‑Model: Schutz gegen Mit‑leser und Server‑Kompromisse; Telefonnummern‑basierte Identität ist Nachteil für Anonymität. Features: Sprach-/Videoanrufe (E2EE), disappearing messages, safety numbers, relay‑mediated large file transfer.

​

Vorteile

+ Sehr einfache und verständliche Handhabung

+ Weltweiter Einsatz

+ Breit anerkanntes Verschlüsselungsprotokoll



Nachteile

- Erfordert Telefonnummer

- Server bei Amazon, Google und Microsoft

- Intransparente Finanzierung

​

Webseite
 

! Molly erweitert Signal für Android um Datenbankverschlüsselung sowie Tor-Unterstützung und enthält keine proprietären Komponenten.

​​

​

Threema
Bezahlte, datensparsame Messaging‑App mit anonymen IDs (kein zwingender Telefonnummern‑/E‑Mail‑Zwang) und E2EE für Chat, Anrufe und Gruppen.

​

Technische, detaillierte Beschreibung
Threema erzeugt lokale, anonyme Threema‑IDs (Base64‑ID) statt Account‑Pflichtdaten; Kontakte können über QR/ID‑Austausch verifiziert werden. Kryptografie: NaCl/libsodium‑basierte primitives (Curve25519, XSalsa20‑Poly1305) für E2EE; Schlüssel werden clientseitig generiert und nie an Server übermittelt. Server‑Architektur: fungiert lediglich als Relay/Metadata‑Minimalist — notwendige Routing‑Infos, Gruppen‑Membership und Zustellungs‑Status werden temporär gehalten; kein Messaging‑Content auf Servern. Open‑Source‑Status: Client‑Apps größtenteils offen, Server‑Code und Betrieb nicht vollständig offen gelegt; regelmäßige Audits veröffentlicht. Features: Polls, Datei‑Transfer, Voice‑calls (E2EE), Unternehmens‑APIs (Threema Gateway). Backup/Recovery: verschlüsselte Backups möglich, aber Wiederherstellung ohne Backup schwierig. Business‑Use: erlaubt MDM/Enterprise‑Integrationen. Threat‑Model: schützt Kommunikation vor Dritten; anonyme ID‑Modell reduziert Linkability, aber Käufe/App‑Store‑Requirements können Zahlungs‑/Device‑Metadaten erzeugen.

 

Vorteile

+ Eigene Infrastruktur in der Schweiz

+ Anonyme Nutzung möglich

+ Einfache und benutzerfreundliche Handhabung

​

Nachteile

- Kostenpflichtig

- Mehrheitlich Nutzer in Europa

- Server nicht Open-Source

​

Webseite

​​

​

SimpleXChat [UNSERE PROFIE EMPFELHUNG]
Dezentralisierte, verschlüsselnde Messaging‑App mit Fokus auf Anonymität und Meta‑Datenreduktion; funktioniert ohne Telefonnummer.

​

Technische, detaillierte BeschreibungSimpleXChat (SimpleX) ist ein föderiertes/dezentralisierbares Messaging‑Protokoll/Client, das E2EE für Nachrichten anbietet und Identity‑Modelle ohne Telefonnummern ermöglicht (z. B. eigenständige IDs oder Server‑Accounts). Architektur: Clients kommunizieren über SimpleX‑Server/Relays; Nachrichten werden clientseitig verschlüsselt (typische primitives: Curve25519/ECDH + AEAD like XChaCha20‑Poly1305). Meta‑Daten‑Minimierung durch Onion‑Routing‑ähnliche Relay‑Nutzung und Verzicht auf Telefonnummern‑Bindung. Features: Multi‑Device‑Support je nach Server‑Implementation, Channel/Group‑Funktionalität, und optional peer‑to‑peer Betriebsmodi. Open‑Source‑Projekte existieren; Implementierungsdetails variieren zwischen Clients/Server‑Projekten. Threat‑Model: Gute Anonymität bei korrekter Relay‑Konfiguration; zentrale Punkte sind Relay‑Betreiber und mögliche Timing‑Attacks; keine breite Audit‑Historie wie etablierte Projekte.

​

Vorteile

+ Dezentral

+ Keinerlei Identifikatoren (anonym)

+ Moderne Architektur

​

Nachteile

- Komplizierte Handhabung

- Unvorteilhafte Finanzierung

- Keine Gruppenanrufe

​

Webseite

​

​

Session
Server‑minimierende, onion‑routing‑basierte Messaging‑App ohne Telefonnummern, konzipiert für maximale Anonymität und reduzierte Metadaten.

​

Technische, detaillierte Beschreibung
Session verwendet ein lokales Onion‑Routing/Service‑Node‑Netzwerk (Lokale ähnlich I2P/Libp2p) und dezentralisierte Service‑Nodes, um Nachrichten ohne klassischen Server‑Account zu routen. Identität basiert auf Public‑Key‑IDs, nicht Telefonnummern oder E‑Mail. Kryptografie: Double Ratchet‑ähnliche Mechanismen + X3DH‑ähnliche Key‑Agreement + AEAD für Nachrichten; zusätzliche Onion‑Layer verschleiern Sender‑Empfänger‑Beziehungen gegenüber Relay‑Nodes. Meta‑datenminimalismus: keine zentralen Adresslisten, keine Telefonnummern, keine IP‑Bindung in Profilen; allerdings Service‑Nodes sehen Relay‑Metadaten (aber nicht Nachrichtentext). Gruppen: unterstützt E2EE‑Gruppen via client‑seitige Key‑Management. Open‑Source; Community‑Audits und Bug‑Bounty vorhanden. Limitierungen: Latenz höher durch Onion‑Routing, komplexere Multi‑Device‑Sync, kleinere Nutzerbasis und weniger Client‑Feature‑Parität vs. Mainstream. Threat‑Model: Resistenz gegen Server‑seitige Metadatenanalyse; Verwundbar gegenüber korrupten/kooperierenden Service‑Node‑Betreibern bei fortgeschrittenen Traffic‑Analysis‑Angriffen.

​

Vorteile

+ Dezentral

+ Anonym

+ Umgeht Zensur (Onion-Routing)

​

Nachteile

- Komplizierte Handhabung

- Keine Perfect Forward Secrecy (PFS)

- Keine Einzelanrufe (Beta) und Gruppenanrufe

​

Webseite

​

​

Element (Matrix)
Client für Matrix‑Protokoll: dezentrale, föderierte Kommunikation mit E2EE‑Option (Megolm/Olm) und starkem Fokus auf Interoperabilität und Team‑/Community‑Use‑Cases.

​

Technische, detaillierte Beschreibung
Element (früher Riot) ist ein Client für das Matrix‑Ökosystem. Matrix ist ein offenes, föderiertes Protokoll mit dezentralen Homeservers (Synapse, Dendrite u.a.). Verschlüsselung: Olm (für 1:1) und Megolm (für Gruppen) implementieren Double Ratchet‑Varianten; Gruppen‑Megolm verwendet Sender Keys für Effizienz, was gewisse Risiken bei Gruppen‑Forward‑Secrecy erschwert im Vergleich zu Double Ratchet pro Empfänger. Federation: Homeserver replizieren Ereignisse via federation APIs; Server‑Operatoren sehen Metadaten für ihre Domäne (Raum‑Membership, Event‑Metadaten) und können Admin‑Kontrolle ausüben. Features: Persistent Rooms, Bridge‑Funktionalität zu anderen Netzwerken (IRC, Slack), VoIP, Datei‑Freigabe, Bots, Reactions, Threading. Client‑Implementierungen: Desktop, Web, Mobile; E2EE optional und standardmäßig für private Chats empfohlen. Self‑Hosting: Homeserver leicht selbst zu hosten (Synapse/Dendrite), aber Admins müssen Schlüssel‑Backup, Device‑Management, Push‑Gateways und E2EE Key‑Rotation beachten. Threat‑Model: Föderation erhöht Angriffsoberfläche (verschiedene Server‑Operatoren), aber Open‑Standard fördert Interoperabilität. Umfangreiche Audit‑Historie und aktive Entwicklung.

​

Vorteile

+ Föderiert nutzbar

+ Anonyme Nutzung möglich

+ Transparente Finanzierung

​

Nachteile

- Komplizierte Handhabung

- Hinterlässt viele Metadaten

- Eher für Organisationen geeignet
 

Webseite

​

​

Briar
Peer‑to‑peer Messaging über Tor/Bluetooth/Wi‑Fi‑Direct ohne zentrale Server; ideal für Offline‑/Mesh‑Kommunikation mit E2EE.

​

Technische, detaillierte BeschreibungBriar ist ein P2P‑Messenger, der Nachrichten direkt zwischen Geräten synchronisiert über Tor (internetbasiert) oder lokal via Bluetooth/Wi‑Fi‑Direct. Identitäten basieren auf Public Keys; keine Telefonnummern oder zentralen Accounts. Kryptografie: E2EE mit Double Ratchet/Curve25519 + AEAD, metadata‑resistant Design: Nachrichten werden nicht an zentrale Server gesendet, wodurch Metadaten minimiert werden. Synchronisations: Bei Tor‑Verbindungen nutzen Peers Tor Hidden Services (Onion Services) für Erreichbarkeit; bei lokalen Verbindungen erfolgt direkte Peer‑to‑Peer‑Kommunikation. Offline‑Fähigkeiten: Nachrichten werden im Gerät gespeichert und übertragen, wenn Verbindung möglich; ideal für Zonen mit Netz‑Einschränkungen. Open‑Source, ausgerichtet auf Journalist/Activist‑Usecases. Einschränkungen: Usability und Performance bei Multi‑Device; Anhängig von Tor‑Netzwerk für Internet‑P2P; begrenzte Multimedia‑Performance; kleinere Nutzerbasis. Threat‑Model: Resilient gegen Server‑Kompromisse und Zensur; anfällig für physische Gerät‑Kompromittierung und lokale Traffic‑Analysis bei Bluetooth/Wi‑Fi.

​

Vorteile

+ Dezentral

+ Anonym

+ Ohne Internet nutzbar

​

Nachteile

- Komplizierte Handhabung

- Keine iOS-Unterstützung

- Keine Sprachnachrichten und Anrufe

​

Webseite

Netzwerkkabelverbindungen

„Privacy is not an option, and it shouldn't be the price we accept for just getting on the Internet.“

Gary Kovacs

VPN

VPN‑Anbieter können deine Netzwerkverbindung schützen, aber sie sehen viel: besuchte Seiten, Verbindungszeiten und ggf. deine IP‑Adresse. Viele Anbieter protokollieren Daten oder verkaufen Nutzungsinformationen, was Privatsphäre und Anonymität untergräbt. Deshalb ist Wahl wichtig: nutze Anbieter mit klarer No‑Logs‑Policy, transparenter Unternehmensstruktur, unabhängigen Audits und idealerweise in datenschutzfreundlichen Jurisdiktionen. Verschlüsselte Tunnel schützen Daten in unsicheren Netzwerken und maskieren die IP, aber ein vertrauenswürdiger Anbieter ist nötig, damit diese Schutzwirkung nicht durch Logging oder Datenweitergabe aufgehoben wird.

​

Mullvad VPN [UNSERE EMPFELHUNG]
Stark auf Privatsphäre fokussierter VPN‑Provider mit anonymer Kontoführung (kein Account/Email), klarer Transparenz und einfachem Preis-/Pay‑as‑you‑go‑Modell.

​

Technische, detaillierte Beschreibung
Mullvad betreibt ein dezidiertes VPN‑Netzwerk mit eigenen Servern und Miet‑Rechenzentren in mehreren Ländern. Konto‑Modell: anonyme Kontonummer statt E‑Mail/Benutzerkonto; Zahlung per Bargeld, Krypto oder Karte möglich. Protokolle/Implementierung: OpenVPN und WireGuard werden unterstützt; WireGuard‑Keys rotieren clientseitig und sind per Konto zuordnungsfrei. Kryptografie: WireGuard (ChaCha20‑Poly1305), OpenVPN (AES‑256‑GCM, TLS‑1.2/1.3 für Handshake), Perfect Forward Secrecy (ECDHE). Log‑Policy: strikte No‑Logs, minimierte Telemetrie; externe Audits & RAM‑disks für Keys/Logs auf Servern sind üblich (stateless setup). DNS: eigene DNS‑Resolver/optional DNS‑leak protection; IPv6 Leak‑Handling und kill‑switch in Clients. Server‑infrastruktur: Kombination aus eigenen und gemieteten physikalischen/virtuellen Servern; einige Standorte als “bare‑metal” für erhöhte Kontrolle. Threat‑Model: Schutz gegen ISP‑Monitoring, Geolocation‑Basierte Sperren je nach Standort, reduzierte Angriffsfläche durch minimale Metadaten. Performance: WireGuard bietet niedrige Latenz und höhere Durchsatzraten; Server‑Load/Bandbreite variiert je Standort. Rechtliche/Transparenzaspekte: Veröffentlichte Transparenzberichte, gelegentliche unabhängige Audits; Jurisdiktion: Schweden (mit entsprechenden gesetzlichen Rahmenbedingungen).

​

Vorteile

+ Starke Ethik und Transparenz

+ Integrierter Ad-/Content-Blocker

+ Server laufen im Arbeitsspeicher


Nachteile

- Funktioniert nicht mit Streaming-Diensten

- Keine Port-Weiterleitung möglich

​

Webseite

​​

​

IVPN
Datenschutzorientierter Provider mit starker No‑Logs‑Politik, optionalem Multi‑Hop und Fokus auf technische Transparenz und Sicherheitsfeatures.

​

Technische, detaillierte Beschreibung
IVPN betreibt ein internationales Servernetzwerk, legt besonderen Wert auf Auditierbarkeit und minimierte Metadaten. Protokolle: WireGuard und OpenVPN; Implementierungen nutzen moderne Cipher‑Suites (ChaCha20‑Poly1305, AES‑GCM), TLS 1.3 für Handshakes. Multi‑Hop (Gateway über mehrere Länder) sowie Split‑Tunneling, Port‑forwarding (optional) und configurable DNS (eigene Resolver) sind supported. Account‑Modell erfordert Registrierung, bietet aber optionale anonyme Zahlungsmethoden (Krypto, Barzahlungen per Post). Logging: strikte No‑Logs, minimaler Verbindungs‑Telemetrie; unabhängige Audits und detaillierte Transparenzdokumente vorhanden. Server‑Setups: Mischung aus eigenen und angemieteten Servern; einige kritische Server als RAM‑disk konfiguriert. Privacy‑Features: kill‑switch, IPv6‑Leak‑Protection, Obfuscation/Stealth‑Optionen gegen DPI/Blockade in restriktiven Netzen. Performance: WireGuard‑Optimierungen für gute Durchsatzraten; Multi‑Hop reduziert Geschwindigkeit proportional zur Anzahl Hops. Compliance/Legal: Sitz in Gibraltar/UK‑naher Rahmen (je nach Firmenstruktur), mit klaren Richtlinien zu Drittanfragen und Transparenzberichten.

 

Vorteile

+ Starke Ethik

+ Apps für fast alle Geräte

+ Integrierter Ad-/Content-Blocker

​

Nachteile

- Funktioniert nicht mit Streaming-Diensten

- Keine Port-Weiterleitung möglich

- Gemietete Server

​

Webseite

​​

​

Proton Pass
VPN-Angebot des Proton‑Ökosystems (ProtonMail etc.), starker Datenschutzfokus, transparente Rechtslage (Schweiz) und zusätzliche Sicherheitsfunktionen (Secure Core).

​

Technische, detaillierte Beschreibung
Proton VPN betreibt ein globales Servernetzwerk mit eigenen Secure‑Core‑Servern in datenschutzfreundlichen Jurisdiktionen (Schweiz, Island, Schweden) — Traffic kann zuerst durch diese Server geroutet werden, um Risiken durch kompromittierte Exit‑Server zu reduzieren. Protokolle: WireGuard, OpenVPN (AES‑GCM/ChaCha20), IKEv2 in bestimmten Clients; Perfect Forward Secrecy durch ECDHE. Kryptografie und KDF sind industrieweiter Standard (ChaCha20‑Poly1305, AES‑256‑GCM). Logging: strikte No‑Logs‑Policy; Server laufen häufig in RAM‑Disk‑Modus; Proton veröffentlicht Transparenzberichte und nutzt die Schweiz als juristische Basis. Features: Secure Core (Multi‑Hop innerhalb vertrauenswürdiger Jurisdiktionen), Tor over VPN (Einstieg direkt ins Tor‑Netzwerk), P2P‑optimierte Server, DNS‑Leak‑Protection, kill‑switch, SSO/Account‑Integration mit Proton‑Ecosystem. Performance: Secure‑Core erhöht Latenz, normale WireGuard‑Verbindungen schnell; Serverqualität hoch aufgrund eigener Infrastruktur in vielen Ländern. Sicherheit: starke Operational‑Security‑Practices, unabhängige Audits; Integrationen für Mobile/Desktop/Router.

​

Vorteile

+ Kostenlose Nutzung möglich

+ Apps für fast alle Geräte

+ Integrierter Ad-/Content-Blocker

​

Nachteile

- ​Mehrheitlich gemietete Server

- Manchmal langsame Datenübertragungsrate

- Langsamer Prozess bei Barzahlung

​

Webseite

​

​

Safing Privacy Netwerk
Europäischer Datenschutzfokus mit Open‑Source‑Tools (Portmaster, Schild) und Wunsch nach sauberer, auditierbarer Netzwerk‑Kontrolle statt reiner VPN‑Kommerzlösungen.

​

Technische, detaillierte Beschreibung
Safing betreibt Projekte wie Portmaster (Netzwerk‑Firewall/Privacy‑Hub) und SchildVPN als VPN‑Service; starker Open‑Source‑Ansatz und Fokus auf Transparenz. Architektur: Clients integrieren lokale Netzwerk‑Kontrolle (Portmaster) zur Filterung von Tracking‑Domains, DNS‑Anfragen und zum Erzwingen von VPN‑Routen. SchildVPN nutzt WireGuard/OpenVPN Backends mit eigener Serverinfrastruktur; Kryptografie entspricht modernen Standards (ChaCha20‑Poly1305, AES‑GCM). Datenschutz: Open‑Source‑Clients ermöglichen Code‑Audits; Logging minimal gehalten, mit Fokus auf Nutzer‑Kontrolle über Telemetrie. Features: detaillierte App‑/Flow‑Kontrolle (Portmaster), DNS‑Filtering, lokal durchsetzbare Privacy‑Regeln, sowie optionale VPN‑Verbindungen für Traffic‑Tunneling. Self‑Hosting/On‑Premise: Portmaster kann unabhängig betrieben werden; für große Deployments sind jedoch technische Kenntnisse nötig. Performance: WireGuard‑basierte Routen liefern gute Durchsatzraten, lokale Paket‑Filtering kann CPU‑Last erzeugen. Jurisdiktion/Transparenz: EU‑basiert (Deutschland), mit offengelegtem Quellcode und Community‑Fokus; jedoch juristische Rahmenbedingungen der EU/DE sind zu beachten (ggf. Ermittlungsanfragen). Threat‑Model: richtet sich an Nutzer, die aktive Kontrolle über ausgehenden Traffic und DNS‑Auflösung wünschen, kombiniert VPN‑Privatsphäre mit lokalen Privacy‑Enforcement‑Mechanismen.

​

Vorteile

+ Neuartige Mischung aus Tor und VPN

+ Individuelle IP-Adresse und Route pro Ziel

+ Starke, verwaltbare Firewall

​

Nachteile

- Nur für Windows und Linux

- Anspruchsvolle Nutzung

- Limitierte Anzahl Server

​

Webseite

DNS

DNS‑/Netzwerk‑Blocker sind nützlich, weil sie Werbung, Tracker und bösartige Domains bereits auf Netzwerk‑Ebene stoppen, bevor Inhalte Geräte oder Browser erreichen. Das reduziert Tracking, beschleunigt Laden von Seiten, spart Bandbreite und verringert Angriffsflächen für Malware. Selbstgehostete Lösungen schützen alle Geräte im Heimnetz und geben dir volle Kontrolle über Blocklisten und Logs statt Daten an Drittanbieter weiterzugeben. Einschränkungen gibt es — Fingerprinting oder serverseitiges Tracking werden nicht vollständig verhindert — aber als Teil einer mehrschichtigen Privacy‑Strategie sind Netzwerk‑level Blocker ein effektiver, wartungsarmer Schutzmechanismus.

​

Pi-Hole
Netzwerkweiter DNS‑Level Ad‑/Tracker‑Blocker, selbst gehostet auf lokalen Geräten (z. B. Raspberry Pi) — blockiert Werbung/Tracking für alle Geräte im LAN durch DNS‑Filterung.

​

Technische, detaillierte Beschreibung
Pi‑hole läuft als DNS‑Resolver/Forwarder (oft auf dnsmasq oder FTL‑Daemon basierend) und fungiert als primärer DNS‑Server für das lokale Netzwerk. Anfragen der Clients landen bei Pi‑hole; basierend auf konfigurierten Block‑/Whitelist‑Regeln, Regex‑Patterns und Listen (z. B. EasyList, Peter Lowe) wird entweder eine Block‑Antwort (NXDOMAIN, 0.0.0.0 oder eine lokale IP) zurückgegeben oder die Anfrage an Upstream‑Resolver weitergeleitet. Komponenten: Web‑UI (Verwaltung/Statistiken), FTL (Faster‑Than‑Light DNS Engine) für Query‑Handling und Caching, Query‑Logs und Query‑Analytics. Upstream‑Resolver: konfigurierbar (Cloudflare, Google, Quad9, DoT/DoH‑Backends, oder privater recursive Resolver). DNS‑Blocking‑Methoden: exact host blocking, wildcard/regex, gravity lists; unterstützt conditional forwarding, DHCP‑Integration (oder DHCP passt Pi‑hole als DNS via Router). Privacy & Security: lokal gehostete Queries vermeiden ISP‑Logging; jedoch Upstream‑Resolver kann Metadaten sehen—Empfehlung: Upstream per DNS‑over‑TLS/HTTPS (DoT/DoH) verschlüsseln. Unterstützt DNS‑SEC validation (je nach Upstream), custom blocking pages, client‑grouping (via regex/conditional forwarding) und per‑client overrides. Performance & Skalierung: Geeignet für Haushalte/SMBs; auf größeren Netzen sind CPU/Memory‑Limits und FTL‑Skalierung relevant; Caching reduziert Latenz, aber große Blocklists erhöhen Memory‑Footprint. Wartung: Regelmäßige Updates der Blocklists, Sicherung der Konfigurationsdateien, Monitoring (FTL logs, query metrics). Bypass‑Risiken: DNS‑over‑HTTPS direkt am Client, hardcoded DNS in apps, encrypted SNI/DoH can bypass Pi‑hole unless network routes blocked; IPv6 considerations require IPv6 support/enforcement. Threat‑Model: Schützt vor domain‑based tracking and ads, nicht gegen TLS‑level tracking or content‑injection post‑DNS. Failure modes: misconfigured whitelists can break services; local DNS outage affects whole LAN unless fallbacks configured.

​

Vorteile

+ Netzwerkweit blockiert
+ Einfache UI & Stats
+ Vollständig self‑hosted


Nachteile

- DoH/DoT‑Bypass möglich
- IPv6/Router‑Config nötig
- Pflege von Listen erforderlich

​

Webseite

​​

​

AdGuard Home  [UNSERE EMPFELHUNG]
Self‑hostable DNS/HTTP(S)‑level blocker mit erweiterten Filtermöglichkeiten, integrierter DNS‑Proxy, und zusätzlicher HTTP‑filtering‑Funktionalität für Clients.

​

Technische, detaillierte Beschreibung
AdGuard Home kombiniert einen DNS‑Resolver/forwarder mit erweiterten Filter‑Features und einer Benutzeroberfläche zur Verwaltung von Blocklisten, DNS rewrite rules, client‑gruppierung und DNS‑over‑HTTPS/TLS‑Endpoints. Implementierung nutzt eigenen DNS‑Stack mit Caching, Query‑Processing Pipeline und optionalem HTTP(S)‑Proxy‑Modul für tiefere Filterung. Blockmechanismen: domain blocking (NXDOMAIN/0.0.0.0), regex/wildcard, element‑hiding für HTTP content filtering (bei aktiviertem proxy), custom DNS records, parental controls, SafeSearch force, and upstream DNS configuration including DoH/DoT and upstream forwarded recursion. Privacy & Security: unterstützt DoH/DoT server endpoints to encrypt upstream queries; logging configurable with retention policies; integrated TLS for admin UI. Performance & Scaling: performant for home/SMB; built‑in HTTP proxy can increase resource usage when content filtering enabled. Integration: client grouping, per‑client filter rules, DHCP integration optional; supports conditional forwarding and split‑DNS. Advanced Features: DNS rewrites, upstream fallback, DNSSEC validation support (configurable), analytics/queries dashboard, API for automation. Bypass & Limitations: clients using own DoH/DoT bypass local resolver unless network‑level blocking of those endpoints is enforced (firewall/transparent proxy); HTTPS content filtering requires proxying and breaks end‑to‑end semantics unless implemented as local transparent proxy with TLS interception (not default). Operational considerations: maintain filter lists, update software, secure admin endpoint (strong password, TLS), backups. Threat‑Model: reduces domain‑based tracking/ad delivery; not a substitute for endpoint security or traffic inspection at TLS layer.

 

Vorteile

+ Erweiterte Filter & Regeln
+ DoH/DoT‑Endpoints integriert
+ Per‑Client Regeln & UI

​

Nachteile

- HTTP‑Proxy erhöht Ressourcenbedarf
- DoH‑Bypass möglich
- Admin‑Interface absichern nötig

​

Webseite​

Busen mit Bitcoin-Brille

SCHÜTZE DICH UND DEINE ZUKUNFT

BITCOIN PRIVACY

2FA

Zwei‑Faktor‑Authentifizierung (2FA) ist wichtig, weil sie Konten trotz gestohlener Passwörter schützt: selbst wenn Angreifer das Passwort haben, benötigen sie den zweiten Faktor (z. B. Einmalcode oder Hardware‑Token), um sich anzumelden. 2FA reduziert Account‑Übernahmen, verhindert automatisierte Brute‑Force‑Angriffe und limitiert Schaden bei Datenlecks. Hardware‑basierte Token (FIDO/WebAuthn, YubiKey) bieten den stärksten Schutz gegen Phishing; TOTP‑Apps sind ein guter Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit; SMS ist besser als nichts, aber anfällig für SIM‑Swap‑Angriffe. Kurz: 2FA macht Konten deutlich sicherer und sollte überall dort aktiviert werden, wo sensible Daten oder finanzielle Zugänge bestehen.

​

Ente Auth
Leichter, quelloffener TOTP‑Authenticator mit Fokus auf Einfachheit, Datenschutz und portabler Speicherung (Export/Import).

​

Technische, detaillierte Beschreibung
Ente Auth ist eine minimalistische, Open‑Source‑TOTP/ HOTP‑App (RFC 6238 / RFC 4226) für mobile Geräte, die grundlegende 2FA‑Funktionen ohne Kontolock‑Infrastruktur bietet. Schlüsselmaterial (Shared Secrets) wird lokal auf dem Gerät gespeichert; Export/Import erfolgt meist über verschlüsselte Dateien (optional mit Passwort) oder standardisierte URIs (otpauth://). Kryptographie: HMAC‑SHA1/‑SHA256 für TOTP/HOTP, variable Time‑step (Standard 30s) und configurable digit length (6/8). Backup‑Modelle hängen von App‑Implementierung ab—manche Versionen erlauben verschlüsselten Datei‑Export, andere raten zu manuellem Backup des Secrets. Kein Cloud‑Sync oder Account‑Verknüpfung, daher geringere Angriffsfläche gegenüber Server‑kompromittierungen, aber erhöhtes Risiko bei Geräteverlust ohne Backup. Integration: Scan von QR‑Codes, manuelle Eingabe, Einstellungsoptionen für Token‑Labeling und Sortierung. Open‑Source‑Status erlaubt Auditierung; Usability ist bewusst reduziert, geeignet für Nutzer, die lokale Kontrolle und minimale Angriffsoberfläche bevorzugen.

​

Vorteile

+ Lokal & Open‑Source
+ Einfach & leichtgewichtig
+ Kein Cloud‑Sync


Nachteile

- Backup manuell nötig
- Kein Multi‑Device‑Sync
- Basis‑Feature‑Set (kein Push/Smart‑Key)
 

Webseite

​​

​

Aegis Authenticator  [UNSERE EMPFELHUNG]
Feature‑reiche, Open‑Source TOTP/HOTP‑App für Android mit verschlüsseltem Vault, Backup/Restore und Import/Export‑Funktionen; stark auf Sicherheit und Usability ausgelegt.

​

Technische, detaillierte Beschreibung
Aegis implementiert TOTP/HOTP (RFC 6238/4226) mit Unterstützung für HMAC‑SHA1/256/512, anpassbare Time‑step/Length und Labels/Icons/Tags zur Organisation. Schlüssel werden in einem verschlüsselten lokalen Vault gehalten (AES‑GCM), mit Master‑Passwort/PIN und optionaler Biometrie‑Entsperrung; KDF: Argon2id/PBKDF2‑Konfigurationen zur Ableitung des Vault‑Keys (je nach Version). Backup/Restore: verschlüsselter Export (enc‑file) und integrierte Cloud‑Sync‑Optionen über Benutzer‑gewählte Speicher (verschlüsselt), sowie Wiederherstellung via Passwort; unterstützt auch CSV/otpauth‑URI‑Import. Multi‑Device: kein automatischer proprietärer Sync – Synchronisation erfordert verschlüsseltes Export/Cloud‑Speicher oder Dritt‑Sync‑Lösung. Zusätzliche Features: Counter‑based HOTP, touch‑to‑copy, pin‑protected clipboard timeout, secure deletion of secrets, and QR‑scan with manual edit. Open‑Source (GPL/MIT je nach Komponenten) und aktiv gepflegt; ermöglicht Auditierung. Threat‑Model: Schutz gegen local‑file exfiltration durch Vault‑Encryption; verbleibende Risiken sind schwache Master‑Passwörter, Android‑OS‑level compromise, und unsichere Backup‑Speicherung.

 

Vorteile

+ Verschlüsselter Vault
+ Backup/Export/Import
+ Viele Anpassungsoptionen

​

Nachteile

- Kein nahtloser Multi‑Device Sync
- Android‑only
- Richtige Backup‑Praxis nötig

​

Webseite​

E-MAIL

Privacy‑E‑Mail‑Anbieter schützen deine Kommunikation durch starke Verschlüsselung, minimale Metadatenspeicherung und No‑Logs‑Richtlinien. Sie vermeiden Werbung und Verkauf von Daten, bieten transparentere Datenschutzpraktiken und oft Hosting in datenschutzfreundlichen Jurisdiktionen. Nachteile: E2E‑Verschlüsselung erfordert oft Setup und Anbieter sehen weiterhin Verbindungs‑Metadaten; die Usability ist teils eingeschränkter als bei Mainstream‑Diensten. Insgesamt sind sie empfehlenswert für vertrauliche Kommunikation.

​

Proton Mail  [UNSERE EMPFELHUNG]
Ende‑zu‑End‑verschlüsselte, datenschutzorientierte E‑Mail‑Plattform mit Server‑Standort in der Schweiz, nahtloser Integration ins Proton‑Ökosystem und Fokus auf Benutzer‑Privatsphäre.

​

Technische, detaillierte Beschreibung
Architektur: Clientseitige Ende‑zu‑End‑Verschlüsselung für Nachrichten zwischen Proton‑Konten; Server speichern nur verschlüsselte Cipher‑Blobs. Schlüsselmanagement: private/public‑Key‑Paare werden clientseitig erzeugt; private Keys sind durch das Benutzerpasswort verschlüsselt (KDF: Argon2id/PBKDF2‑Parameter variieren). Verschlüsselung: symmetrisch AES‑256‑GCM für Inhalt/Anhänge, asymmetrische Verfahren (RSA/ECC je nach Implementation) für Key‑Wrap; TLS (STARTTLS/Direct TLS) sichert Transport zu externen Servern. Features: verschlüsselte Nachrichten an Nicht‑Proton‑Nutzer (Passwortschutz), selbstzerstörende Nachrichten, integrierte Spam/Anti‑Abuse‑Mechanismen (Server‑seitig auf Metadaten), Bridge‑Tools für IMAP/SMTP‑Clients (entschlüsselnd lokal). Infrastruktur & Datenschutz: Hosting in der Schweiz mit strenger Rechtslage; Server‑Sicherheit umfasst RAM‑disk‑Nutzung für temporäre Schlüssel, regelmäßige Audits und Transparenzberichte. Metadaten: Proton reduziert Logging, aber gewisse technische Metadaten (Zeitstempel, Absender/Empfänger, IP‑Zugriffslogs je nach Policy) können vorhanden sein; verschlüsselte Inhalte bleiben geschützt. Recovery/Backup: verschlüsselte Schlüssel‑Backups möglich; ohne Master‑Passwort kann E2EE‑Inhalte schwer wiederherstellbar sein. Einschränkungen: E2EE nur vollständig zwischen Proton‑Konten; externe E‑Mail‑Interoperabilität erfordert Passwort‑geschützte Nachrichten oder PGP‑Workflows. Threat‑Model: schützt vor Mailserver‑Operatoren und Drittlesern; Risiken verbleiben bei Endgerätkompromittierung, schwachen Passwörtern oder inkorrekter Backup‑Handhabung.

​

Vorteile

+ Server in der Schweiz

+ Bezahlung mit Bargeld möglich

+ Nutzung mit bekannten Mailprogrammen möglich


Nachteile

- Unverschlüsselte Betreffzeilen

- Kontoerstellung teils aufwendig

- Langsamer Prozess bei Barzahlung

​

Webseite

​​

​

Tuta Mail (Tutanota)
Ende‑zu‑End‑verschlüsselte E‑Mail‑Plattform mit Fokus auf Open‑Source‑Clients, integrierter verschlüsselter Suche und Speicherung von verschlüsselten Daten auf eigenen Servern in EU‑Jurisdiktionen.

​

Technische, detaillierte Beschreibung
Architektur: Komplett clientseitige Verschlüsselung für E‑Mails, Kontakte und Kalender‑Daten; Server speichern nur verschlüsselte Inhalte. Schlüsselmanagement: Account‑Keys werden clientseitig generiert; zum Teil wird eine Kombination aus Passwort‑verschlüsselten Private‑Keys und server‑seitig unterstützten Rekovierungs‑Mechanismen genutzt (KDF: Argon2id/PBKDF2‑ähnliche Parameter). Verschlüsselung: symmetrisch AES‑256‑GCM für Inhalte; asynchrone Schlüsselmechanismen für Versand an externe Empfänger (bei Nicht‑Tutanota‑Empfängern optional Passwort‑geschützte Nachrichten). Transport: TLS für SMTP/IMAP/Bridge; Tutanota verwendet eigene verschlüsselte Mail‑Workflows statt klassischem PGP in der UI (keine native PGP‑Integration standardmäßig). Features: verschlüsselte Volltextsuche (indizierte, verschlüsselte Suchdaten), integrierte Spam/Anti‑Abuse‑Filter (auf Metadaten), verschlüsselte Kontakte/Kalender, Custom Domains (bei bezahlten Plänen), Desktop/Mobile/Web‑Clients Open‑Source (teilweise). Infrastruktur & Datenschutz: Server in EU/Jurisdiktion (z. B. Deutschland), strenge Datenschutzpolitiken, regelmäßige Audits. Metadaten: Tutanota minimiert Metadaten, aber grundlegende Header/Envelope‑Daten für Zustellung notwendig; IP‑Logging reduziert und Transparenzberichte vorhanden. Recovery/Backup: eingebauter Recovery‑Mechanismus; ohne Backup/Passwort kann Datenverlust drohen. Einschränkungen: Nicht‑PGP‑basiertes eigenes Verschlüsselungsformat kann Interoperabilität behindern; verschlüsselte Suche ist ein Kompromiss zwischen Funktionalität und Komplexität. Threat‑Model: Schutz gegen Server‑Operatoren und Länderzugriffe innerhalb EU‑Rechtsrahmen; Endgerät‑Komprimisse und schwache Passwörter bleiben Schwachstellen.

 

Vorteile

+ Server in Deutschland

+ Verschlüsselte Nachrichten inklusive Betreffzeilen

+ Post-Quantum-Verschlüsselung

​

Nachteile

- Keine Ende-zu-Ende-Verschlüsselung von E-Mails von externen Personen - Limitierte Alias-Adressen

- Keine anonymen Zahlungsmöglichkeiten

​

Webseite​

ROUTER

Alternative Router‑Firmware lohnt sich, weil sie dir volle Kontrolle über dein Heimnetz gibt: du kannst Firewall‑Regeln, VLANs, QoS, DNS‑Resolver und VPN‑Server/Client genau nach Bedarf konfigurieren, statt dich auf Hersteller‑Defaults zu verlassen. Durch schnellere Sicherheitsupdates und transparenten, auditierbaren Code sinkt das Risiko ungepatchter Schwachstellen. Du kannst Telemetrie deaktivieren, lokale Dienste (z. B. DNS‑Blocker) hosten und Logs selbst verwalten, was die Privatsphäre deutlich verbessert. Außerdem verlängert Community‑Support die Lebensdauer älterer Hardware und ermöglicht moderne Features wie WireGuard oder feingranulare Benutzer‑ und Gerätekontrolle. Nachteilig ist der höhere Konfigurationsaufwand und die eingeschränkte Hardware‑Kompatibilität — wer aber mehr Sicherheit, Privatsphäre und Flexibilität will, profitiert erheblich davon.

​

OpenWrt  [UNSERE EMPFELHUNG]
Vollständig quelloffenes, Linux‑basiertes Router‑OS mit Paket‑Manager für maximale Anpassung und Community‑Support.

​

Technische, detaillierte Beschreibung
Architektur: OpenWrt läuft als Embedded‑Linux mit konfigurierbarem Kernel, init‑System und einer opkg‑Paketverwaltung. Netzwerk‑Stack nutzt standardmäßige Linux‑Netfilter/iptables‑oder nftables‑Kernelmodule, dnsmasq/odhcpd für DHCP/DNS, and uHTTPd/NGINX for web UI (LuCI). Routing/FW‑Funktionen: VLANs, multiple WANs, policy‑based routing, QoS (sqm‑qdisc, fq_codel), OpenVPN/WireGuard support, full IPv6 support (RA, DHCPv6), dynamic routing (BIRD/FRRouting). Storage & Config: Konfiguration via UCI or CLI, persistent overlay filesystem; images can be built with ImageBuilder or SDK; supports external storage (USB) for logs/caching. Security: regular community updates, package audits; supports TLS for LuCI, SSH hardened; per‑package signing depends on build. Extensibility: thousands of community packages (ad‑blockers, Pi‑hole, intrusion detection like Snort/Suricata, captive portals). Performance: optimized for consumer/SMB hardware; CPU/flash/RAM limits on low‑end devices constrain deep packet inspection or heavy IDS. Deployment: flashing required, risk of bricking if mismatched firmware; device support matrix maintained. Management: supports autoupdate scripts, remote management via VPN, and telemetry opt‑out. Threat‑Model: reduces vendor backdoors, increases control; security depends on timely updates and secure configuration. Use‑cases: custom home routers, branch offices, mesh networks (batman‑adv), IoT segmentation.

​

Vorteile

+ Vollständig Open‑Source

+ Paket‑Manager & Anpassbar

+ Breite Hardware‑Unterstützung


Nachteile

- Flashing‑Risiko

- Wartungsaufwand

- Performance‑Limits auf schwacher HW

​

Webseite

​​

​

OPNsense 
Föderierte, auf FreeBSD basierende Firewall/UTM‑Distribution mit Web‑GUI, Fokus auf Enterprise‑Features, IDS/IPS und hohe Auditierbarkeit.

​

Technische, detaillierte Beschreibung
OPNsense basiert auf FreeBSD, nutzt PF (Packet Filter) als Kern‑Firewall, CARP für High‑Availability, OpenVPN/IPsec/WireGuard (via plugins) für VPN, und HardenedBSD/LibreSSL‑Komponenten. Management: umfangreiche Web‑GUI mit Role‑Based‑Access, configuration rollback, scheduled backups and central logging; paketbasierte Plugins für Suricata/Zeek, proxy (Squid), captive portal, HAProxy. Routing/Funktionen: advanced policy‑based routing, multi‑WAN with failover/load‑balancing, dynamic routing via FRR/BIRD plugin, detailed traffic shaping. Security: integrated IDS/IPS (Suricata), GeoIP blocking, two‑factor admin login, frequent security updates and commercial support options. Hardware/Performance: designed for x86 hardware (appliances/VMs) enabling high throughput, hardware offload (AES‑NI, Intel QuickAssist), and enterprise SSDs for logging; scales better than embedded router OS for IDS/UTM workloads. Extensibility & Auditing: open core with many components open‑source, professional support and long‑term update channels; configuration export/import and REST API available. Deployment: common in SMBs and enterprises as edge firewall, perimeter router, VPN concentrator; requires x86 hardware or appliance image. Threat‑Model: protects network perimeter with layered controls; admin misconfiguration remains major risk. Compliance: useful for environments needing logging, audits, and granular policy enforcement.

 

Vorteile

+ Enterprise‑Features & HA

+ IDS/IPS & Proxy‑Plugins

+ Scalable on x86

​

Nachteile

- Hardware‑requirements (x86)

- Komplexer als Consumer‑OS

- Lizenz/Plugin‑Heterogenität

​

Webseite​

LINUX

Es bietet Kontrolle, Transparenz und Anpassbarkeit — kein verstecktes Telemetrieverhalten, auditierbarer Code und feingranulare Systemkonfiguration. Regelmäßige Updates, große Community und Paketmanager erhöhen Sicherheit und Zuverlässigkeit. Für Server, Embedded und Workstations liefert es Stabilität, geringe Ressourcenanforderungen und starke Automatisierungs‑Tools. Insgesamt ideal für Nutzer, die Privatsphäre, Flexibilität und langfristige Wartbarkeit wollen.

​

Pop!_OS  [UNSERE EMPFELHUNG]
Desktop‑orientierte Ubuntu‑Abwandlung von System76 mit Schwerpunkt auf Benutzerfreundlichkeit, Hardware‑Integration (System76‑Geräte) und optimierten Workflows für Entwickler und Kreative.

​

Technische, detaillierte Beschreibung
Debian/Ubuntu‑Basin (Ubuntu LTS‑Kernel/Packages), APT/DPKG, eigenes Pop!_OS‑Repository für Kernel/Treiber‑Backports. Desktop: GNOME‑Fork/Custom‑GNOME mit eigenen UI‑Tweaks, tiling window‑Mode, und systemd‑integration. Kernel & Hardware: angepasste Kernel‑Builds mit NVIDIA‑Support (proprietäre Treiber als Option) und automatischem GPU‑Switching; Firmware‑/EC‑Updates integriert für System76‑Hardware. Privacy/Security: standardmäßige Ubuntu‑Security‑Updates, full‑disk encryption (LUKS) bei Installer, Secure Boot‑Support; keine spezielle compartmentalization wie Qubes. Dev/Power‑User: NVIDIA/AMD GPU workflows, CUDA support, Flatpak/Snap optional, power‑profilesctl für battery/perf tuning. Deployment: Live‑USB, installer GUI, OEM images for System76. Threat‑Model: geeignet für general desktop use; relies on upstream Ubuntu security model and closed‑source driver trust if used.

​

Vorteile

+ Gute Hardware‑Integration

+ Entwicklertools & Tiling Mode

+ Einfaches Setup


Nachteile

- Proprietäre Treiber optional

- Weniger auf Härtung fokussiert

- Ubuntu‑abhängigkeiten

​

Webseite

​​

​

Linux Mint
Einsteigerfreundliche, stabile Ubuntu‑basiere Desktop‑Distribution mit Cinnamon‑Desktop, konservativen Updates und Fokus auf Komfort und Kompatibilität.

​

Technische, detaillierte Beschreibung
Ubuntu LTS Basis, APT/DPKG, eigene Mint‑Repos für Cinnamon‑Extras und Desktop‑Anpassungen. Desktop: Cinnamon (GTK), MATE/Xfce Varianten; traditionelle Desktop‑Metaphern, starke Menüs, Update‑Manager mit fein steuerbaren Update‑Ebenen. Multimedia/Codecs: Standardmäßig proprietäre Codecs/Flash optional vorinstallierbar für out‑of‑the‑box Medien‑Support. Installation & Tools: grafischer Installer (Ubiquity/Calamares Varianten), Timeshift‑Integration für System‑Snapshots, GUI‑Netzwerk/Driver Manager. Security: Standard Ubuntu Security Stack, LUKS‑FDE optional at install; konservative Update‑Policy reduziert regressionsrisiko but may delay latest security fixes. Zielgruppe: Anfänger/Umsteiger von Windows, Nutzer die stabile Desktop mit minimaler Konfiguration suchen. Threat‑Model: usability‑first; not specialised for high‑security threat models.

 

Vorteile

+ Sehr einsteigerfreundlich

+ Cinnamon Desktop UX

+ Timeshift‑Snapshots

​

Nachteile

- Weniger cutting‑edge

- Proprietäre‑Optionen standardmäßig möglich

- Nicht für hohe Anonymitätsanforderungen

​

Webseite​

​

​

Whonix
Privacy‑by‑design Distribution, isoliert Internet‑zugriff über Tor durch separierte Gateway/Workstation VM‑Architektur zur minimierte Leak‑Risiken.

​

Technische, detaillierte Beschreibung
Zwei‑VM‑Modell: Whonix‑Gateway (Tor‑Gateway) und Whonix‑Workstation (isoliertes Desktop). Gateway leitet sämtlichen Traffic der Workstation ausschließlich über Tor; Workstation hat keine direkte Netzwerkzugriffs­möglichkeiten. Virtualisierung: empfohlen VirtualBox/KVM‑QEMU; Images basieren auf Debian. Routing/Leak‑Prevention: strikt konfiguriertes Netzwerk‑Stack, DNS und DNSSEC über Tor, firewall/iptables Regelsatz zur Verhinderung von Direct‑Connections; metadata‑minimizing defaults (uBlock, Tor Browser prepared). Persistence/Updates: Workstation persistent; Gateway/Workstation Updates via apt/repo; caution with templates and snapshot rollbacks (can harm anonymity). Threat‑Model: schützt gegen IP‑Leaking apps and misconfigured network setups, but vulnerable to OS‑level compromises, misused VMs (host leaks), and advanced fingerprinting if user behavior leaks identity. Usability: higher complexity vs standard desktop; Tor latency impacts UX; not intended for general desktop performance.

 

Vorteile

+ Tor‑forced isolation

+ VM‑based leak prevention

+ Debian‑stability

​

Nachteile

- Performance & latency

- Complex setup & VM‑reliance

- Host‑compromise risk

​

Webseite

​

​

Tails
Amnesic Live‑System für maximale Anonymität: bootfähig von USB, alle Verbindungen über Tor, keine persistenten Spuren standardmäßig.

​

Technische, detaillierte Beschreibung
Boot & Volatility: Live‑OS (Debian‑basiert), bootbar von USB/DVD; amnesisch konzipiert — RAM wird beim Herunterfahren gelöscht, sofern kein persistentes Volume aktiviert ist. Netzwerk: sämtlicher Netzwerkverkehr wird über Tor geleitet; enthält Tor Browser mit sicheren Voreinstellungen; unterstützt Bridges und pluggable transports für zensierte Umgebungen. Persistenz: optionale, verschlüsselte Persistenzpartition für vom Benutzer gewählte Daten (GPG‑Schlüssel, persistente Browser‑Lesezeichen) mit starker Verschlüsselung. Forensik & Privatsphäre: minimale vorinstallierte Tools, Maßnahmen zur Systemuhren‑Härtung, Optionen zum Spoofing der MAC‑Adresse, kein Swap standardmäßig, Abschwächungen gegen Hardware‑Identifier. Updates & Verifikation: Images sind signiert; Signaturprüfung vor Nutzung empfohlen. Einschränkungen: nicht ideal als dauerhafter Alltagsarbeitsplatz; manche Hardware startet eventuell nicht; Peripherie‑Fingerprinting und Firmware‑Lecks bleiben Risiken. Threat‑Model: starke Abwehr gegen lokale forensische Artefakte und Netzüberwachung; verwundbar gegenüber kompromittierten Endpunkten, Firmware‑Kompromittierungen und Anwenderfehlern.

 

Vorteile

+ Amnesisch & Tor‑only Traffic

+ Einfaches USB‑Boot & verifizierbare Images

+ Gut für sensible, transiente Nutzung

​

Nachteile

- Nicht als tägliche Arbeitsstation geeignet

- Hardware/Driver‑Einschränkungen

- Usability‑ und Performance‑Tradeoffs

​

Webseite

​

​​

Qubes OS
Security‑by‑isolation Desktop: Xen‑basierte Kompartimentierung mit per‑VM Security Domains (AppVMs, TemplateVMs, NetVMs) für starke Isolation zwischen Aufgaben.

​

Technische, detaillierte Beschreibung
Hypervisor & Isolation: Xen‑Hypervisor trennt Domains; minimales dom0 (Admin‑Domain) läuft mit GUI‑Compositor und Gerätetreibern, aber ohne direkte Netzwerkverbindung. Qubes verwendet TemplateVMs als unveränderliche Basisimages und AppVMs als nutzerspezifische, disposable Instanzen; NetVM/ProxyVM‑Modell isoliert den Netzwerkstack (z. B. sys‑net, sys‑firewall). Sichere Interaktion: Copy/Paste und Dateitransfers werden durch qrexec‑Policies vermittelt. USB‑Geräte werden über eine dedizierte USBVM gehandhabt, um Angriffsfläche zu reduzieren. Krypto & Schlüsselverwaltung: Integration mit Qubes Vault für Secret‑Handling; optionale Nutzung von Hardware‑Tokens (z. B. YubiKey) über USBVM‑Passthrough mit Richtlinien. Updates & Wartung: Template‑Updates propagieren zu AppVMs; Snapshot‑ und Rollback‑Workflows verfügbar. Threat‑Model: minimiert laterale Bewegung durch Isolierung; effektiv gegen Browser‑ oder Attachment‑Kompromittierungen. Komplexität & Hardware: benötigt VT‑x/VT‑d, IOMMU und kompatible Hardware; GPU‑Passthrough und Suspend/Resume können komplex sein. Usability & Performance: steilere Lernkurve; Virtualisierungs‑Overhead, aber auf modernen CPUs mit ausreichend RAM gut handhabbar. Auditing/Community: aktive, sicherheitsfokussierte Community und dokumentierte Best Practices.

 

Vorteile

+ Starke Kompartimentierung

+ Hardware‑level Isolation (Xen)

+ Feingranulare Richtlinien

​

Nachteile

- Hohe Hardwareanforderungen

- Steile Lernkurve

- Verwaltungsaufwand

​

Webseite

​

​

SecureBlue
Härtungsorientiertes Desktop‑OS: Linux‑Derivat mit Fokus auf Kernel‑Härtung, Mandatory Access Control und minimiertem Userland.

​

Technische, detaillierte Beschreibung
Basiert auf einer stabilen Distribution (z. B. Debian/Arch‑Hardened Fork) mit Fokus auf Kernel‑Härtung (Grsecurity/PaX‑Patches oder lizenzkompatible Hardening‑Maßnahmen), Mandatory Access Control (AppArmor/SELinux aktiv), reduziertem Userland, signierten Paketen und reproduzierbaren Builds. Netzwerk: strikte Firewall‑Voreinstellungen, verpflichtende Proxy/VPN‑Routen für ausgehenden Verkehr, gehärtete TLS‑Stacks und optionale Sandboxen (bubblewrap, firejail). Authentifizierung & Secrets: Integration mit Hardware‑Tokens, TPM/secure‑boot Attestation, optional FIPS‑konforme Krypto‑Bibliotheken. Update‑Modell: signierte, atomare Updates, reproduzierbare Images und sicherheitsorientierte Backports. Einsatzfälle: sichere Arbeitsstationen für hochsensible Umgebungen. Threat‑Model: schützt gegen OS‑level Exploits durch mehrere Mitigation‑Schichten; erfordert dennoch sichere Hardware/Firmware und diszipliniertes Admin‑Verhalten. Einschränkungen: mögliche Kompatibilitätsprobleme mit proprietären Treibern, erhöhter Wartungsaufwand und mögliche Lizenzbeschränkungen für bestimmte Kernel‑Patches.

 

Vorteile

+ Kernel‑ und Userland‑Härtung

+ MAC & Sandboxing durchgesetzt

+ Reproduzierbare, signierte Updates

​

Nachteile

- Hardware/Driver‑Kompatibilität

- Wartungsaufwand & Komplexität

- Mögliche Lizenzrestriktionen

​

Webseite

Städtische Fahrradparkplätze

JETZT IM DEATIL UND BEQUEM

PRIVACY BERATUNG

SMARTPHONE

Ein privacy‑fokussiertes Smartphone‑OS lohnt sich allgemein, weil es die Kontrolle über persönliche Daten erhöht und die Angriffsfläche reduziert. Solche Systeme bieten härtere Sicherheits‑Defaults, feinere Berechtigungssteuerung, schnellere Sicherheitsupdates und Schutzmechanismen (Sandbox‑Härtungen, Verified Boot, eingeschränkte Hintergrund‑Zugriffe). Das führt zu weniger Datensammlung durch Apps, weniger Risiko bei Exploits und besserer Integrität sensibler Informationen (Kamera, Mikrofon, Standort, Anmeldedaten). Für alle, die Wert auf Datenschutz, Sicherheit und langfristige Geräte‑Integrität legen, macht ein gehärtetes, datensparsames OS das Smartphone‑Nutzungsverhalten deutlich sicherer — mit der Voraussetzung, dass passende Hardware unterstützt wird und man bereit ist, etwas Konfiguration/Umgewöhnung in Kauf zu nehmen.
 

GrapheneOS  [UNSERE EMPFELHUNG]
Security‑ und Privacy‑fokussiertes Android‑Fork für Pixel‑Geräte: starke Sandbox‑Härtungen und restriktive Sicherheits‑Defaults.

​

Technische, detaillierte Beschreibung
Basis & Kompatibilität: Android‑Fork, entwickelt primär für Google Pixel‑Hardware zur Nutzung von deren Sicherheits‑Features (Titan M, verified boot). Härtungen: umfangreiche Laufzeit‑ und Kernel‑Mitigations (Speichersicherheit, Hardened malloc, seccomp‑Filter), verstärkte App‑Sandboxing‑Verbesserungen und restriktive SELinux‑Policies. Privacy & Permissions: fein granulare Berechtigungssteuerung, gestaffelte Network‑permission controls, optionale Sandboxed Google Services (via alternative Implementierungen) nicht standardmäßig installiert. Updates & Verification: regelmäßige Sicherheitsupdates; Builds sind offen und reproduzierbar; unterstützt Verified Boot für Integritätsprüfung. App‑Kompatibilität: Fokus auf F‑Droid/privatsphärebewusste Apps; Play‑Store‑Kompatibilität möglich über getrennte sandboxes (wenn Nutzer explizit einrichtet). Threat‑Model: schützt vor App‑Exploits, Privilege‑Escalation und vielen lokalen Angriffsvektoren; bleibt abhängig von Hardware‑Firmware und Supply‑chain‑Risiken.

​

Vorteile

  • Starke OS‑Härtungen

  • Fokus auf minimalen Angriffs‑Tiefgang

  • Regelmäßige Sicherheitsupdates


Nachteile

  • Nur Pixel‑unterstützt (offizielle Builds)

  • Eingeschränkte out‑of‑the‑box App‑Kompatibilität

  • Erfordert technisch versierte Nutzer für Advanced‑Setups

​

Webseite

​​

​

CalyxOS
Privacy‑minded Android‑Distribution mit Fokus auf Benutzerfreundlichkeit: mehr Datenschutz als Stock Android bei guter App‑Kompatibilität.

​

Technische, detaillierte Beschreibung
Basis & Kompatibilität: Android‑Fork, unterstützt mehrere Geräte (Pixel, ausgewählte andere Modelle). Bietet einfache Einrichtung und Nutzerfreundlichkeit. Privacy Features: integriert Privacy Guard‑ähnliche Berechtigungssteuerungen, systemweite Firewall (per App), Network‑permission management und optionale Fused Location Service‑Kontrolle. Google‑Integration: ermöglicht optional prüfbare, privat isolierte MicroG/Google Services für App‑Kompatibilität; Nutzer entscheiden, ob und wie sie Dienste nutzen. Updates & Sicherheit: regelmäßige Sicherheitsupdates; Builds offen dokumentiert; nutzt Verified Boot. App‑Ökosystem: gute Kompatibilität zu Play‑Services‑abhängigen Apps dank MicroG und Sandboxing. Threat‑Model: verbessert Schutz vor Tracking und übermäßigen Berechtigungen, aber weniger aggressiv gehärtet als GrapheneOS; abhängig von Hardware‑Firmware.

 

Vorteile

  • Gutes Gleichgewicht Privatsphäre/Kompatibilität

  • Benutzerfreundliche Einrichtung

  • Unterstützt MicroG für App‑Kompatibilität
     

Nachteile

  • Weniger tiefgehende Härtungen als GrapheneOS

  • Potenzielle Kompromisse durch MicroG/Google‑Komponenten

  • Abhängigkeit von Geräte‑Support

​

Webseite​

​

​

Sailfish OS
Linux‑basiertes, unabhängiges Mobile OS mit Fokus auf Datenschutz, Offenheit und alternativer UX; unterstützt Android‑Apps via Kompatibilitätsschicht.

​

Technische, detaillierte Beschreibung
Kernel & Stack: proprietär‑freundlicher, aber offen entwickelter Linux‑Stack mit eigenem Silica‑UI‑Framework; basiert auf Linux‑Kernel und Mer‑Projekt‑Komponenten. App‑Modell: Native Qt/QML‑Apps plus Android‑App‑Kompatibilitätsschicht (Alien Dalvik bzw. vergleichbare Layer) für breitere App‑Verfügbarkeit. Privacy & Kontrolle: granularere Kontrolle über Berechtigungen, integrierte Datenschutzoptionen; offenere Systemarchitektur erlaubt tiefere Anpassungen durch Entwickler. Geräte & Support: teils limited hardware support; kommerzielle Partner (z. B. Jolla, bestimmte OEMs) bieten Images/Devices; Community‑Ports existieren. Updates & Entwicklung: aktiv von kleineren Teams gepflegt; kommerzielle und Community‑Pakete; weniger frequent security updates als große Android‑Forks, abhängig vom Maintainer. Threat‑Model: besser gegen Datensammel‑Profiling im Vergleich zu Stock Android; Sicherheit hängt stark von Vendor‑Support und Update‑Rhythmus.

 

Vorteile

  • Unabhängiges, offenes Mobile‑OS

  • Native Apps + Android‑Kompatibilität

  • Starke Kontrolle für Entwickler/Power‑User

​

Nachteile

  • Begrenzte Geräteunterstützung

  • Kleineres Ökosystem und Update‑Rhythmus

  • Mögliche Kompatibilitätslücken bei Apps

​

Webseite

​

​

PureOS
Privacy‑first GNU/Linux‑basierendes OS für mobile und Desktop (von Purism): freies Software‑Primat, fokusiert auf Datenschutz und sichere Defaults.

​

Technische, detaillierte BeschreibungBasis & Philosophie: Debian‑basiertes, von Free‑Software‑Prinzipien geleitetes OS; Standard‑Repository bevorzugt freie Software; entwickelt von Purism (Librem Phone/Librem 5). Security & Privacy: standardmäßig freie Software, Datenschutz‑fokussierte Apps (Privacy Browser, freien Messaging‑Clients), eingeschränkte Telemetrie. Unterstützt Hardware‑Sicherheitsfeatures auf Librem‑Geräten (HW‑Kill‑Switches für Kamera/Mikrofon, separate Baseband‑Kontrollen). Mobile Implementierung: auf Librem 5 optimiert — dedizierte Hardware, Linux‑Phone‑Stack mit Phosh/Phoc UI. Android‑App‑Kompatibilität begrenzt (optional über Anbox oder Containerlösungen). Updates & Reproduzierbarkeit: offener Update‑Prozess; Sicherheitspatches abhängig von Community und Purism. Threat‑Model: reduziert proprietäre Firmware/closed‑source‑Angriffsflächen; jedoch Baseband, Bootloader und Hardware‑Firmware bleiben kritische Risiken.

 

Vorteile

  • Freie‑Software‑Philosophie & starke Privatsphäre‑Defaults

  • Hardware‑Features (Librem) für physische Kontrolle

  • Offener Stack für Audits

​

Nachteile

  • Begrenzte App‑Kompatibilität (kein Android‑Ökosystem nativ)

  • Hardware primär an Librem‑Geräte gebunden

  • Performance/Kompatibilitätskompromisse vs. Mainstream Phones

​

Webseite

​

​

/e/OS (Murena)
Privacy‑orientiertes Android‑Fork mit Fokus auf einfachen Ersatz für Google‑Dienste und Nutzerfreundlichkeit; kommerzielles Angebot unter Marke Murena.

​

Technische, detaillierte Beschreibung
Basis & Ziele: Android‑Fork mit Ziel, Google‑abhängige Komponenten zu ersetzen; bietet eigene Cloud‑Services (E‑Mail, Drive, Kalender) als privacy‑freundliche Alternative. Google‑Ersetzung: integriert MicroG‑ähnliche Komponenten und zusätzliche Services, um Funktionalität ohne Google‑Account zu ermöglichen; vorinstallierte Privacy‑Apps und Launcher. Geräte & Zugang: unterstützt zahlreiche Geräte via Community‑Builds und offizielle Images; kommerzieller Service Murena bietet vorkonfigurierte Geräte und Cloud‑Accounts. Updates & Maintenance: regelmäßige Builds und Sicherheitsupdates abhängig von Community und Murena‑Team; OTA‑Support für unterstützte Geräte. App‑Kompatibilität: hohe Kompatibilität zu Android‑Apps dank MicroG‑Implementationen; Nutzer können Auswahl treffen zwischen F‑Droid, Aurora Store oder optionalem Play‑Store‑Zugriff. Threat‑Model: reduziert Tracking durch Google‑Backend, verbessert Datenschutz für durchschnittliche Nutzer; weniger aggressive Härtungen als GrapheneOS.

 

Vorteile

  • Google‑freie Nutzererfahrung mit bekannten Apps

  • Einsteigerfreundlich, kommerzieller Support verfügbar

  • Gute App‑Kompatibilität dank MicroG

​

Nachteile

  • Weniger tiefgehende Härtungen als spezialisierte Builds

  • Teilweise Abhängigkeit von MicroG‑Kompatibilität

  • Datenschutz hängt von Murena‑Service‑Modellen und Community‑Support ab

​

Webseite​​

SOCIAL MEDIA

Dezentrale/Protokoll‑basierte soziale Medien (z. B. Nostr) sind sinnvoll, weil sie Kontrolle, Ausfallsicherheit und Zensurresistenz zurück an Nutzer geben. Statt an einen einzelnen Betreiber gebunden zu sein, besitzt du deine Identität (z. B. Schlüssel‑pair) und kannst Inhalte über verschiedene Speicher‑/Relay‑Anbieter veröffentlichen und portieren. Das reduziert zentrale Macht über Moderation, Datenzugriff und Account‑Sperren und macht es schwieriger, ganze Communities offline zu nehmen. Leichtgewichtige Protokolle fördern Innovation und Interoperabilität zwischen Clients. Einschränkungen sind fehlende standardisierte Moderation, Relay‑abhängige Verfügbarkeit und größere Verantwortung für Schlüsselverwaltung — trotzdem bieten diese Systeme mehr Kontrolle über Daten, bessere Portabilität und höheren Widerstand gegen Zensur, was sie für Nutzer attraktiv macht, die Unabhängigkeit und Datenschutz priorisieren.

​

Nostr  [UNSERE EMPFELHUNG]
Dezentralisiertes, einfaches Protokoll für federated‑freie soziale Netzwerke: kryptographisch signierte Ereignisse über beliebige Relays.

​

Technische, detaillierte Beschreibung
Protokoll‑Level statt vollständige Plattform — Clients erzeugen signierte Events (JSON) mit Schlüssel‑pair; Events werden an beliebige Relays (Datenspeicher/Weiterleiter) gesendet und von dort abgerufen. Keine zentrale Identitätsdatenbank; Identität = Public Key. Kommunikationsmodell: Peers (Clients) veröffentlichen/abonnieren Events bei Relays; Relays sind beliebig, unabhängig und können beliebige Filter/Moderationsregeln haben. Federation findet nicht auf Protokollebene statt — Relays legen Speicherung und Verbreitung fest. Privacy & Security: Kryptographische Signaturen gewährleisten Authentizität; Privacy hängt von Relay‑Eigenschaften (Logging, IP‑Retention) ab. Kein eingebautes Spam‑/Moderationsmodell auf Protokollebene; Clients/Relays implementieren lokale Maßnahmen (rate‑limits, moderation lists). Persistenz & Portabilität: Nutzerkontrolle über Schlüssel erleichtert Account‑Portabilität; Datenduplikation über mehrere Relays möglich, aber kein garantierter vollständiger Konsens. Ecosystem & Interoperability: Leichtgewichtig, fördert Experimentierfreude; viele Client‑Implementierungen und Relay‑Projekte. Integration mit Web‑2.0 diensteabhängig. Threat‑Model: Resistenter gegen zentrale Zensur, aber anfällig an Relay‑Level (Zuverlässigkeit, Privacy), Sybil‑Attacken und Spam ohne breitere Moderationsinfrastruktur.

​

Vorteile

  • Einfaches, schlankes Protokoll

  • Identität durch Public Key — portabel

  • Resistent gegen zentrale Zensur


Nachteile

  • Keine standardisierte Moderation/Spam‑Bekämpfung

  • Privacy/Verfügbarkeit abhängig von Relays

  • Fragmentierte Nutzererfahrung zwischen Clients/Relays

​

Webseite

​​

​

Mastodon
Dezentralisiertes, föderiertes soziales Netzwerk (ActivityPub): Instanzen‑basiertes Modell mit Nutzerverwaltung und föderierter Interaktion.

​

Technische, detaillierte Beschreibung
Architektur: Föderiertes Netzwerk von Serverinstanzen (Mastodon‑Instances). Jede Instance hostet Nutzerkonten, moderiert Inhalte und kommuniziert mit anderen Instances via ActivityPub (federation protocol). Account‑Model: Benutzerkonten auf konkreten Domains (user@instance); Föderation ermöglicht Follow/Interaction über Instanzen hinweg, abhängig von Vertrauens‑/Moderationsbeziehungen. Moderation & Governance: Jede Instance kontrolliert lokale Moderationsregeln, Block‑/Filterlisten und kann Federation mit anderen Instanzen einschränken (defederation). Dadurch variable Content‑Policies und Community‑Standards. Privacy & Data: Daten liegen auf der gehosteten Instance; Nutzer können Instanzen mit vertrauenswürdigen Privacy‑Policies wählen oder eigene Instanz hosten. Direct Messages und nichtöffentliche Inhalte sind möglich, Datenschutzniveau variiert. Content Discovery & UX: Chronologische und algorithmische Timelines durch Client‑Implementierungen; unterstützte Formate: Text, Medien, Toots/Boosts (Reposts), Threads. Threat‑Model: Dezentralität verringert Single‑Point‑of‑Failure und Zensur; Risiken: inkonsistente Moderation, Instanz‑Ausfälle, Content‑Moderationsvakuum bei kleinen/unkontrollierten Instanzen.

 

Vorteile

  • Föderation mit lokaler Moderation

  • Benutzerwahl bei Instanz (Trust & Policy)

  • Reicheres Social‑Feature‑Set (Media, DMs, Threads)
     

Nachteile

  • Inkonsequente Moderation über Instanzen

  • Instanz‑Betreiberhaftung/Verfügbarkeit variabel

  • Onboarding/Discovery für neue Nutzer komplexer

​

Webseite​

​

​

Bluesky
Dezentralisiertes soziales Netzwerk mit eigenem Protokoll (AT Protocol / ADX): design für interoperable Identity, modularen Moderation‑Layer und bessere Content‑Discoverability.

​

Technische, detaillierte Beschreibung
Protokoll & Architektur: Baut auf dem AT Protocol (Activity Transmission Protocol / Authenticated Transfer) mit DID‑basierten Identitäten; trennt Transport, moderation und index/search (Community‑konfigurierbare Moderation über Moderation Protocol). Datenhaltung kann verteilt sein (Personal Data Stores/servers), während Indices und Feeds über standardisierte APIs abrufbar sind. Identity & Portability: Identitäten sind portierbar zwischen Hosts mittels DIDs und Account‑Migration; Nutzer behalten Kontrolle über Follower/Blocklists beim Provider‑Wechsel. Moderation & Governance: Modularer Moderation‑Layer erlaubt provider‑seitige und gemeinschaftliche Regeln sowie algorithmische oder chronologische Feeds, mit dem Ziel, klarere Delegation von Moderationsentscheidungen zu ermöglichen. Discovery & UX: Fokus auf performante, kuratierte Feeds und bessere Such/Index‑API; Ziel einer konsistenten Nutzererfahrung unabhängig von Host. Privacy & Safety: Entwurf für klarere Content‑Policies und Migrationspfade; tatsächliche Privacy‑Eigenschaften hängen von Implementierung/Host. Threat‑Model: Adressiert Probleme zentralisierter Plattformen und Inkonsistenzen in Föderation durch standardisierte Moderation und Portabilität; neue Protokollkomponenten können Implementierungsrisiken bergen.

 

Vorteile

  • Protokoll‑fokus mit Identity‑Portabilität

  • Modularer Moderation‑Ansatz

  • Ziel: konsistente UX & bessere Discovery

​

Nachteile

  • Noch in Entwicklung / Adoption ungleichmäßig

  • Moderation/Privacy hängen von Host‑Implementierung

  • Neuartiges Protokoll → Interoperabilitäts‑/Sicherheitsreife offen
     

Webseite​​​

bottom of page