Datenschutz

Verantwortlicher Betreiber von NextStop by techtumbler ist Jens Farronato, Schweiz.

TODO vor Veröffentlichung: Die noch fehlende zustellfähige Postadresse ergänzen. Diese Angaben beschreiben den geprüften lokalen Entwicklungsstand. Hosting, Aufbewahrung, Apple-Dienste und der tatsächlich veröffentlichte App- und Backend-Stand müssen vor der Freigabe abgeglichen werden.

Diese Webseite

Diese Seiten laden ihr Stylesheet vom selben Server. Es sind keine Analysewerkzeuge, Werbetracker, externen Schriftarten oder eingebetteten Karten eingebunden. Der Webseiten-Code setzt keine Cookies, startet keine Session, fragt keinen Standort ab und greift nicht auf die Backend-Datenbank zu.

Beim Aufruf erhält das Hosting technische Verbindungsdaten, darunter die IP-Adresse, den Zeitpunkt, die angefragte Adresse und vom Browser übermittelte HTTP-Header. Für das Angebot ist Hosting bei cyon vorgesehen. TODO: Die konkrete Vertragspartei, Server- und Backup-Standorte sowie aktivierte Zugriffs-, Fehler- und Sicherheitsprotokolle mit ihren Inhalten und Speicherfristen bestätigen. Aus dem Webseiten-Code sind diese Hosting-Einstellungen nicht ersichtlich.

Externe Quellen und Datenschutzhinweise sind als normale Links eingebunden. Erst wenn du einen solchen Link öffnest, ruft dein Browser das externe Angebot auf; dort gelten dessen eigene Bedingungen und Datenschutzhinweise.

Standort und aktiver Wecker in der App

Die App verwendet die Standortdienste von iOS, um nahe Haltestellen und Entfernungen anzuzeigen. Sie verarbeitet dabei Koordinaten, die Genauigkeit und den Zeitpunkt einer Messung. Der Standortzugriff wird über die iOS-Berechtigung gesteuert.

Für einen aktiven Wecker verwendet die App laufende Standortmessungen und eine Hintergrund-Standortsitzung. Damit kann sie die Entfernung zur gewählten Haltestelle auch verarbeiten, wenn die App nicht im Vordergrund ist. Beim vorgesehenen Beenden oder Auslösen des Weckers beendet der Code diese laufende Überwachung. Zusätzlich kann iOS eine ortsbezogene lokale Mitteilung für den gewählten Zielbereich verwalten.

Die Entfernungsberechnung und die Entscheidung über das Erreichen des Zielbereichs erfolgen im geprüften App-Code auf dem Gerät. Der Abfahrtsrequest an das NextStop-Backend enthält die Kennung der angefragten Haltestelle, nicht die aktuelle GPS-Koordinate. Die Haltestellenkennung beschreibt dennoch einen Ort; zusammen mit Anfragezeit und technischen Kennungen können Anfragen Rückschlüsse auf die Nutzung zulassen.

Haltestellensuche und Favoriten verwenden eine mit der App ausgelieferte Haltestellendatei. Favoritenkennungen werden lokal in den App-Einstellungen gespeichert. Abfahrtsantworten werden in der App zusätzlich kurzzeitig im Arbeitsspeicher zwischengespeichert.

Karte, Mitteilungen und weitere Apple-Dienste

Die Kartenansicht verwendet Apple MapKit und kann den eigenen Standort anzeigen. Die Standortdienste und die Kartenansicht beziehen Apple-Dienste ein; aus der lokalen Berechnung in NextStop folgt keine Zusage, dass keine Daten an Apple übertragen werden. Hinweise dazu bietet Apple unter Ortungsdienste und Datenschutz sowie Apple Maps und Datenschutz (Englisch). Diese allgemeinen Hinweise ersetzen nicht den noch ausstehenden Abgleich der konkret verwendeten MapKit-Funktionen.

Lokale Mitteilungen enthalten den Namen der Zielhaltestelle und die gewählte Alarmdistanz. Bei verfügbarem und erlaubtem AlarmKit übergibt die App Zielname und Haltestellenkennung als Alarm-Metadaten an das iOS-Alarmsystem. Alarm- oder Mitteilungsinhalte können abhängig von den iPhone-Einstellungen auf dem Sperrbildschirm sichtbar werden. Für diese lokalen Erinnerungen ist im geprüften App-Code keine Registrierung beim Apple Push Notification Service eingebaut.

Berechtigungen lassen sich in den iPhone-Einstellungen ändern; dadurch können Funktionen eingeschränkt werden. TODO: Empfänger, Verarbeitungsorte und allfällige Auslandbekanntgaben für MapKit, Ortungsdienste und App Attest anhand des veröffentlichten Builds und der massgeblichen Apple-Bedingungen bestätigen. Nicht belegte Apple-Speicherfristen werden hier nicht zugesichert.

Abfahrtsanfragen und Missbrauchsschutz

Beim Abruf von Abfahrten verarbeitet das Backend die Haltestellenkennung, den App-Attest-Nachweis und technische Verbindungsdaten. Der Rate-Limiter verwendet die vom Webserver bereitgestellte IP-Adresse als Ausgangswert. Er speichert einen SHA-256-Hash der IP-basierten Kennung mit Zähler, Kategorie und Zeitfenster. Für verifizierte Anfragen gibt es zusätzlich einen schlüsselbezogenen Zähler. Diese stabilen Hashes sind keine Zusicherung einer Anonymisierung.

Abfahrtsantworten werden serverseitig je Haltestellenanfrage zwischengespeichert. Zusätzlich werden tägliche Nutzungszähler nach Anfragetyp geführt; diese Zähler enthalten im vorgesehenen Schema weder einzelne IP-Adressen noch Schlüssel- oder Haltestellenkennungen. Die Datenbank führt kein eigenes Abfahrtsjournal je Schlüssel. Das schliesst Einträge in separat konfigurierten Hosting-Protokollen nicht aus.

App Attest von Apple

Zum Schutz der Abfahrts-API nutzt der geprüfte Code Apple App Attest. Die App speichert die Schlüsselkennung und den Registrierungszustand in der iOS-Keychain. Bei einer noch nicht abgeschlossenen Registrierung können dort auch die zugehörige Challenge, ihre Ablaufzeit und das bereits erzeugte Attestation-Objekt für eine Wiederaufnahme liegen. Aus einer Deinstallation wird hier keine automatische Löschung sämtlicher lokaler oder serverseitiger Daten abgeleitet.

Das Backend speichert den Hash der Schlüsselkennung, den öffentlichen Schlüssel, die Umgebung, den verifizierten Attestation-Receipt, Erstellungs-, Prüf- und Nutzungszeitpunkte, einen fortlaufenden Zähler und gegebenenfalls einen Widerrufszeitpunkt. Die Schlüsselkennung und die Nachweise werden bei den entsprechenden HTTP-Anfragen zusätzlich verarbeitet. Ein öffentlicher Schlüssel und seine Kennung können wiederkehrende Anfragen miteinander verknüpfbar machen.

Challenges werden mit Kennung, zufälligem Challenge-Text und dessen Hash, Zweck, Erstellungs-, Ablauf- und Verbrauchszeitpunkt gespeichert. Assertion-Challenges sind zusätzlich an den Schlüssel und das verwendete Profil gebunden. Die Verifikation verarbeitet Attestation- und Assertion-Objekte. Bei der Receipt-Prüfung legt der Code vorübergehend geschützte Dateien an und versucht, sie nach Abschluss zu entfernen; ein Prozessabbruch kann diese Bereinigung verhindern.

Die Attestation bezieht Apple als Dienstanbieter ein. Der private App-Attest-Schlüssel wird nicht an das NextStop-Backend übertragen. Die serverseitige Prüfung verwendet mitgelieferte Apple-Zertifikate; im geprüften Verifier ist kein zusätzlicher Online-Abgleich bei Apple eingebaut. App Attest ist kein Benutzerkonto und kein Nachweis der Identität einer Person.

Weitergabe an den Datendienst

Für nicht aus einem frischen Cache beantwortete Abfahrtsanfragen sieht die Anwendung eine Anfrage an OJP 2.0 auf opentransportdata.swiss vor. Das Backend sendet dafür die Haltestellenkennung, Zeitangaben und Abfrageparameter mit seinem eigenen API-Zugang. Der erzeugte Request enthält weder die aktuelle GPS-Koordinate noch den App-Attest-Nachweis oder die IP-Adresse des iPhones als Nutzdaten. Der Datendienst erhält die technische Verbindung des Backend-Servers.

TODO: Den tatsächlich konfigurierten OJP-Endpunkt und die Empfängerangaben vor Veröffentlichung bestätigen. Die Serverkonfiguration erlaubt einen konfigurierbaren HTTPS-Endpunkt; dessen produktiver Wert wurde für diesen Text nicht ausgelesen. Herkunft und Bedingungen der vorgesehenen Daten sind unter Datenquellen aufgeführt.

Diagnose und Protokolle

Der zentrale API-Fehlerhandler protokolliert bei von ihm behandelten Fehlern eine Anfragekennung, den HTTP-Status und die Fehlerklasse. Er schreibt dabei keine Request-Bodies oder Nachweise in diesen eigenen Protokolleintrag. Das ist keine Aussage darüber, was Webserver, Hosting, PHP oder vorgeschaltete Dienste separat protokollieren.

Debug-Fassungen der App schreiben Diagnoseausgaben und speichern lokal Labordaten, beispielsweise Zielhaltestellen, Alarmereignisse, Messgenauigkeit, Messzeitpunkte und Entfernungen. Für gespeicherte Testfahrten ist keine zeitliche Löschfrist eingebaut. Der Laborspeicher und die eigenen Debug-Ausgaben sind im geprüften Code auf Debug-Builds begrenzt. Bei weitergegebenen Diagnoseauszügen können deshalb orts- und nutzungsbezogene Angaben enthalten sein.

Aufbewahrung, Löschung und Kontakt

Die Ablaufzeit einer Challenge bestimmt, wie lange sie verwendet werden darf. Ein Cache- oder Rate-Limit-Zeitfenster bestimmt ebenfalls die Nutzbarkeit, nicht die Löschung des Datenbankeintrags. Im Backend-Repository ist ein CLI-Bereinigungsprozess für abgelaufene Challenges, Rate-Limit-Einträge, Cache-Einträge und ältere tägliche Nutzungszähler vorbereitet. Daraus folgt keine Zusage, dass er produktiv eingerichtet ist oder regelmässig ausgeführt wird. App-Attest-Schlüssel, ihre Receipts und Counter werden von diesem Prozess nicht gelöscht. Tatsächlich aktive Löschläufe sowie die Aufbewahrungsregeln für Daten und Backups sind vor Veröffentlichung zu bestätigen.

Das bestehende Deployment sichert betroffene versionierte Code-Dateien, nicht die produktive Datenbank. Seine Aufbewahrungsregeln dürfen deshalb nicht als Löschfrist für App-Daten, Datenbank- oder Hosting-Backups verstanden werden.

TODO: Zwecke und erforderliche Aufbewahrungsdauer je Datenkategorie sowie tatsächliche Löschläufe und den Umgang mit widerrufenen Schlüsseln, temporären Prüfdateien, lokalen Diagnosen und Backups verbindlich festlegen. Ebenso das Verfahren für Auskunfts- und Löschanfragen sowie die anwendbaren Datenschutzangaben und Vertragsverhältnisse mit Dienstanbietern ergänzen.

Angaben zum verantwortlichen Betreiber Jens Farronato, Schweiz, stehen im Impressum. Für Datenschutzanfragen erreichst du uns unter kontakt@techtumbler.ch. Die zustellfähige Postadresse ist noch zu ergänzen.