PlainApp Sicherheit im Detail
Wie PlainApp Ihre Daten im lokalen WLAN schützt — mit Belegen aus dem Open-Source-Code.
Warum ist Sicherheit im lokalen Netzwerk wichtig?
Wenn Sie eine App verwenden, um Ihr Android-Handy vom PC-Browser aus zu verwalten, wandern Ihre SMS, Fotos, Kontakte und Dateien über Ihr WLAN. Die meisten Apps senden all das als lesbaren Klartext. Jeder im selben Netzwerk könnte es mitlesen.
Sie denken vielleicht: „Das ist mein WLAN zu Hause, wer sollte da mithören?“ Aber bedenken Sie:
- Öffentliches WLAN — Cafés, Flughäfen, Hotels — jeder in der Nähe kann den Datenverkehr abfangen
- Geteilte Netzwerke — Mitbewohner, Gäste oder kompromittierte IoT-Geräte
- Router-Schwachstellen — Veraltete Firmware mit bekannten Sicherheitslücken
Wenn eine App Ihre SMS als Klartext über HTTP sendet, kann jeder mit einem kostenlosen Tool wie Wireshark sie mitlesen. Das ist keine Theorie — es ist kinderleicht.
Genau das tun die meisten Handy-Verwaltungs-Apps. Öffnen Sie Chrome DevTools (F12 → Netzwerk-Tab) während Sie deren Web-Oberfläche nutzen, und Sie können jeden API-Aufruf als lesbares JSON sehen — SMS-Inhalte, Dateipfade, Kontaktnamen, alles.
Was PlainApp anders macht
PlainApp setzt mehrere Verschlüsselungs- und Authentifizierungsebenen ein. Hier erfahren Sie, was jede Ebene bewirkt — in verständlicher Sprache.
GraphQL API — Nur die Daten abfragen, die Sie brauchen
Die meisten Apps verwenden klassische REST APIs: eine URL pro Ressource, die alles zurückgibt — egal ob Sie es brauchen oder nicht. PlainApp nutzt GraphQL — einen modernen Ansatz, bei dem der Browser genau die benötigten Daten anfordert, nicht mehr.
Warum das wichtig ist:
- Weniger Daten preisgegeben — Wenn Sie nur einen Dateinamen brauchen, wird auch nur dieser übertragen
- Ein einziger Endpunkt — Es gibt nur eine /graphql-URL statt Dutzender, was die Angriffsfläche verringert
- Berechtigungen pro Abfrage — Jede Abfrage prüft ihre eigene Berechtigung (z. B. erfordert das Lesen von SMS die READ_SMS-Berechtigung, auch wenn Sie bereits eingeloggt sind)
Verschlüsselte API-Aufrufe (XChaCha20-Poly1305)
Das ist der größte Unterschied zwischen PlainApp und den meisten Konkurrenten.
Jede API-Anfrage und -Antwort — einschließlich HTTP- und WebSocket-Verkehr — wird mit XChaCha20-Poly1305 verschlüsselt, sowohl im HTTP- als auch im HTTPS-Modus. Dies ist ein moderner AEAD-Verschlüsselungsalgorithmus, der von WireGuard VPN, Cloudflare und Googles Tink-Bibliothek verwendet wird.
Einfach erklärt:
- 1Ihr Browser erstellt eine Anfrage (z.B. „Zeige mir meine SMS")
- 2Er fügt einen Zeitstempel und eine zufällige Nonce zum Schutz vor Replay-Angriffen hinzu
- 3Er verschlüsselt den gesamten Payload mit XChaCha20-Poly1305 in unlesbare Binärdaten
- 4Die verschlüsselten Binärdaten werden direkt über das Netzwerk gesendet — kein Base64, kein JSON, reines Binärformat
- 5Nur Ihr Telefon kann die Daten entschlüsseln und validieren
Selbst wenn jemand den Datenverkehr abfängt, sieht er nur bedeutungslose Binärdaten — kein lesbares JSON.
Zur Verschlüsselung im Detail:
- 256-Bit-Schlüssel (extrem stark)
- 192-Bit-Nonce (verhindert bestimmte Angriffsarten, die andere Verschlüsselungsverfahren betreffen)
- Eingebaute Manipulationserkennung — wenn jemand die Daten während der Übertragung verändert, schlägt die Entschlüsselung fehl
- Android-Seite: betrieben von Google Tink
- Web-Seite: betrieben von @noble/ciphers (eine gut geprüfte JavaScript-Kryptobibliothek)
Digitale Signaturen (Ed25519) — Gerät-zu-Gerät
Wenn zwei PlainApp-Geräte miteinander kommunizieren (z.B. Telefon-zu-Telefon-Chat), reicht Verschlüsselung allein nicht aus — jedes Gerät muss überprüfen, dass die Nachricht wirklich vom anderen Gerät stammt und nicht gefälscht wurde.
Zeitstempel
Das empfangende Gerät überprüft die Signatur mit dem öffentlichen Schlüssel des Absenders und lehnt Anfragen mit einem Zeitstempel von mehr als 5 Minuten ab. Dies verhindert sowohl Fälschung als auch Replay-Angriffe.
Sicheres Geräte-Pairing (ECDH-Schlüsselaustausch)
Wenn sich zwei PlainApp-Geräte miteinander koppeln (z. B. zwei Handys), benötigen sie einen gemeinsamen Verschlüsselungsschlüssel. Aber das Senden eines Schlüssels über das Netzwerk würde den Zweck verfehlen.
PlainApp löst das mit ECDH (Elliptic Curve Diffie-Hellman) Schlüsselaustausch — dieselbe Mathematik, die in TLS, Apples Secure Enclave und WebAuthn zum Einsatz kommt:
- 1Jedes Gerät erzeugt ein Schlüsselpaar (öffentlich + privat)
- 2Sie tauschen nur ihre öffentlichen Schlüssel aus
- 3Jedes Gerät kombiniert seinen eigenen privaten Schlüssel mit dem öffentlichen Schlüssel des anderen
- 4Beide gelangen zum selben gemeinsamen Geheimnis — ohne dass es jemals über das Netzwerk übertragen wird
Verschlüsselte URLs — Dateipfade verbergen
Ein Detail, das die meisten nicht bemerken: Auch URL-Pfade geben Informationen preis.
Beim Herunterladen einer Datei teilt die URL dem Server mit, welche Datei Sie möchten. In vielen Apps sieht die URL so aus:
/fs?path=/sdcard/DCIM/Camera/photo_2024.jpgJeder, der den Datenverkehr mitschneidet (oder in den Browserverlauf schaut), kann genau sehen, auf welche Datei Sie zugegriffen haben und wie Ihre Ordnerstruktur aufgebaut ist.
PlainApp verschlüsselt den Dateipfad in der URL:
/fs?id=AxK9f2mQ7vR3xP8nWz...Der id-Parameter ist der Dateipfad, verschlüsselt mit XChaCha20-Poly1305 unter Verwendung eines zufälligen Schlüssels namens URL Token. Standardmäßig ist dieser Schlüssel permanent und bleibt auch nach einem App-Neustart erhalten, sodass geteilte Links weiterhin funktionieren. Ohne den Schlüssel kann niemand den tatsächlichen Pfad erraten, Ihre Dateien durchsuchen oder Download-URLs erzeugen.
HTTPS mit selbstsignierten Zertifikaten
PlainApp erzeugt ein selbstsigniertes TLS-Zertifikat auf Ihrem Handy. Das schafft einen verschlüsselten HTTPS-Tunnel — dieselbe Technologie, die Banken und Websites verwenden.
Das Zertifikat verwendet:
- ECDSA mit P-256-Kurve (wie große Websites)
- SHA256-Signatur
- Gespeichert im privaten App-Verzeichnis
In Kombination mit der XChaCha20-Anwendungsverschlüsselung erhalten Sie zwei unabhängige Verschlüsselungsebenen. Das Brechen einer Ebene hilft nicht, ohne die andere ebenfalls zu brechen.
Anmeldeschutz
PlainApp begrenzt Anmeldeversuche, um das Erraten von Passwörtern zu verhindern:
- 5 Versuche pro 60 Sekunden pro IP-Adresse
- Danach werden Verbindungen abgelehnt
- Veraltete Ratenbegrenzungs-Einträge werden automatisch bereinigt
HTTP vs. HTTPS: Ein ehrlicher Vergleich
PlainApp bietet sowohl HTTP- als auch HTTPS-Modus an. Hier ist der ehrliche Unterschied:
| HTTP-Modus | HTTPS-Modus | |
|---|---|---|
| Dateipfad-URLs | Verschlüsselt (XChaCha20) | Verschlüsselt (XChaCha20) |
| API-Aufrufe | Verschlüsselt (XChaCha20) | Verschlüsselt (XChaCha20 + TLS) |
| Dateidownloads | Nicht verschlüsselt bei Übertragung | Verschlüsselt durch TLS |
| Für wen geeignet | Einsteiger (keine SSL-Warnung im Browser) | Datenschutzbewusste Nutzer |
Beide Modi verschlüsseln API-Aufrufe mit XChaCha20-Poly1305 — Ihre SMS, Kontakte und anderen Daten sind immer verschlüsselt, unabhängig von HTTP oder HTTPS.
Der HTTP-Modus existiert, weil selbstsignierte Zertifikate eine Browserwarnung auslösen ("Ihre Verbindung ist nicht privat"). Für weniger technikaffine Nutzer ist diese Warnung verwirrend und beunruhigend. HTTP vermeidet diese Hürde.
Allerdings verschlüsselt der HTTP-Modus keine Dateiübertragungen. In geteilten oder öffentlichen Netzwerken sollten Sie immer HTTPS verwenden.
Empfehlung: Verwenden Sie HTTPS, wann immer möglich. Akzeptieren Sie die Browserwarnung zum selbstsignierten Zertifikat — das ist normal und erwartbar bei einer App im lokalen Netzwerk.
Supply-Chain-Sicherheit — Weniger Abhängigkeiten, weniger Risiko
Eine Sicherheitsbedrohung, an die viele Nutzer nicht denken: Supply-Chain-Angriffe. Wenn eine App Hunderte von Drittanbieter-Bibliotheken verwendet, kann jede einzelne davon kompromittiert werden — mit Schadcode, der Daten stiehlt, Kryptowährung schürft oder Hintertüren öffnet.
Das ist besonders gefährlich im JavaScript-Ökosystem. In den letzten Jahren wurden populäre npm-Pakete wie event-stream, ua-parser-js und colors gekapert, um Schadcode in Millionen von Projekten einzuschleusen. Wenn die Web-Oberfläche einer Handy-Verwaltungs-App Hunderte von JS-Paketen einbindet, ist jedes einzelne ein potenzielles Einfallstor.
PlainApp verfolgt einen bewussten Ansatz: So wenige Abhängigkeiten wie möglich verwenden und eigenen Code schreiben, wo es sinnvoll ist.
Android-App (plain-app)
- Kein Dependency-Injection-Framework (kein Hilt, kein Dagger) — einfache Singletons
- Kryptografie wird nur von 3 bewährten Bibliotheken gehandhabt: Google Tink, Bouncy Castle und der integrierten Java Cryptography Extension
- Server läuft auf Ktor (offizielles Kotlin-Framework von JetBrains) — keine obskuren Drittanbieter-Server-Bibliotheken
Web-Oberfläche (plain-desktop)
Nur 28 Laufzeit-Abhängigkeiten — weit weniger als typische Web-Apps. Mehrere Funktionen, die normalerweise npm-Pakete erfordern, sind von Grund auf selbst entwickelt:
| Funktion | Typische App | PlainApp |
|---|---|---|
| Benachrichtigungstöne | howler.js / tone.js | Eigener Web Audio API Synthesizer |
| UUID-Generierung | uuid npm-Paket | Eigene RFC 4122-Implementierung |
| Datei-Uploads | uppy / axios | Eigener Chunked-Upload mit Warteschlange |
| WebRTC-Video | Twilio / Daily.co SDK | Eigener PeerConnection-Code |
| HTTP-Client | axios / ky | Nativer Browser-Fetch |
Die Kryptografie auf der Web-Seite nutzt @noble/ciphers — eine gut geprüfte JavaScript-Kryptobibliothek ohne eigene Abhängigkeiten — statt großer, aufgeblähter Alternativen.
Warum das wichtig ist
Jede Abhängigkeit, die Sie hinzufügen, ist Code, den Sie nicht kontrollieren. Der Ansatz von PlainApp bedeutet:
- Weniger Verstecke für Schadcode
- Kleinere Angriffsfläche
- Leichter zu überprüfen (der gesamte Quellcode ist Open Source)
- Kein Risiko durch aufgegebene oder gekaperte npm-Pakete
Was viele Konkurrenten falsch machen
Es geht hier nicht darum, bestimmte Apps beim Namen zu nennen. Es geht um verbreitete Muster in dieser Kategorie:
| Sicherheitsaspekt | PlainApp | Bei Konkurrenten üblich |
|---|---|---|
| API-Datenverkehr | Verschlüsselt (XChaCha20) in HTTP und HTTPS | Klartext-JSON über HTTP |
| WebSocket-Verkehr | Verschlüsselte Binär-Frames (XChaCha20) | Klartext-JSON oder kein WebSocket |
| Auth-Token-Handling | Als Verschlüsselungsschlüssel verwendet, nie in Headern | In HTTP-Headern gesendet (leicht abgreifbar) |
| Datei-URLs | Verschlüsselte Pfad-IDs | Klartextpfade offen sichtbar |
| Schlüsselaustausch | ECDH (P-256) | Keiner |
| Anfrage-Signierung | Ed25519 (nur Gerät-zu-Gerät) | Keine |
| Replay-Schutz | 30 s + Nonce (Web); 5 Min. + Signatur (Gerät) | Keiner |
| Anmeldeschutz | Rate-Limiting + Zwei-Faktor-Bestätigung | Unbegrenzte Versuche |
| Datenrouting | 100 % lokal, keine Cloud | Teils über Cloud geleitet |
| Abhängigkeiten | Minimale, bewährte Bibliotheken | Hunderte npm-Pakete |
| Quellcode | Open Source (GPL-3.0) | Überwiegend Closed Source |
Der einfachste Weg, eine App zu prüfen: Öffnen Sie Chrome DevTools (F12) → Netzwerk-Tab, während Sie die App verwenden. Wenn Sie API-Antworten als JSON lesen können, hat die App keine Verschlüsselung.
Überzeugen Sie sich selbst
PlainApp ist vollständig Open Source. Jede Aussage in diesem Artikel lässt sich im Code nachprüfen.
github.com/plainhub/plain-app (GPL-3.0)Automatisierte, nachvollziehbare und manipulationsresistente Release-Pipeline
Alle Installationspakete werden automatisch von der GitHub- und F-Droid-Infrastruktur gebaut. Die Builds sind nachvollziehbar, sicher und ohne manuelle Build-Eingriffe. PlainApp gehört zu den wenigen Android-Apps mit verifizierbaren Builds (SLSA) und VirusTotal-geprüften Releases.
Automatisierte Builds auf GitHub und F-Droid
Release-Artefakte werden durch CI-Pipelines statt lokalem manuellen Packaging erzeugt. Jedes Artefakt ist auf Quell-Commits und reproduzierbare Build-Workflows zurückführbar.
SLSA Provenance (Level 3) + VirusTotal-Scan
Jedes Release enthält SLSA-Provenance-Nachweise und VirusTotal-Scan-Ergebnisse. So wird die Lieferkette auditierbar und Nutzer können die Integrität vor der Installation prüfen.
Häufig gestellte Fragen
Ist PlainApp wirklich verschlüsselt, wenn ich den HTTP-Modus verwende?
Ja. Alle API-Aufrufe (SMS, Kontakte, Dateilisten usw.) werden mit XChaCha20-Poly1305 verschlüsselt — sowohl im HTTP- als auch im HTTPS-Modus. Im HTTP-Modus bleiben lediglich Dateidownloads unverschlüsselt. Für vollständigen Schutz verwenden Sie HTTPS.
Warum zeigt mein Browser eine Sicherheitswarnung an?
PlainApp verwendet ein selbstsigniertes TLS-Zertifikat zur Verschlüsselung. Da es nicht von einer öffentlichen Zertifizierungsstelle ausgestellt wurde, zeigt Ihr Browser eine Warnung an. Das ist normal und erwartbar für eine App im lokalen Netzwerk. Klicken Sie auf „Erweitert“ und „Fortfahren“, um fortzusetzen.
Kann jemand im selben WLAN meine Daten sehen?
Mit PlainApp: nein. API-Aufrufe sind mit XChaCha20-Poly1305 verschlüsselt, und im HTTPS-Modus werden auch Dateiübertragungen durch TLS geschützt. Bei den meisten Konkurrenz-Apps hingegen: ja — deren API-Aufrufe werden als Klartext-JSON übertragen.
Wie schneidet PlainApp im Vergleich zu einem VPN ab?
Ein VPN verschlüsselt den Datenverkehr zwischen Ihrem Gerät und dem VPN-Server. PlainApp verschlüsselt den Datenverkehr zwischen Ihrem Handy und dem Browser im lokalen Netzwerk. Sie dienen unterschiedlichen Zwecken — PlainApp sichert die lokale Geräteverwaltung, während ein VPN den Internetverkehr absichert.
Ist der Code wirklich Open Source?
Ja. PlainApp steht unter der GPL-3.0-Lizenz. Der vollständige Quellcode ist verfügbar unter github.com/plainhub/plain-app. Sie können jede Verschlüsselungs-Implementierung einsehen, aus dem Quellcode bauen oder dazu beitragen.
Übernehmen Sie die Kontrolle über Ihr Telefon zurück.
Kein Cloud-Mittelsmann. Keine monatlichen Gebühren. Nur Ihr Telefon und Ihr Browser.