Alle persönlichen Daten — Standorte, Nachrichten, Notfall-Streams, Sensor-Aufzeichnungen — werden ausschließlich gegen den Schlüssel der Familien-Administratoren (Spaceadmins) verschlüsselt. Wir als Betreiber haben keinen technischen Zugriff auf eure Inhalte.
Ausnahme: Wenn ein Spaceadmin uns explizit zur Prüfung Daten freigibt (z.B. bei Verdacht auf Stalking-Vorfall mit Polizei-Anzeige), wird dieser Daten-Pfad transparent dokumentiert und im Audit-Log festgehalten („Re-Wrap“).
Konsequenz: Bei berechtigten Behörden-Anfragen können wir nur sehr wenig herausgeben — wir haben einfach nicht mehr.
Modular: Jede einzelne Funktion lässt sich separat ein- und ausschalten. Wir bauen das System so, dass weniger immer geht — mehr nur dann, wenn ihr’s wollt.
Hinweis zur „Wir“-Form: „Wir“ bedeutet derzeit eigentlich nur ich, Fabian Burth — eine Person, die das Projekt allein in der Freizeit entwickelt. Die Plural-Form ist für späteres Wachstum vorgehalten.
Die App scannt kontinuierlich auf unbekannte Bluetooth-Sender in der Nähe, die möglicherweise Stalking-Geräte (AirTags, Tile o.ä.) sein könnten.
Alle Geräte der Familie leiten ihren Internet-Traffic über eigene, kontrollierte Server. Kein Tracking durch Netzwerk- Betreiber, Schutz in öffentlichen WLANs.
DNS-basierter Schutz gegen Werbung, Tracking, Phishing und Malware-Domains für alle Familien-Geräte. Keine Abfragen an externe DNS-Anbieter (Google, Cloudflare etc.).
Erkennt, wenn Apps auf dem Gerät unverschlüsselte Verbindungen nach außen aufbauen — ein Hinweis auf schlecht konfigurierte oder bösartige Apps.
Nachrichten zwischen Familien-Mitgliedern sind Ende-zu-Ende verschlüsselt. Der Server sieht keine Klartexte — nur verschlüsselte Datenpakete.
Zugang zum Familien-Konto kann über einen 24-Wörter- Wiederherstellungs-Code gesichert werden — ähnlich wie bei Krypto-Wallets, aber für den Familien-Zugang.
Zentrale, selbst-gehostete Verwaltung der Verschlüsselungs- schlüssel. Kein externer Cloud-Dienst hält eure Master-Schlüssel.
Wenn ein Vorfall passiert ist, kann der Spaceadmin gezielt Daten (Standort-Verlauf, Audio-Snapshots) für Behörden oder Anwälte aufbereiten — transparenter Prozess mit Audit-Log.
Jedes Familien-Mitglied hat ein eigenes Konto mit konfigurierbaren Rechten. Rollen: Spaceadmin (volle Kontrolle), Mitglied, Kind (eingeschränkter Zugang).
Welches Familien-Mitglied darf was sehen und tun — Standort, Alarm-Trigger, Chat-Zugang — wird einzeln konfiguriert, nicht pauschal.
Alle wichtigen Aktionen — Alarm-Auslösung, Zugriff auf sensible Daten, Änderungen an Berechtigungen — werden in einem nicht-manipulierbaren Log festgehalten.
Die App bemerkt, wenn eine installierte App auf dem Gerät plötzlich neue Berechtigungen hat oder bestehende sich verändert haben — z.B. nach einem App-Update.
Kommunikation zwischen verschiedenen Familien-Gruppen auf derselben Plattform — z.B. enge Verwandte, die ein eigenes Familien-Konto haben.
Vertrauenspersonen außerhalb der Familie können als „Helfer“ eingebunden werden — mit eng begrenzten Rechten, z.B. nur Alarm-Empfang ohne Standort-Sicht.
Spezieller Betriebsmodus für Banking-Apps: verschlärfte Netzwerk-Filterung, MAC-Randomisierung, erhöhte Isolation. Aktivierbar per Knopfdruck.
Überprüft, ob Apps auf dem Gerät Zertifikats-Pinning korrekt implementieren — ein schwaches oder fehlendes Pinning macht TLS-Verbindungen angreifbar.
Die Web-Verwaltungsoberfläche für Operatoren ist dreifach gesichert: VPN-Zugang + Hardware-Sicherheitsschlüssel + zweiter Tippen-Bestätigung für kritische Aktionen.
Anlage, Konfiguration und Löschung von Familien-Konten (Accounts) inklusive vollständiger Daten-Löschung auf Wunsch — DSGVO-konforme Umsetzung.
Künftig können neue Familien-Gruppen sich selbständig registrieren, ohne manuellen Eingriff durch den Betreiber. Aktuell nur auf Anfrage (Beta).
Mehrere Familien-Gruppen können in einem gemeinsamen Netz-Verbund zusammenarbeiten — z.B. für Hilfs- Organisationen oder Mehr-Generations-Haushalte.
Notfall-Alarm per Knopfdruck, Schnellgeste, PIN-Eingabe, SMS-Stichwort oder Schrütteln des Geräts. Das Signal geht sofort an alle konfigurierten Familien-Mitglieder.
Im Notfall startet die App automatisch einen Audio-/Video-Stream, der von anderen Familien-Mitgliedern in Echtzeit mitgehört werden kann. Snapshots werden verschlüsselt gespeichert.
Die App erkennt über den Beschleunigungssensor, wenn jemand sturz-typische Bewegungen macht, und löst nach kurzer Rückfrage automatisch einen Alarm aus.
Die App sendet regelmäßige Lebenszeichen an den Server. Bleibt ein Signal aus, kann ein Alarm ausgelöst werden — konfigurierbar nach Zeitfenster und Empfänger-Kreis.
Kurze Sprach-Direktnachrichten per Knopfdruck — ähnlich wie Walkie-Talkie, aber über das Familien-Netz. Kein Dauerstream, nur wenn der Knopf gehalten wird.
Wir können technisch nur folgende Daten herausgeben:
Alles andere — Standorte, Chat-Inhalte, Notfall-Streams, Sensor-Aufzeichnungen — ist verschlüsselt und liegt in der Hand des Spaceadmins. Wir können das nicht entschlüsseln.
Weitere Informationen in der Datenschutzerklärung.
Family-Hub-App (Mobile-Foreground-Service) → FastAPI-Backend-Endpoint → ntfy-Push-Channel → alle autorisierten Empfänger-Geräte. Zusätzlicher WebSocket-Kanal für Echtzeit-Status-Updates an online-Mitglieder.
private-Flavor mit SMS-Permission)Alarm-Metadaten (Zeitstempel, Methode, Geräte-ID) werden TLS 1.3 transportverschlüsselt an den Backend-Endpoint übermittelt. Alarm-Inhalte selbst sind server-readable (notwendig für Trigger-Engine). Distress-PIN-Decoy-Logik läuft vollständig auf dem Gerät.
POST /api/distress/trigger — Alarm auslösenPOST /api/distress/{id}/cancel — Fehlalarm rücknehmenWS /api/ws/device — Empfang von Alarm-NotifikationenAlarm-Log-Einträge pseudonymisiert (Pseudo-ID statt Klarname). Server hält Alarm-Zeitstempel und Geräte-Pseudo-ID, kein Klartext-Personenbezug. Distress-PIN-Decoy: Server erhält nur verschlüsselten Alarm-Payload, PIN-Variante ist für Server nicht unterscheidbar.
Notfall-Live-Stream — Technische UmsetzungMobile-Foreground-Service (Special-Use Android 14+) → ValKey-RAM-Ringpuffer (15 Minuten) → Object-Storage pro Family-Bucket → HLS-Manifest (LL-HLS, CMAF) → Caddy-Reverse-Proxy auf family.burth.space/emergency/[stream_id] (Mesh-only). WebSocket-Kanal für Echtzeit-Steuerung.
Stream-Chunks werden gegen Spaceadmin-Pubkey verschlüsselt (X25519 + ChaCha20-Poly1305) bevor sie den Object-Storage erreichen. Backend speichert ausschließlich Ciphertext. Bei explizitem Re-Wrap durch Spaceadmin (Triple-Lock + Audit-Log) kann Material an Operator-Pubkey weitergegeben werden.
POST /api/emergency/streams — Stream startenWS /api/ws/emergency/stream/{id} — Live-EmpfangPOST /api/emergency/streams/{id}/snapshot — Snapshot persistierenDELETE /api/emergency/streams/{id} — Stream beendenStream nur im aktiven Notfall-Modus aktivierbar. Alle Stream-Starts/Stops/Snapshots in Hash-Chain-Audit-Log (Severity critical). ValKey-Ringpuffer: nach 15 Minuten automatisch überschrieben, kein persistentes Logging ohne expliziten Snapshot-Befehl. Betreiber sieht keinen Inhalt.
Android-Beschleunigungssensor (SensorManager, TYPE_ACCELEROMETER) → lokaler ML-Klassifikator auf dem Gerät → Rückfrage-Dialog (5 Sekunden) → bei Nichtreaktion: Distress-Signal-Flow identisch zu manuellem Alarm.
Sensor-Rohdaten verlassen das Gerät nicht. Nur das klassifizierte Sturz-Ereignis (Zeitstempel + Konfidenz-Wert) wird TLS 1.3 an das Backend übermittelt. Kein kontinuierliches Sensor-Streaming an den Server.
POST /api/distress/trigger wie manueller Alarm, mit Feld trigger_method: "fall_detection".On-Device-Processing: keine Roh-Sensordaten im Netz. Rückfrage-Fenster verhindert Fehlalarme. False-Positive-Rate konfigurierbar (Empfindlichkeits-Einstellung). Sensor-Algorithmus läuft vollständig lokal, kein Cloud-ML-Dienst.
Heartbeat-Überwachung — Technische UmsetzungFamily-Hub-App (periodischer Hintergrund-Job, Android WorkManager) → FastAPI-Backend heartbeats-Tabelle → serverseitige Inactivity-Trigger-Engine → ntfy/WebSocket-Alarm an konfigurierte Empfänger.
Heartbeat-Pakete sind server-readable (Klartext nach TLS-Entschlüsselung). Inhalt: Geräte-Pseudo-ID, Zeitstempel, Online-/Offline-Flag, Batterie-Prozent. Kein Standort, keine Bewegungsdaten im Standard-Heartbeat.
POST /api/heartbeats — Lebenszeichen sendenGET /api/devices/{id}/heartbeat-status — letzter Heartbeat-ZeitpunktHeartbeat-Daten in der Postgres-Datenbank mit Row-Level-Security (Account-Isolation): Geräte eines Accounts können nie Heartbeats anderer Accounts lesen. Inactivity-Schwellwert konfigurierbar pro Gerät. Alarm-Empfänger-Kreis separat konfigurierbar von allgemeinen Benachrichtigungen.
Push-to-Talk — Technische UmsetzungFamily-Hub-App (Mikrofon-Stream, nur bei gehaltenem Knopf) → WebRTC-Signaling via FastAPI-WebSocket → direktes Peer-to-Peer-Audio über Mesh-Verbindung (bevorzugt) oder TURN-Relay. Audio-Codecs: Opus.
WebRTC-DTLS 1.3 + SRTP für den Audio-Stream. Signaling-Kanal via TLS 1.3 + mTLS (Geräte-Client-Cert). Keine serverseitige Aufzeichnung ohne explizite Freigabe durch alle Teilnehmer.
WS /api/ws/ptt/signal — WebRTC-Signaling (SDP-Offer/Answer, ICE-Candidates)POST /api/ptt/sessions — PTT-Sitzung startenNur bei gehaltenem Knopf aktiv — kein Dauerstream. Peer-to-Peer via Mesh bevorzugt: kein Audio-Traffic über Backend-Server. Audit-Log-Eintrag bei Session-Start/Stop (Pseudo-IDs). Kein Mitschnitt-Modus ohne Critical-Action-Step-Up durch alle Teilnehmer.
Bluetooth-Tracker-Erkennung — Technische UmsetzungAndroid-Bluetooth-LE-Scanner (kontinuierlich, Hintergrund-Service) → lokale Geräte-Datenbank (bekannte Tracker-Advertising-Patterns) → lokale Bewertungslogik → bei Warnungs-Schwellwert: Push-Benachrichtigung lokal + optional an Familien-Mitglieder.
Scan-Rohdaten (MAC-Adressen, Signal-Stärken) bleiben ausschließlich auf dem Gerät. Nur die Warn-Ereignisse (Zeitstempel, Geräte-Typ-Klassifikation ohne MAC) werden übermittelt — kein Fingerprinting anderer Geräte auf dem Server.
POST /api/bt-scan/warnings — Warn-Ereignis optional an Familien-Mitglieder meldenAUWF (Advertising Unwanted Tracking Framework): kompatibel mit Google/Apple-DULT-Draft-Standard. Erkennungs-Muster halten MAC-Adressen nie länger als 10 Minuten im Geräte-RAM. Privacy-by-Design: kein zentrales Tracker-Reporting-Backend.
Familien-VPN — Technische UmsetzungFamily-Hub-App (embedded VPN-Client via Tailscale-Library, Android VpnService-API) → Headscale-Koordinations-Server (headscale.burth.space, public) → WireGuard-Tunnel zu Exit-Nodes auf eigenen Hetzner-Servern. Subnet-Tags für verschiedene Geräte-Klassen.
WireGuard verwendet Noise Protocol Framework mit X25519-Schlüsseltausch + ChaCha20-Poly1305-Datenverschlüsselung + BLAKE2s-MAC. Geräte-Schlüsselpaare werden im Android-Keystore gespeichert. PFS (Perfect Forward Secrecy) via ephemere Session-Keys.
DNS-Resolver via SafeBrowse-Endpoint (eigener Server, kein Google/Cloudflare). VPN-Traffic-Logs: nur Verbindungs-Metadaten für Sicherheitsdiagnose, 7-Tage-Retention, danach automatisch gelöscht. Subnet-Tags ermöglichen spätere Sichtbarkeits-Segmentierung pro Geräte-Klasse.
VPN-Koordination über Headscale-eigenes Protokoll (größtenteils Standard-Tailscale-Coordination-API). Kein eigenes Backend-Endpoint für den VPN-Core.
SafeBrowse DNS-Filter — Technische UmsetzungDNS-Filter-Stack im Family-Safety-Compose-Stack: eigener DNS-Filter-Server + rekursiver Resolver. Filterlisten: Community-gepflegte Block-Listen für Werbung, Tracking, Phishing, Malware-Domains. Aktivierung über VPN-DNS-Override (alle Familien-Geräte im Mesh nutzen automatisch SafeBrowse als DNS-Resolver).
DNS-over-HTTPS-Endpoint (safebrowse.burth.space) für Companion-Clients vor VPN-Aufbau. Im Mesh selbst: DNS via verschlüsselten WireGuard-Tunnel. Kein Klartext-DNS nach außen.
DNS-Abfragen verbleiben auf eigenen Servern. Keine Weiterleitung an externe Resolver (Google 8.8.8.8, Cloudflare 1.1.1.1 etc.). Rekursiver Resolver löst direkt über Root-Nameserver. DNS-Query-Logs: anonymisiert, 24h-Retention für Diagnose-Zwecke, kein Profiling.
Klartext-Verbindungs-Audit — Technische UmsetzungVPN-Exit-Node (iptables-LOG-Targets für Port 80/non-TLS-Traffic) → Log-Parser im Backend (scapy + iptables-LOG-Analyse) → Aggregation pro App-Paketname (via Android-UID-Mapping) → Warn-Bericht an Familien-Mitglieder.
Audit-Berichte werden gegen Spaceadmin-Pubkey verschlüsselt gespeichert (Plaintext-Audit-Logs: doppelt-encrypted, Spaceadmin-Pubkey + User-Pubkey gemäß Architektur-Vertrag). Betreiber kann Inhalte nicht lesen.
GET /api/audit/plaintext-connections — Bericht abrufen (Spaceadmin-Auth erforderlich)URL-Inhalte werden nicht geloggt (nur Destination-IP + Port + App-Paketname). Kein Deep-Packet-Inspection. Ziel: Transparenz über schlecht konfigurierte Apps, keine Content-Analyse.
Sealed-Sender-Chat — Technische UmsetzungFamily-Hub-App (Chat-Modul) → lokale Verschlüsselung (PyNaCl-äquivalent auf Mobile: libsodium-Flutter-Binding) → FastAPI-Chat-Endpoint → Postgres (nur Ciphertext + Wrap-Map) + Object-Storage für Anhänge → WebSocket-Push an Empfänger.
Ende-zu-Ende via LibsodiumE2EProvider: Curve25519 + XSalsa20-Poly1305 (PyNaCl Box). Conversation-Key (32 Byte random) wird gegen jeden berechtigten Geräte-Pubkey einzeln gewrappt. Server sieht: Ciphertext + Wrap-Map pro Empfänger-Gerät. Klartext-Nachrichten: nie auf dem Server.
POST /api/chat/rooms/{id}/messages — Nachricht senden (Ciphertext)GET /api/chat/rooms/{id}/messages — Nachrichten abrufen (Ciphertext)WS /api/ws/device — Echtzeit-Push bei neuen NachrichtenJede Nachricht trägt Ed25519-Signatur des sendenden Geräts (Integritäts-Schutz gegen Manipulation). Server hält nur Ciphertext — auch bei Datenbank-Compromise kein Klartext-Zugriff. Subpoena-Resistance: Betreiber kann auf Behörden-Anfrage nur Pseudo-IDs + Ciphertext liefern.
Recovery-Codes — Technische UmsetzungFamily-Hub-App (lokale Code-Generierung via CSPRNG) → Zero-Knowledge-Shamir-Secret-Sharing (lokal auf dem Gerät) → FastAPI-Recovery-Endpoint speichert nur Argon2id-Hashes + verschlüsselte Shares. Mindestens 3 aktive Recovery-Methoden Pflicht.
Code-Format: 10 Codes × 20 Base32-Zeichen (130 Bit Entropie pro Code). Hashing: Argon2id (m=65536, t=3, p=4) + Per-User-Salt + KMS-Pepper. Shares: Client-seitig verschlüsselt mit ChaCha20-Poly1305 (Key = HKDF-SHA256(method_value, salt)) vor Upload. Server sieht niemals Klartextcodes.
POST /api/auth/recovery/methods/register — Recovery-Methode anlegenPOST /api/auth/recovery/methods/test — Methode periodisch testenPOST /api/auth/recovery/redeem — Zugangs-WiederherstellungCodes sind Single-Use. Anti-Brute-Force: Rate-Limit 3/h pro E-Mail + Argon2id-Compute-Cost (~100ms). 30-Tage-Pflichttest pro Methode (Sicherheit dass Codes noch funktionieren). 2-of-m Threshold: Angreifer muss mindestens 2 Methoden kompromittieren.
Schlüssel-Verwaltung (KMS) — Technische UmsetzungOpenBao-Instanz (Vault-Fork, Open-Source) als zentrales KMS → 4 logische Slots: Master-Account-Key, Chat-Conversation-Keys, Distress-Stream-Keys, Plaintext-Audit-Keys. Zugriff nur über Backend-Service-Account mit Least-Privilege. Cold-Start: Operator-Privatekey-Entschlüsselung lokal via YubiKey-PRF.
Operator-Privatekey: ChaCha20-Poly1305-Wrap (Key = PRF(YubiKey + Salt)) + Argon2id-Doppel-Layer (m=1 GB, t=10, p=2 — State-Actor-resistent). X25519 für asymmetrische Layer. Server hält nur Ciphertext-Wraps, niemals Klartext-Privatekeys.
YubiKey-gebundene Entschlüsselung: PRF-Extension (FIDO2, WebAuthn-PRF) ist hardware-bound, kein Software-Key-Fallback. Backup-YubiKey mit eigenem Salt. Beide YubiKeys verloren: Threshold-Recovery über Shamir-Splits. Operator-Privatekey ist nur InMemory während aktiver Sitzung, Memory-Wipe bei Logout.
Stalking-Beweis-Paket (Re-Wrap) — Technische UmsetzungWeb-GUI (SvelteKit, Browser-seitig) → WebCrypto + libsodium-WASM (lokaler Decrypt) → Multi-Recipient-Envelope-Re-Encrypt (gegen alle aktiven Operator-Pubkeys) → Upload des Re-Wrap-Pakets an Backend. Operator-Workstation: lokaler Decrypt mit eigenem YubiKey-PRF.
Flow A (Spaceadmin-initiiert): Lokaler Decrypt im Browser (YubiKey-PRF) → Re-Encrypt als Multi-Recipient-Envelope (X25519 + XSalsa20-Poly1305 Box pro Operator-Pubkey). Server sieht niemals Klartext. Streaming-Re-Wrap: 100 MB Snapshot < 60 s auf Mid-Range-Laptop, Memory-Footprint < 200 MB.
POST /api/operator/case/{case_id}/evidence — Re-Wrap-Paket hochladenGET /api/operator/case/{case_id}/evidence — Ciphertext + Wrap-Map abrufen (Operator-Auth)Spaceadmin wählt explizit einzelne Events aus (kein Massen-Export). Ed25519-Signaturen belegen Integrität (Selektions-Lücken werden als Platzhalter gerendert, Anti-Manipulation). Jeder Re-Wrap-Schritt im Hash-Chain-Audit-Log. Operator-Pubkey-Pool mit Lifecycle-Management (Rotation-SLA 90 Tage).
Multi-User + Rollen — Technische UmsetzungPostgres-Datenmodell mit Row-Level-Security (RLS) pro Account → Backend-Tenancy-Context-Manager (setzt SET LOCAL family.tenant_id pro Request) → Rollen-basierte API-Autorisierung: Spaceadmin / Member / Child. Geräte-Provisioning via Bootstrap-Token-Flow.
Geräte-mTLS: Ed25519-Schlüsselpaar bei Provisioning generiert (Android-Keystore Strongbox wenn verfügbar). Cert-Lifetime 12 Monate, Auto-Renew bei 9 Monaten. Caddy validiert Client-Cert pro Request.
GET /api/admin/members — Familien-Mitglieder auflisten (Spaceadmin)POST /api/admin/members — Mitglied einladenPATCH /api/admin/members/{id}/role — Rolle ändern (Critical-Action)RLS-Policy verhindert Familien-übergreifend-Datenlecks auf Datenbankebene (Defense-in-Depth gegen Backend-Fehler). Kind-Rolle: kein Zugriff auf Admin-Funktionen, eingeschränkte Standort-Sichtbarkeit. Spaceadmin-Scope ist Account-scoped — kein Familien-übergreifend-Zugriff möglich.
Granulare Berechtigungen — Technische UmsetzungBerechtigungs-Modell in Postgres (member_permissions-Tabelle mit Consent-Timestamps) → Backend-Middleware prüft Permissions pro API-Request → Web-GUI (Spaceadmin) + Mobile-App (Mitglieder) zur Verwaltung. Jede Änderung erfordert aktiven Consent des betroffenen Mitglieds.
Berechtigungs-Daten sind server-readable (notwendig für Trigger-Engine). Granularität: Standort-Sichtbarkeit (per Mitglied), Alarm-Empfang (per Mitglied), Chat-Zugang (per Raum), Heartbeat-Sichtbarkeit. Consent-Zeitstempel im Audit-Log.
GET /api/permissions — eigene Berechtigungen einsehenPOST /api/permissions/consent — Zustimmung erteilen/widerrufenGET /api/admin/permissions — Übersicht (Spaceadmin)Opt-in-Standard: keine Berechtigung ohne explizite Zustimmung. Widerruf jederzeit möglich. Consent-Widerruf wirkt sofort (kein Batching). Jede Berechtigungsänderung im Audit-Log mit Pseudo-ID des ändernden Mitglieds.
Audit-Log — Technische UmsetzungPostgres audit_log-Tabelle mit BEFORE INSERT-Trigger für Hash-Chain (SHA-256: H(prev_hash || entry_data)) → BEFORE UPDATE/DELETE-Trigger wirft Exception (append-only). Cross-Server-Mirror via rsyslog TCP 6514 als unabhängiger Audit-Anker.
Log-Einträge pseudonymisiert: Geräte-Pseudo-ID statt Klarnamen, Account-UUID statt Familienname. Server-readable (Trigger-Engine benötigt Lesezugriff). Plaintext-Audit-Logs (bei aktiviertem Modus): doppelt-encrypted gegen Spaceadmin-Pubkey + User-Pubkey.
Hash-Chain: Manipulation eines einzelnen Log-Eintrags macht alle nachfolgenden Einträge ungültig (nachweisbar). Append-only via Postgres-Trigger: kein Backend-Fehler kann Einträge überschreiben. Offline-Verifikation: CLI-Tool audit_verify.py prüft Chain-Integrität ohne Server-Zugriff.
Family-Hub-App (Android PackageManager-Abfragen im Hintergrund-Service) → lokaler Snapshot-Vergleich (aktuelle vs. letzte bekannte App-Berechtigungen) → bei Änderung: lokale Warn-Benachrichtigung + optional an Familien-Mitglieder.
Berechtigungs-Snapshots werden lokal auf dem Gerät gespeichert (Android-interner Storage). Nur aggregierte Warn-Ereignisse (App-Paketname + geänderte Permission-Kategorie) werden übermittelt — kein vollständiges App-Profil auf dem Server.
Erkennt: neue Permissions nach App-Update, Permissions die per ADB/Root gesetzt wurden, Sideload-Apps mit unerwarteten Permissions. Keine Cloud-basierte App-Analyse: ausschließlich lokaler Vergleich gegen eigene Snapshot-Datenbank.
Cross-Family-Chat — Technische UmsetzungErweiterung des Sealed-Sender-Chat-Moduls für Familien-übergreifend-Nachrichten → Familien-übergreifend-Pub Key-Exchange-Mechanismus (via Plattform-Operator als Vermittler) → E2E-Verschlüsselung über Account-Grenzen. Feature-Flag: standardmäßig deaktiviert (Phase-2-Opt-In).
Identischer Crypto-Layer wie Sealed-Sender-Chat (Curve25519 + XSalsa20-Poly1305). Conversation-Key wird gegen Empfänger-Pubkeys des anderen Accounts gewrappt. Plattform-Operator vermittelt nur den Pubkey-Austausch — nie den Conversation-Key selbst.
Doppeltes Opt-in erforderlich: beide Accounts müssen Cross-Family-Verbindung aktiv bestätigen (Critical-Action-Step-Up beider Spaceadmins). Verbindung jederzeit trennbar durch einen der Spaceadmins. Audit-Log-Eintrag bei Verbindungsaufbau/-trennung in beiden Accounts.
Helfer-System — Technische UmsetzungHelfer-Einladung (Spaceadmin → E-Mail-Link mit Token) → Helfer-Konto mit eingeschränkter Rollen-Konfiguration → Berechtigungs-Granularität: nur Alarm-Empfang, optional Standort-Sicht (Spaceadmin-konfigurierbar). Helfer-Konto ist account-scoped, kein eigenes Familien-Konto.
Helfer-Gerät erhält eigenes mTLS-Client-Cert (Ed25519, 12 Monate). Chat-Nachrichten an Helfer: selbes E2E-Crypto wie normaler Chat, Helfer-Pubkey wird in Wrap-Map inkludiert.
Helfer sieht nur explizit freigegebene Daten (kein pauschaler Familien-Zugang). Helfer-Konto kann vom Spaceadmin jederzeit widerrufen (Certificate-Revoke + DB-Deactivation). Audit-Log: alle Helfer-Aktionen protokolliert. Helfer-Einladung über Plattform-Operator-Approval (Phase 4).
Banking-Modus — Technische UmsetzungFamily-Hub-App (Betriebsmodus-Umschalter) → verschärfte VPN-Routing-Regel (Banking-Traffic über dediziertes Exit-Node-Subnetz) → MAC-Randomisierung via Android-WifiManager + Network-Capabilities-API → Netzwerk-Isolation für Banking-Apps via Android-App-Network-Policies (VpnService-Split-Tunneling).
Banking-Modus erhöht keinen bestehenden Crypto-Layer, sondern erhöht die Netzwerk-Isolation. TLS-Verbindungen der Banking-Apps laufen vollständig über das eigene VPN (kein Split-Tunneling für Banking-Traffic). MAC-Randomisierung verhindert WLAN-Tracking.
Banking-Traffic-Log: kein Protokoll der besuchten Banking-URLs. Modus-Aktivierung wird lokal geloggt (Zeitstempel), nicht an Server übermittelt. Automatische Deaktivierung nach 30 Minuten Inaktivität (konfigurierbar).
Zertifikats-Pinning-Audit — Technische UmsetzungFamily-Hub-App (Android-Network-Security-Config-Parser + APK-Analyse-Modul) → lokale Prüfung der installierten Apps auf Network-Security-Config (Pinning-Konfiguration) → Klassifikation: starkes Pinning / schwaches Pinning / kein Pinning → Bericht an Nutzer.
Audit-Ergebnisse werden lokal auf dem Gerät gespeichert. Optional: verschlüsselter Upload des Berichts an Familien-Konto (gegen Spaceadmin-Pubkey) für zentrale Übersicht im Web-GUI.
Keine App-Daten (Inhalte, Netzwerk-Traffic) werden analysiert — nur statische APK-Konfiguration. Offline-fähig. Erkennt: fehlendes Pinning, Pinning auf User-CAs (schwach), korrektes SPKI-Pinning mit Backup-Pin.
Triple-Lock-Admin-Zugang — Technische Umsetzung100.64.0.0/10). Externe Zugriffsversuche erhalten 403.JWT-Session-Token (15 Minuten), Refresh-Token in ValKey (24h). Critical-Action-Step-Up: eigener WebAuthn-Cycle pro Aktion mit action-spezifischer Challenge SHA256(action_type || target_id || timestamp || tenant_id). 60 Sekunden Action-Token, nicht wiederverwendbar.
Alle drei Faktoren müssen gleichzeitig kompromittiert sein für erfolgreichen Angriff. Geleakte Credentials ohne Mesh-Zugang sind wertlos. Workstation-Cert-Verlust: Revoke via zweiter Workstation oder KVM-Console + Recovery-Code.
Account-Lebenszyklus — Technische UmsetzungServer-CLI family-bootstrap-token (Account-Anlage, kein REST-API-Endpunkt) → Postgres-Account-Tabelle mit RLS-Policies → DSGVO-Erasure-Flow: kaskadierte Löschung aller Account-Daten (Geräte, Heartbeats, Chat, Distress-Events, Audit-Log, Object-Storage-Bucket) → Soft-Delete mit 30-Tage-Grace-Period.
Art. 17 (Löschrecht): vollständige Datentilgung auf Antrag, keine versteckten Backups nach Grace-Period. Art. 20 (Datenübertragbarkeit): Export aller Account-Daten als JSON/ZIP via Spaceadmin-GUI vor Löschung. Account-Anlage: nur Kontakt-Mail erfasst, kein Profiling.
POST /api/admin/tenants/{id}/suspend — Account suspendieren (Critical-Action)DELETE /api/admin/tenants/{id} — Account löschen (Critical-Action, eigener Account)GET /api/admin/export — DSGVO-DatenexportLöschen löscht wirklich: Postgres-Cascade + Object-Storage-Bucket-Delete + ValKey-Key-Flush + Headscale-User-Delete. Grace-Period: 30 Tage Soft-Delete mit Reaktivierungsmöglichkeit. Nach Ablauf: unumkehrbar.
Selbst-Registrierung — Technische UmsetzungÖffentlicher Registrierungs-Endpoint auf family.burth.space/register → E-Mail-Verifizierung (SMTP via dev-Smarthost) → automatische Account-Anlage + Bootstrap-Token-Generierung → Willkommens-Mail mit App-Download-Link. Aktuell (Beta): manueller Prozess durch Betreiber.
Registrierung erfasst nur Kontakt-Mail + Familien-Name (optional). Kein Profiling. E-Mail-Adresse: Argon2id-gehasht in der Datenbank (kein Klartext). CAPTCHA via Proof-of-Work (kein Google-reCAPTCHA). Rate-Limit: 3 Registrierungen pro IP-Subnetz/24h.
POST /api/public/register — Registrierungs-AnfragePOST /api/public/register/verify — E-Mail-VerifizierungErweiterung der Headscale-Multi-User-ACLs für übergreifende Subnet-Tags → Familien-übergreifend-Routing-Richtlinien (welche Accounts dürfen welche Subnetze sehen) → Plattform-Operator-Approval für Verbund-Anfragen → getrennte ACL-Namespaces pro Familien-Gruppe.
Verbund-Zugang nur per expliziter gegenseitiger Freigabe (beide Spaceadmins + Operator-Approval). Netzwerk-Segmentierung: Familien-Gruppe A sieht nur freigegebene Subnetze von Gruppe B, keinen vollständigen Mesh-Zugang. Verbund trennbar durch einen der Spaceadmins (sofort wirksam via Headscale-ACL-Update).
Konfiguration via Spaceadmin-GUI (Web-GUI, Critical-Action) und Headscale-ACL-Update durch Backend. Kein direktes Familien-zu-Familien-API.