Swiftli Private Relay · SchweizVoraussetzung für den Mobile Companion
Der Weg
dazwischen.
Kurzlebige Mailbox.
Das Telefon einer Mitarbeiterin muss die Zentrale im Betrieb auch dann erreichen, wenn niemand im Firmen-WLAN steht. Dafür gibt es das Relay: den verschlüsselten Weg zwischen beiden Enden. Es reicht weiter — mehr ist es nicht, und mehr soll es nicht sein.
01 — Die Strecke
Zwei Enden. Und ein Bote, der nichts versteht.
Verschlüsselt wird auf dem Mac im Betrieb, entschlüsselt auf dem Telefon — und umgekehrt. Dazwischen liegt das Relay. Der Fachpayload bleibt für den Dienst opak; sichtbar sind die für Routing, Reihenfolge, Ablauf und Betrieb nötigen Hüllendaten. Die Inhaltsschlüssel erhält das Relay nicht.
A
Die Zentrale
Der Mac im Betrieb, auf dem Swiftli Smart HR läuft. Hier liegt die autoritative Fachablage; für Companion und Relay werden nur die jeweils beschriebenen, verschlüsselten Fachpayloads übertragen.
B
Das Relay
Ein Server bei einer Schweizer Anbieterin; den Anwendungsstack verwalten wir, die Infrastruktur stellt die Hosterin bereit. Der Dienst nimmt entgegen und gibt weiter. Er ist kein HR-Archiv und wertet Fachinhalte nicht aus.
C
Der Companion
Das Telefon der Mitarbeiterin, unterwegs. Schichtplan, Ferienantrag, Krankmeldung, verschlüsselter Chat.
02 — Grenzen mit Absicht
Nicht mitlesen.
Möglichst wenig mitschreiben.
Ein Weiterleitungsdienst wird nicht dadurch sicher, dass man ihm vertraut, sondern dadurch, dass man ihm nichts anvertrauen muss. Das Relay ist deshalb bewusst arm gebaut — es kann vieles nicht, was ein Cloud-Dienst könnte.
A
Befristete Queue
Ein verschlüsselter Frame liegt bis zur Empfangsbestätigung oder höchstens bis zu seiner Queue-TTL von sieben Tagen bereit. Pairing-, Replay-, Receipt-, Sperr- und Löschzustände haben eigene, für ihren Sicherheitszweck begrenzte Lebenszyklen; «alles nach sieben Tagen weg» wäre deshalb falsch.
B
Metadatenminimiert
Für Routing, Reihenfolge, Ablauf, Quoten und Missbrauchsschutz braucht der Dienst pseudonyme Handles, Sequenzen, Zustände und Zeitwerte. Die Anwendung vermeidet identifierreiche Access-Logs; Netzwerk- und Sicherheitsmetadaten am Edge, beim Betriebssystem oder beim Hoster werden dadurch nicht weggezaubert.
C
Keine Anwesenheitsfunktion
Das Relay bietet keinen Online-Status und keine HR-Anwesenheitskontrolle. Technische Zustell-, Ablauf- und Sicherheitszustände können trotzdem Rückschlüsse auf einzelne Übertragungen erlauben; sie sind kein metadatenfreier oder anonymer Kanal.
03 — Im Einzelnen
Was auf dem Server liegt. Und was nicht.
- Ende zu Ende verschlüsselt
- Fachinhalte werden auf Mac und Telefon ver- und entschlüsselt. Das Relay besitzt diese Inhaltsschlüssel nicht; es sieht den verschlüsselten Payload und die zur Zustellung nötige Hülle.
- Begrenzte Metadaten
- Gespeichert werden je nach Zustand zufällige oder HMAC-pseudonymisierte Tenant-, Mailbox-, Pairing- und Frame-Handles sowie Richtung, Sequenz, grobe Server- und Ablaufzeiten, Status, Grössenklasse und Ciphertext. Fachliche Company-, Outlet- oder HR-Inhalte gehören nicht in diese Hülle.
- Protokollierung
- Die Relay-Anwendung ist ohne identifierreiche Route-Access-Logs ausgelegt. Edge, Betriebssystem, Abwehrsysteme und Hoster können für Betrieb und Sicherheit dennoch Netzwerkmetadaten verarbeiten; konkrete Fristen dürfen erst nach Prüfung der produktiven Konfiguration zugesagt werden.
- Befristete Zustellung
- Queue-Frames werden nach der Empfangsbestätigung entfernt oder laufen spätestens nach sieben Tagen ab. Sicherheitsrelevante Receipts, Replay-Wasserstände und Revoke-/Pairing-Zustände folgen gesonderten, zweckgebundenen Retention-Regeln.
- Betrieb in der Schweiz
- Der Anwendungsstack läuft auf einem von uns verwalteten Server bei einer Schweizer Hosterin. Die zugrunde liegende Infrastruktur bleibt Teil der Betriebs- und Vertrauenskette.
- Getrennt von der Verwaltung
- Das Relay ist kein Lizenz-, Support- oder Verwaltungsserver. Es leitet weiter; alles andere passiert woanders.
Wie diese Website selbst mit Daten umgeht, steht in der Datenschutzerklärung.
04 — Zusammen mit dem Companion
Das eine gibt es
nur mit dem anderen.
Der Mobile Companion setzt das Relay voraus — ohne den Weg dazwischen käme das Telefon nicht an die Zentrale heran, ausser es steht im Firmen-WLAN. Im lokalen Netz läuft der Abgleich weiterhin direkt; das Relay ist der Weg für alles ausserhalb.
- Im Betrieb: Abgleich direkt im lokalen Netz, ohne Umweg.
- Unterwegs: derselbe Abgleich über das Relay, Ende zu Ende verschlüsselt.
- Die Companion-Apps befinden sich im Debug- und Gerätetest; ein Produktrelease ist noch nicht freigegeben — Entwicklungsstand.
Buchung
Als Zusatz, pro Seat.
Abrechnung pro aktiviertem Seat — Sie zahlen für die Menschen, die die App wirklich nutzen. Tritt jemand aus, wird der Seat deaktiviert und die Verrechnung endet.
Companion und Relay gehören zusammen und werden zusammen gebucht. Preise und Buchung im Shop.
05 — Forschung · Version 2
Live zuerst. Speichern nur als kurzer Rückfallweg.
Wenn aus Hobbys Ernst wird und aus «Googeln» Research. Mit der Veröffentlichung des Swiftli Smart HR und des State-of-the-Art Swiftli Private Relay hat für uns die Arbeit erst begonnen. Aktive Forschung und Test Driven Development sind schon bei Version 2. Wir wollen Datenschutz und Sicherheit in der Branche auf einen höheren Standard bringen und haben Folgendes in Arbeit, das bald zu Swiftli hinzukommt:
Forschungsstand · 02.09.2026
Version 2 ist ein Zielbild in Forschung und Test. Sie ist noch kein produktiver Protokollvertrag und keine Zusage eines Veröffentlichungstermins. Das heute beschriebene Relay v1 bleibt unverändert, bis Threat Model, Dateninventar, plattformübergreifende Tests und unabhängige Prüfungen abgeschlossen sind.
- Live-first-Zustellung
- Das Relay versucht zuerst, einen Ende-zu-Ende-verschlüsselten Payload flüchtig an den erreichbaren Empfänger weiterzugeben. Im erfolgreichen Live-Pfad soll kein Nachrichtenpayload auf dem Relay gespeichert werden.
- Absender-Outbox bis Empfänger-ACK
- Die autoritative Kopie bleibt beim Absender, bis der wirkliche Empfänger den Erhalt Ende zu Ende bestätigt hat. Eine Relay-Annahme oder ein HTTP-Status allein darf die lokale Löschung nicht auslösen.
- Offline-Fallback bis 24 Stunden
- Ist der Empfänger nicht erreichbar, soll ein optionaler Rückfallweg ausschliesslich den opaken E2E-Ciphertext und die minimal nötige Zustellhülle halten — längstens 24 Stunden und nur bis zum bestätigten Empfang.
- Privacy-Tunnel auf Abruf
- Kein permanentes Geräte-VPN: Geprüft wird ein kurzer, app-spezifischer Tunnel nur für Swiftli-Verkehr. Er startet für ein Sende- und Empfangsfenster, bündelt Zustellung und ACKs und endet danach ohne dauernden Keepalive.
- Fail-closed statt Direktweg
- Schlägt der Tunnel fehl, soll es keinen stillen direkten Rückfallweg geben. DNS sowie IPv4 und IPv6 müssen ohne Leak im vorgesehenen Pfad bleiben. Ein standardisierter MASQUE-/CONNECT-UDP-Weg nach RFC 9298 wird als Kandidat geprüft.
- Getrennte Sicht auf Metadaten
- Privacy-Ingress und Relay sollen Infrastruktur, Schlüssel, Administration und Beobachtbarkeit trennen. Gepoolte Verbindungen vieler Clients sollen verhindern, dass ein einzelner Dienst gleichzeitig Client-IP, innere Mailbox und E2E-Klartext zusammenführen kann.
- Keine fremden Personaldaten auf Mobilgeräten
- Mobile-Companion-Geräte werden weder Cache noch Transportpeer für Daten anderer Mitarbeitender. Mehrere Smart-HR-Instanzen dürfen eine gemeinsame Firmen-Outbox nur mit expliziter, atomarer Ownership verwenden.
A
Weniger Persistenz
Keine historischen Payloadbackups, kein dauerhaftes Journal pro Sendung und kein langfristiger Zustellverlauf als Komfortfunktion.
B
Mehr Verantwortung am Endpunkt
Outbox, Empfänger-ACK, Deduplizierung und Multi-Instanz-Ownership werden sicherheitskritischer und deshalb als Zustandsmodelle sowie mit Ausfalltests geprüft.
C
Kryptografie bleibt getrennt
Der Tunnel ergänzt die innere Ende-zu-Ende-Verschlüsselung, ersetzt sie aber nie. VPN-, Ingress-, Relay- und E2E-Schlüssel oder stabile Identifikatoren werden nicht zusammengelegt.
Was vor v2 bewiesen werden muss
Keine Architektur per Behauptung.
- Threat Model und exakter Protokollvertrag mit Anti-Downgrade, Domain Separation und Testvektoren.
- Neustart-, Deduplizierungs- und Löschtests für jede Outbox sowie ein echter E2E-Empfangsnachweis.
- Leak-, Kill-Switch-, DNS-, IPv4-/IPv6- und Abbruchtests auf macOS, iOS und Android.
- Audit von Schlüsselrotation, Providerpfaden, Logs, Retention und physischer Löschung einschliesslich WAL und Backups.
- Messungen zu Latenz, Stromverbrauch und Metadatenwirkung der gebündelten Sync-Fenster.
06 — Nächster Schritt
Am besten sieht man es an einem echten Betrieb.
Wir zeigen Ihnen in einer halben Stunde, wie Zentrale und Telefon zusammenspielen — mit Ihren Schichten, Ihren Leuten, Ihrem Netz.