Deine Daten.

Drei Teile

Die Apps reden nie direkt mit Google; sie kennen deine Google-Anmeldung nicht. Der Zugang zum Backend läuft über eine Adresse und einen Zugangsschlüssel, die du einmal einträgst. Das Backend ist der einzige Ort mit Logik, damit Regeln auch laufen, wenn kein Gerät an ist, und damit nachvollziehbar bleibt, was passiert.

Google bleibt die Quelle

Jeder Termin liegt in deinem Google-Kalender und nur dort. Zulu liest über die Google-Calendar-API und schreibt über sie. Es gibt keinen zweiten Datenbestand, der auseinanderlaufen könnte. Hörst du mit Zulu auf, ist nichts weg.

• Zugriff: pro Google-Konto eine Anmeldung per OAuth mit der Berechtigung für Google Kalender. Google zeigt dabei, worauf Zulu zugreift; du kannst den Zugriff jederzeit in deinem Google-Konto widerrufen.
• Zeitraum: Zulu lädt 30 Tage zurück und 180 Tage voraus. Fragst du in der App einen Zeitraum außerhalb an, holt das Backend ihn direkt bei Google, ohne ihn zu speichern.
• Aktualität: Google meldet Änderungen per Push an das Backend. Zusätzlich fragt es jede Minute nach, falls eine Push-Nachricht ausbleibt.

Was das Backend speichert

Eine SQLite-Datenbank, eine Datei. Darin:

• Ein Zwischenspeicher der Termine im geladenen Zeitraum, damit die Apps schnell sind und Regeln rechnen können. Er wird bei jedem Abgleich aus Google neu aufgebaut.
• Was Google nicht abbilden kann: der Typ eines Termins (normal, Wegzeit, Blocker), die Verknüpfung zwischen Termin und Wegzeit bzw. Blocker, deine Regeln, die Wegzeiten und Ausschlüsse pro Termin oder Serie, die Rollen deiner Kalender (Privat, Arbeit, Sonstige).
• Pro Google-Konto ein Zugriffstoken, verschlüsselt mit AES-256-GCM und einem Schlüssel, der nur auf dem Server liegt.
• Ein Protokoll der Abgleiche zur Fehlersuche.

Keine Auswertung, keine Weitergabe, keine Dienste von Dritten: Das Backend spricht ausschließlich mit Google und deinen Apps.

Was Zulu in Google schreibt

• Was du selbst anlegst, änderst oder löschst.
• Wegzeit-Termine („⏳ Wegzeit“) vor und nach Terminen mit Wegzeit, im selben Kalender.
• Blocker im Zielkalender einer Regel, mit dem Titel der Regel, privat, ohne Details.
• Kopien von Arbeitsorten, falls du eine Übertragungsregel angelegt hast.

Alle drei sind normale Google-Termine mit einem kurzen Zulu-Marker, damit Zulu sie wiedererkennt. Bestehende Termine fasst Zulu nur an, wenn du es tust. Und es schreibt nur in Kalender, die beim Einrichten als beschreibbar festgelegt wurden; alle anderen sind für Zulu schreibgeschützt.

Was auf Mac und iPhone liegt

• Mac: Adresse und Zugangsschlüssel des Backends, verschlüsselt über den Schlüsselbund von macOS. Dazu Fensterlage, ausgeblendete Kalender, Ansicht, und seit Oktober 2026 ein lokaler Zwischenspeicher der zuletzt geladenen Termine für den schnellen Start.
• iPhone: Einstellungen im Schlüsselbund des Geräts. Ein Zwischenspeicher des geladenen Zeitraums im Speicher der App, damit Woche, Tag, Monat, Suche und Widget auch ohne Netz den letzten Stand zeigen. Er ist Teil des Gerätebackups.
• Die Mitteilung „Losgehen“ plant die iPhone-App lokal; dafür verlässt nichts das Gerät.

Wo das Backend läuft

Zwei Möglichkeiten. Entweder wir betreiben das Backend für dich auf eigener Hardware, nicht bei einem Cloud-Anbieter. Oder du betreibst es selbst: Es ist ein einzelner Prozess mit einer SQLite-Datei, läuft als Container (Docker oder Podman) und braucht wenig, ein Raspberry Pi reicht. Für Push von Google muss eine Adresse öffentlich erreichbar sein; ohne sie arbeitet Zulu nur mit der minütlichen Abfrage.

Zulu wieder trennen

1. In deinem Google-Konto unter Sicherheit › Drittanbieter-Apps den Zugriff von Zulu entfernen. Ab da kann das Backend nichts mehr lesen oder schreiben.
2. Wegzeiten, Blocker und Arbeitsort-Kopien bleiben als normale Termine in Google stehen. Du löschst sie dort wie jeden anderen Termin, oder wir entfernen sie vorher für dich.
3. Sag uns Bescheid, dann löschen wir Zwischenspeicher, Regeln und Token aus dem Backend. Betreibst du es selbst, löschst du die Datenbankdatei.