---
title: "ChrisGuard: Warum das Handy nicht der Alarm sein kann"
description: "Ein Sicherheits-Timer muss genau dann handeln, wenn seine Nutzerin oder sein Nutzer es nicht kann. Diese eine Anforderung verlegte die Deadline von ChrisGuard vom iPhone auf einen Server. Danach formte sie das Datenschutzmodell und die Texte in der App neu."
canonical: https://arnekellmann.de/de/blog/chrisguard-das-handy-kann-nicht-der-alarm-sein
published: 2026-10-02
modified: 2026-10-02
lang: de
---
# ChrisGuard: Warum das Handy nicht der Alarm sein kann
ChrisGuard ist ein Sicherheits-Timer fürs iPhone. Vor einem Lauf, einer Wanderung oder einem ersten Date stellst du ein, wie lange es dauern soll. Meldest du dich bis dahin nicht zurück, bekommt dein Notfallkontakt eine SMS. Auf Wunsch enthält sie deinen Standort. Die Idee passt in einen Satz. Der Großteil der Technik steckt in einer Frage, die einfacher klingt: Wo lebt die Deadline?
Dieser Artikel verfolgt diese Frage durch den Code. Die Antwort entschied zuerst die Architektur. Danach entschied sie, was ChrisGuard ehrlich über Datenschutz sagen kann. Zuletzt entschied sie, was die App auf ihrem eigenen Bildschirm zeigen darf.
Dieser zwölfsekündige Film ohne Ton stammt aus der House-Ad-Kampagne und zeigt englischen Text. Er zeigt Illustrationen, keine Aufnahme der App-Oberfläche. Die SMS-Blase zeigt nicht den echten Alarmtext.
## Der erste Entwurf hatte keinen Server
Die erste Version von ChrisGuard arbeitete offline und hatte gar kein Backend. Lief ein Timer ab, bereitete die App mit Apples MessageUI-Framework eine SMS vor. Die Nutzerin tippte dann auf „Senden“. Für den Datenschutz war das ideal. Kein Kontakt, keine Nachricht und kein Standort verließ je das Telefon.
Im entscheidenden Fall versagte es aber. Wer sich nicht zurückmeldet, kann oft auch nichts antippen. Der Akku ist leer. Es gibt kein Netz. Die Person ist verletzt, oder das Handy liegt auf dem Grund eines Sees. iOS ergänzt ein leiseres Problem: Eine pausierte App darf nicht zu einem selbst gewählten Zeitpunkt Code ausführen. Eine lokale Benachrichtigung kann erinnern. Zuverlässig für dich handeln kann sie nicht.
Ein Sicherheits-Timer, der im Ernstfall die Hilfe seiner Nutzer braucht, ist eine Erinnerungs-App. Im November 2025 entfernte ChrisGuard deshalb MessageUI und verlegte die Notfall-SMS auf einen Server.
## Der Server hält die Deadline, das Handy meldet nur
Das Backend läuft auf Cloudflare Workers. Das Handy meldet ihm drei Dinge: Eine Session beginnt, die Nutzerin verlängert sie, die Session endet. Der Server führt die Deadline. Verstreicht sie ohne Ende, schickt der Server die SMS. Der Notfallkontakt braucht weder App noch Konto. Eine normale SMS erreicht ihn.
Aufgeschrieben wirkt diese Aufteilung selbstverständlich. Die erste serverseitige Änderung enthielt trotzdem den Fehler, der zeigt, warum sie es nicht ist. Lief der Timer ab, markierte der Client die Session als beendet und teilte das dem Server mit. Im alten Entwurf war das richtig. Im neuen brach es genau die Nachricht ab, die der Server gleich senden wollte. Ein Code-Review fand ihn, und ein Folge-Commit im selben Pull Request entfernte den Aufruf. Daraus folgte eine Regel für alles Weitere: Sobald der Server die Deadline besitzt, trifft der Client keine Entscheidungen mehr über sie. Das Handy meldet, was die Nutzerin tut. Es entscheidet nicht, was passiert, wenn sie nichts tut.
## Zwei Timer statt eines guten
Auch ein Server kann einen Moment verpassen. ChrisGuard versucht nicht, einen perfekten Timer zu bauen. Es betreibt zwei unabhängige und sorgt dafür, dass beide gefahrlos auslösen dürfen.
Der erste ist ein geplanter Alarm. Jede Nutzerin hat ein Cloudflare Durable Object, einen kleinen Worker mit eigenem Zustand und eigenem Speicher. Er kann einen Alarm stellen, der ihn zu einer bestimmten Zeit weckt. Beginnt eine Session, stellt der Server diesen Alarm auf die Deadline.
Der zweite ist ein Kontrolldurchlauf. Ein geplanter Job läuft in kurzen Abständen und sucht Sessions, deren Deadline vorbei ist und die kein Alarm behandelte. Die Commit-Nachricht nennt ihn ein Sicherheitsnetz, und das ist das ehrliche Wort dafür. Er existiert für den Fall, dass der erste Mechanismus ohne Fehlermeldung versagt.
Zwei Mechanismen, die beide auslösen können, schaffen ein neues Risiko: zwei SMS für einen Notfall, oder schlimmer, zwei halbe Versuche, von denen jeder glaubt, der andere sende. ChrisGuard verhindert das in der Datenbank. Bevor etwas rausgeht, muss ein Mechanismus die Session für den Versand beanspruchen, und nur ein Anspruch kann gelingen. Wer zuerst kommt, sendet. Der andere findet nichts mehr zu tun.
Der Versand selbst wiederholt, aber gezielt. Nach einem vorübergehenden Fehler des SMS-Anbieters versucht der Server es eine begrenzte Zahl von Malen erneut. Ein dauerhafter Fehler, etwa eine ungültige Nummer, scheitert sofort, denn ein neuer Versuch würde nur hinauszögern, dass der Fehler sichtbar wird. Der Server protokolliert das Endergebnis jedes Versands, und der Anbieter kann zurückmelden, ob eine Nachricht ankam.
Unfehlbar wird das System dadurch nicht. Es verringert aber die Abhängigkeit von einem einzelnen Mechanismus, und es tauscht Zuverlässigkeit nicht gegen doppelte Alarme.
## Die Oberfläche darf nicht mehr behaupten, als der Server getan hat
Der Umzug der Deadline auf den Server schuf ein zweites Problem, das mit Servern nichts zu tun hat. App und Backend hatten nun getrennte Vorstellungen von Zeit, und der Bildschirm der App konnte von der Wahrheit abweichen. Im September 2026 fanden ein manueller QA-Durchgang und ein Code-Review drei solche Fälle.
**Die Kulanzzeit war auf dem Bildschirm länger als auf dem Server.** Die App zeigte eine kurze Kulanzzeit, die eine Minute nach dem geplanten Ende endete. Der Server schickte die SMS 30 Sekunden nach dem geplanten Ende. Eine halbe Minute lang konnte die Nutzerin „du hast noch Zeit“ lesen, während die SMS schon unterwegs war. Der Fix richtet die App am Server aus: Die Warnung beginnt jetzt vor dem geplanten Ende, und der Überfällig-Zustand beginnt genau dort.
**Die App meldete „Notfallalarm gesendet“, ohne es wissen zu können.** Die Überfällig-Karte behauptete, der Alarm sei raus. Die App bekommt aber keinen Zustellbericht, nur der Server. Die Karte sagt jetzt, was die App tatsächlich weiß. Vor dem Sendezeitpunkt des Servers bittet sie die Nutzerin, zu bestätigen, dass alles in Ordnung ist. Danach sagt sie, dass der Server die SMS sendet. Bestätigte der Server die Session nie, rät sie, die eigenen Leute direkt zu kontaktieren.
Links: eine laufende Session mit dem Versprechen für ein ausgeschaltetes Handy. Rechts: die Überfällig-Karte nach dem Fix. App-Store-Screenshots aus den UI-Tests der App mit Demodaten („Anna“ ist kein echter Kontakt). Deutsche Oberfläche, September 2026.
**Die App versprach Schutz, bevor der Server zustimmte.** Das zentrale Versprechen von ChrisGuard lautet: Der Alarm geht auch raus, wenn das Handy aus ist. Die App zeigte dieses Versprechen, sobald eine Session begann, auch bei Sessions, die der Server noch nicht annahm, etwa offline. Jetzt erscheint das Versprechen nur für Sessions, die der Server bestätigte. Bis dahin sagt die App, dass der Alarm nur auf diesem iPhone läuft. Dasselbe gilt für Verlängerungen im Offline-Modus. Sie warten in einer lokalen Warteschlange und synchronisieren, sobald das Handy den Server erreicht. Solange eine wartet, kennt der Server noch die alte Deadline, also nimmt die App das Versprechen zurück, bis die Warteschlange leer ist.
Alle drei Fehler haben dieselbe Ursache. Jeder Bildschirm stammt aus der Zeit, als das Handy die Quelle der Wahrheit war, und sprach weiter so, als wäre es das noch. In einer Sicherheits-App ist ein beruhigender Satz, den der Server nicht deckt, kein kosmetisches Problem. Er verändert, was die Nutzerin als Nächstes tut.
## Datenschutz nach „keine Server“
Der Umzug auf einen Server hatte seinen Preis, und die eigenen Texte von ChrisGuard zeigen ihn. Frühe Beschreibungen sagten „keine Server“. Apples Review stellte dann eine direkte Frage: Werden Kontakte hochgeladen? Nach dem Umzug lautete die Antwort Ja, und die Marketingtexte änderten sich entsprechend.
Sobald Daten das Telefon verlassen, ist Datenschutz keine Eigenschaft der Architektur mehr. Er wird zu einer Liste von Entscheidungen: was der Server behält, wie lange, und in welcher Reihenfolge er es löscht.
**Minimale Nutzlast.** Der Server erhält die Telefonnummer des Kontakts und den Nachrichtentext, weil er beides zum Senden braucht. Kontaktnamen erhält er nicht. Der Nachrichtentext kann eine Absenderzeile enthalten, die die Nutzerin selbst schreibt. Der Server verschlüsselt beide Felder im Ruhezustand.
**Ein Standort, keine Historie.** Schaltet die Nutzerin den Standort ein, behält der Server höchstens einen Standort pro Session. Es gibt keinen Verlauf. Verstreicht die Deadline, wartet der Server kurz vor dem Senden, damit das Handy einen frischen Standort hochladen kann, falls es das noch kann. Einen mehrere Stunden alten Standort ignoriert der Server, denn er würde den Kontakt an den falschen Ort schicken.
**Die Reihenfolge des Löschens.** Der Server löscht den gespeicherten Standort bei jedem Ende einer Session: bei einem normalen Check-in, beim Ablauf, bei einem Fehler und bei einer Kontolöschung. Das lehrreichste Detail steckt im Ablauf-Pfad. Der Server löscht den Standort aus der Datenbank, *bevor* ein Schritt kommt, der einen Fehler werfen kann, etwa das Entschlüsseln oder das Senden. Eine frühere Version löschte ihn danach. Scheiterte die Entschlüsselung oder der Anbieter, blieb der Standort in der Tabelle. Der Fehler legte niemandem etwas offen. Er behielt Daten nur länger als versprochen, und für ein Datenschutzversprechen reicht das, um falsch zu sein. Ein Test gegen eine echte Datenbank mit allen Migrationen deckt diesen Pfad jetzt ab.
**Löschen als Stoppsignal.** Das Löschen des Kontos entfernt nicht nur Zeilen. Es bricht laufende Sessions ab, und der Versandpfad prüft vor dem Senden noch einmal, ob das Konto noch existiert. Eine Löschung, die Sekunden vor einer Deadline eintrifft, gewinnt.
Die eigenen Daten der App (Sessions, Kontakte und Vorlagen) synchronisieren über die private iCloud-Datenbank der Nutzerin. ChrisGuard fragt weder nach Namen noch nach E-Mail-Adresse.
## Was die Deadline entschied
Verfolgt man eine einzige Frage durch ein kleines Produkt, erklärt sie den Großteil des Codes. Weil die Deadline halten muss, wenn die Nutzerin nicht handeln kann, lebt sie auf einem Server, und das Handy meldet nur. Weil auch ein Server einen Moment verpassen kann, laufen zwei unabhängige Timer, und die Datenbank sorgt dafür, dass nur einer sendet. Weil der Server jetzt Daten hält, wird Datenschutz zu einer Folge von Löschungen, und die Reihenfolge zählt so viel wie das Löschen selbst. Und weil das Handy nicht mehr die Quelle der Wahrheit ist, muss jeder Satz auf seinem Bildschirm einer sein, den der Server bereits deckt.
