Das Experiment wurde an fünf iPhone 17e mit iOS 26.5.2 durchgeführt. Das Verhalten wiederholte sich auf allen Geräten. Der Netzwerkverkehr wurde in einem kontrollierten WLAN-Netzwerk analysiert. Das wichtigste Ergebnis der Untersuchung:

Das Deaktivieren der Systemanalytik unterbindet nicht die automatische Übertragung von Metadaten an die Apple-Infrastruktur. Sie deaktiviert zwar eine bestimmte Kategorie von Diagnoseberichten, stoppt jedoch nicht „Find My“, den Apple-Account, Geodienste, Werbekomponenten, den App Store, MobileAsset und die systemeigenen Check-in-Mechanismen.

Was genau überträgt das iPhone?

In den entschlüsselten Anfragen wurden folgende Daten entdeckt:

  • die Apple-Account-Adresse;
  • DSID und alternative DSID des Kontos;
  • die Werbe-ADSID;
  • Seriennummer;
  • UDID des Geräts;
  • APN- und Push-Token;
  • IDS-Geräte-ID;
  • Handy-Modell;
  • iOS-Version und Build;
  • Hardware-Plattform;
  • Arbeitsspeichergröße;
  • Gerätename;
  • Region des Kontos;
  • Sprache und Zeitzone;
  • Akkustatus;
  • Ladezustand;
  • Status der Bildschirmsperre;
  • Status von „Find My“;
  • Status der Standortdienste;
  • BSSID der umliegenden WLAN-Hotspots;
  • Koordinaten für WeatherKit;
  • Versionen der installierten Systemkomponenten;
  • Informationen zu verbundenen Apple-Geräten.

Es handelt sich hierbei nicht um einen einheitlichen „Analysebericht“. Die Daten sind auf mehrere funktionale Dienste von Apple verteilt. Aus technischer Sicht handelt es sich jedoch um automatische Telemetrie: Das Smartphone übermittelt an entfernte Server Informationen über sich selbst, seinen Status und seine Umgebung.

Apple erhält Meldungen über das Ein- und Ausschalten der Standortbestimmung

Der aussagekräftigste Mechanismus steht im Zusammenhang mit „Find My“.

Bei jeder Statusänderung der Standortdienste sendet das iPhone eine Anfrage:

POST p117-fmf.icloud.com/fmipservice/fmf/<DSID>/<UDID>/register

Als die Standortbestimmung deaktiviert wurde, enthielt der HTTP-Request-Text Folgendes:

{
  "cause": "LocationServicesStateChanged",
  "registeredCauses": [
    "LocationServicesStateChanged"
  ],
  "locationServicesEnabled": false,
  ...
}

Beim anschließenden Einschalten:

{
  "cause": "LocationServicesStateChanged",
  "registeredCauses": [
    "LocationServicesStateChanged"
  ],
  "locationServicesEnabled": true
}

Beide Anfragen wurden vom Apple-Server mit folgender Antwort angenommen: HTTP 204 No Content

Auf diese Weise erhält Apple nicht nur den aktuellen Standortstatus. Der Server erhält ein separates Ereignis, das mitteilt, dass der Nutzer die entsprechende Einstellung geändert hat.

Das Flag selbst true oder false ist nur ein kleiner Teil der Anfrage. Zusammen mit ihm werden übermittelt:

  • DSID des Apple-Kontos;
  • UDID des Telefons;
  • Seriennummer;
  • Gerätemodell;
  • iOS-Version und -Build;
  • Gerätename;
  • APN-Token;
  • Liste der Push-Token;
  • IDS-Geräte-ID;
  • Akkuladestand;
  • Ladezustand;
  • Sperrstatus;
  • Standort;
  • Zeitzone;
  • Apple-Zertifizierungskennungen.

Dies ist ein vollständig identifiziertes Ereignis. Es ist gleichzeitig mit dem Konto, einem bestimmten Gerät und dessen aktuellem Status verknüpft.

Was passiert nach dem Aktivieren der Standortbestimmung?

Bei deaktivierter Standortbestimmung wurden die Anfragen mit BSSID-Übertragung eingestellt. Innerhalb von zweieinhalb Stunden gab es keinen einzigen Aufruf des primären WLAN-Ortungsdienstes.

Unmittelbar nach dem Aktivieren der Standortbestimmung begann das iPhone, folgende Dienste anzurufen: http://gs-loc.apple.com/clls/wloc

Einem Systemprozess locationd sendete Apple Listen der umliegenden Zugangspunkte.

In einer der Anfragen wurden 19 BSSIDs übermittelt. Als Antwort lieferte Apple 119 WLAN-Einträge zurück, die sich auf die Umgebung bezogen.

Der Mechanismus funktioniert wie folgt:

  1. Das iPhone scannt die verfügbaren WLAN-Hotspots.
  2. Das Telefon sendet deren BSSIDs – die MAC-Adressen der Zugangspunkte – an Apple.
  3. Der Server gibt geografische Informationen zu den gefundenen und benachbarten Zugangspunkten zurück.
  4. Das Telefon berechnet seinen Standort lokal.

Formal gesehen sendet das Gerät keine Meldung wie „Ich befinde mich an dieser Adresse“. Doch die Liste mehrerer umgebender BSSIDs in Verbindung mit dem Zeitpunkt der Anfrage ermöglicht es dem Server, den Standort des Telefons mit hoher Genauigkeit zu bestimmen.

Ein separater Prozess geod wird aufgerufen: http://gspXX-ssl.ls.apple.com/wifi_request

In dieser Anfrage wird eine BSSID übermittelt – wahrscheinlich die Kennung des aktuellen Verbindungspunkts oder des Hauptpunkts, der bei der Positionsbestimmung verwendet wird.

Geodienste funktionieren auch bei deaktivierter Standortbestimmung weiter

Das Deaktivieren der Geolokalisierungsdienste unterbrach zwar das Laden der Listen der umliegenden BSSIDs, stoppte jedoch nicht den iOS-Geolokalisierungsstapel selbst.

Prozesse geod und locationd griffen weiterhin auf folgende Datei zu:

gspXX-ssl-background.ls.apple.com/dispatcher.arpc
gsp-ssl.ls.apple.com/ab.arpc
configuration.ls.apple.com/config/defaults
gspeX-ssl.ls.apple.com/pep/gcc
gspeXX-ssl.ls.apple.com/ligl/v1/ligl.bin
gspeXX-ssl.ls.apple.com/geo_manifest/dynamic/config

In den Anfragen wurden folgende Angaben übermittelt:

  • iPhone-Modell;
  • iOS-Version;
  • Build-Nummer;
  • Systemprozess-ID;
  • Sprache;
  • Region;
  • Art der Apple Maps-Anfrage;
  • Dienstparameter der geografischen Konfiguration.

In den Antworten dispatcher.arpc enthalten waren regionale Daten und Blöcke für die Rückgeokodierung.

Bei identischen Anfragen lieferten verschiedene Serverknoten Daten für Japan oder die Region des Apple-Accounts zurück. Dies zeigt, dass das geografische Subsystem auch bei deaktiviertem Benutzerzugriff auf die Geolokalisierung weiterhin die Serverkonfiguration erhält.

WeatherKit übermittelt Koordinaten in der URL

Die iOS-Wetterkomponente griff auf folgende Adresse zu:

weatherkit.apple.com/api/v2/weather/<lang>/<lat>/<lon>

Die Koordinaten befanden sich direkt im URL-Pfad mit einer Genauigkeit von drei Dezimalstellen – etwa bis zu hundert Metern.

Zusätzlich wurden folgende Daten übermittelt:

  • Zeitzone;
  • Land;
  • Gerätesprachen;
  • iOS-Version;
  • Build-Nummer;
  • Liste der Wetterdatensätze;
  • Zeitraum;
  • Request-UUID;
  • Bearer-JWT.

Das JWT wurde zur Autorisierung von WeatherKit verwendet und enthielt weder DSID, UDID noch eine Seriennummer. Die HTTPS-Anfrage selbst enthielt jedoch dennoch die Koordinaten und die IP-Adresse der Quelle.

In einem der Captures hat der Apple-Server eine solche Anfrage erfolgreich verarbeitet und folgende Antwort zurückgegeben HTTP 200.

Folglich handelt es sich bei der Übermittlung der Koordinaten an WeatherKit nicht nur um eine lokal generierte Anfrage, sondern um einen bestätigten Austausch mit dem Server.

„Find My“ übermittelt den Status des Telefons

„Find My“ wird nicht nur beim Umschalten der Standortbestimmung verwendet.

Nach einem Neustart sendet das iPhone denselben Registrierungstyp mit folgendem Grund: cause = DeviceRestart

Im Gerät befinden sich:

  • Seriennummer;
  • UDID;
  • Gerätename;
  • Modell;
  • iOS-Version;
  • Push-Token;
  • IDS (Geräte-ID);
  • Akkuladestand;
  • Ladezustand;
  • Ist das Ladegerät angeschlossen?
  • Ist der Bildschirm gesperrt?
  • Ist die Standortbestimmung aktiviert?
  • ob „Find My“ aktiv ist.

Der Server erhält die genaue Zeit des Neustarts und den aktuellen Status des Geräts.

„Find My“ fungiert in diesem Fall als vollwertiger Kanal für Betriebsdaten, der an den Apple-Account und ein bestimmtes physisches Gerät gebunden ist.

Apple-Account-Check-in

Nach dem Neustart sendet der Systemprozess com.apple.NewDeviceOutreach eine Anfrage:
POST sse-ws-p189.apple.com/device/api/v1/checkIn

Darin enthalten sind:

  • E-Mail-Adresse des Apple-Kontos;
  • die primäre DSID;
  • die alternative DSID;
  • Seriennummer;
  • Gerätemodell;
  • Name des Telefons;
  • Gehäusefarbe;
  • Region;
  • Storefront;
  • Sprache;
  • Zeitzone;
  • Garantie-Hash;
  • Liste der lokalen Apple-Geräte;
  • Informationen zu verbundenen Apple Watches;
  • Dienst-IDs von Apple Media Services;
  • Hardware-Zertifizierung.

Der Server gibt das Ergebnis SUCCESS und den Zeitpunkt des nächsten Check-ins zurück.

Dies ist eine der Anfragen mit dem höchsten Anteil an personenbezogenen Daten. Sie vereint das Konto, das physische Gerät, Garantieinformationen und Angaben zu verbundenen Geräten.

Die Werbeinfrastruktur funktioniert auch bei deaktivierter Personalisierung

Bei deaktivierter personalisierter Werbung liefen die Systemprozesse weiter:

com.apple.ap.promotedcontentd
com.apple.ap.adprivacyd

Sie griffen auf Folgendes zu:

sas.pcms.apple.com
iadsdk.apple.com
ca.iadsdk.apple.com
partiality.itunes.apple.com

In den Anfragen zur Werbesegmentierung wurden folgende Daten übermittelt:

  • DSID;
  • ADSID;
  • storefront;
  • Lokalisierung;
  • Zeitzone;
  • Gerätebescheinigung;
  • Server-Cookies;
  • Service-Flags des Werbeprofils.

Der Attributions-Endpunkt erhielt:

  • App-ID im App Store;
  • Bundle-ID;
  • Attributionsschlüssel;
  • das iPhone-Modell;
  • die iOS-Version;
  • Build;
  • Storefront;
  • Zeitstempel;
  • Apple-Signatur.

Im Text befand sich folgender Wert: attribution = false

Das bedeutet, dass keine positive Werbeattribution festgestellt wurde. Der Mechanismus der Attribution und der Werbesegmentierung selbst funktionierte jedoch weiterhin.

Das Deaktivieren personalisierter Werbung schaltet den Werbestack nicht aus. Es ändert die Regeln für die Datennutzung, unterbricht aber nicht den Datenaustausch im Netzwerk.

Der App Store lädt die Konfiguration der Metriken über bag.itunes.apple.com/bag.xml

Das iPhone erhält die Konfiguration des App Stores und der Mediendienste.

In den Anfragen übermittelt das Smartphone:

  • Modell;
  • Gerätekategorie;
  • iOS-Version und -Build;
  • Storefront;
  • Sprache;
  • Zeitzone;
  • ID des Systemprozesses.

Die Antworten enthalten folgende Adressen:

xp.apple.com/report
daf.xp.apple.com/report

Außerdem übermittelt der Server:

  • Themen der Usage-Metriken;
  • Themen der Leistungsmetriken;
  • Sendeintervalle;
  • Sampling-Parameter;
  • rotierende Client-IDs;
  • Regeln zur Begrenzung von Ereignissen und Feldern.

Verbindungen zu xp.apple.com wurden zwar erfasst, ihr Inhalt blieb jedoch verschlüsselt. Daher ist es anhand der vorliegenden Daten nicht möglich, die genaue Zusammensetzung der dorthin gesendeten Ereignisse zu ermitteln.

Es lässt sich lediglich Folgendes feststellen: Der Metrik-Pipeline war konfiguriert, und das iPhone stellte Verbindungen zum Berichtempfangsserver her.

Siri und Apple Intelligence empfangen weiterhin Systemmanifeste

Selbst bei deaktiviertem Siri und Apple Intelligence griff das Telefon weiterhin auf folgende Dienste zu: gdmf-ados.apple.com/v2/assets

Folgende Systempakete wurden abgefragt:

com.apple.MobileAsset.UAF.Siri.UnderstandingNLOverrides
com.apple.MobileAsset.UAF.Siri.UnderstandingASRHammer
com.apple.MobileAsset.UAF.IF.PlannerOverrides

In den Anfragen wurden folgende Daten übermittelt:

  • das Smartphone-Modell;
  • Hardware-Plattform;
  • Größe des Arbeitsspeichers;
  • iOS-Version und Build;
  • Build-ID;
  • System-Image-ID;
  • Update-Status;
  • Rollback-Status;
  • Versionen der installierten Komponenten;
  • Sitzungs-ID;
  • Nonce;
  • Asset-Zielgruppe.

Die Antworten enthielten signierte Manifeste:

  • URL des Systemarchivs;
  • Komponentenversion;
  • Build;
  • Archiv-ID;
  • Entschlüsselungsschlüssel für das Archiv;
  • Digest;
  • Größe;
  • Bereich kompatibler iOS-Versionen;
  • Caching-Regeln.

Die Übertragung von Sprache, Siri-Text oder Benutzeranfragen findet hier nicht statt. Es handelt sich um eine Überprüfung auf Updates der Systemkomponenten.

Die Deaktivierung der Funktionen führt jedoch nicht dazu, dass das Gerät aus dem Support für die entsprechenden Komponenten genommen wird: Das iPhone überprüft weiterhin regelmäßig deren Versionen und übermittelt Apple detaillierte Informationen zur Hardware- und Softwarekonfiguration.

Ein Neustart und der Flugmodus lösen eine Kaskade von Verbindungen aus

Ein Neustart ist eines der ereignisreichsten Vorgänge.

Unmittelbar nach dem Start des iPhones:

  • registriert es sich bei „Find My“ mit dem Grund DeviceRestart;
  • führt es einen Apple-Account-Check-in durch;
  • wird die Netzwerkverfügbarkeit geprüft;
  • ermittelt die externe IP-Adresse;
  • lädt die App Store-Caches;
  • stellt die Verbindung zu iCloud wieder her;
  • überprüft MobileAsset;
  • aktualisiert die geografischen Konfigurationen.

Innerhalb einer Minute nach dem Neustart wurden Dutzende von Zugriffen auf folgende Dienste verzeichnet:

gateway.icloud.com
bag.itunes.apple.com
setup.icloud.com
gsa.apple.com
itunes.apple.com
fpinit.itunes.apple.com

Ein ähnliches Verhalten wurde beim Ein- und Ausschalten des Flugmodus beobachtet.

Nach der Rückkehr ins Mobilfunknetz stellte das iPhone Verbindungen zu folgenden Diensten her: gateway.icloud.com

und leitete eine erneute Initialisierung der Apple-Systemdienste ein.

Der Inhalt des Datenaustauschs mit gateway.icloud.com konnte nicht entschlüsselt werden, doch die Tatsache des Netzwerkereignisses und dessen Zusammenhang mit dem Umschalten des Flugmodus ließen sich in einem kontrollierten Experiment reproduzieren.

Geschützte Dienste verschwinden beim Anzeigen von HTTPS

Ein Teil der Apple-Dienste funktionierte bei aktivem Aufrufen von HTTPS-Traffic durchweg nicht.

Das Experiment wurde wiederholt:

  • auf fünf iPhone 17e;
  • über zwei Tage hinweg;
  • nach jeweils 5–10 Neustarts jedes Geräts.

Solange der HTTPS-Datenverkehr entschlüsselt wurde, stellten die entsprechenden Dienste keine funktionierenden Verbindungen her.

Unmittelbar nach Deaktivierung der Entschlüsselung nahmen sie den Betrieb wieder auf und wurden als nicht-transparente CONNECTVerbindungen.

Dieses Verhalten wiederholte sich und war kein zufälliger Netzwerkausfall.

Daher setzte sich das Gesamtbild aus zwei Arten von Erfassungen zusammen:

  1. mit Entschlüsselung – zur Analyse von URLs, Headern und Inhalten;
  2. ohne Entschlüsselung – zur Erfassung sicherer Dienste, die unter Beobachtung nicht funktionieren.

Ein CONNECT entspricht nicht einer HTTP-Anfrage. Innerhalb eines Tunnels können zahlreiche Vorgänge ablaufen. Daher lässt sich die Anzahl CONNECT nicht direkt mit der Anzahl der entschlüsselten GET- und POST-Anfragen verglichen werden.

Das Telefon greift im Leerlauf weiterhin auf Apple zu

In einer lang andauernden Hintergrundsitzung lag das iPhone ohne Benutzeraktivität.

Obwohl Analytik, Geolokalisierung, Siri und Synchronisierung deaktiviert waren, stellte das Gerät weiterhin alle paar Minuten eine Verbindung zur Apple-Infrastruktur her.

Zu den regelmäßigsten Verbindungen gehörten:

  • gspXX-ssl-background.ls.apple.com — etwa alle 30 Minuten;
  • configuration.ls.apple.com — etwa alle 50 Minuten;
  • iphone-ld.apple.com — etwa alle 51 Minuten;
  • gateway.icloud.com — in Serien;
  • weatherkit.apple.com — etwa alle paar Stunden;
  • caldav.icloud.com — etwa einmal pro Stunde.

Innerhalb von 8,8 Stunden gab es kein einziges vollständig „schlafendes“ Intervall, das länger als 21 Minuten dauerte.

Fazit

Die Untersuchung ergab keine offensichtlichen Crash-Berichte, Stack-Traces oder vollständigen Diagnose-Archive. Wahrscheinlich deaktiviert der Schalter „iPhone-Analytik“ tatsächlich genau diese Art der Berichterstattung.

Er deaktiviert jedoch nicht die iOS-Telemetrie als Ganzes.

Auch bei deaktivierten Benutzereinstellungen übermittelt das iPhone 17e weiterhin folgende Daten an Apple:

  • Konto-IDs;
  • E-Mail-Adresse des Apple-Kontos;
  • DSID und ADSID;
  • Seriennummer;
  • UDID;
  • Push-Token;
  • IDS (Geräte-ID);
  • Akkustatus;
  • Sperrstatus;
  • Neustart;
  • Umschaltung der Geolokalisierung;
  • Änderung des Netzwerkstatus;
  • BSSID der umgebenden WLAN-Hotspots;
  • Koordinaten für den Wetterdienst;
  • Informationen zu verbundenen Geräten;
  • detaillierter Hardware- und Software-Fingerabdruck;
  • Daten zur Werbesegmentierung und -zuordnung.

Wichtigste Erkenntnis:

In iOS gibt es keinen einheitlichen Schalter für den Nutzer, mit dem die automatische Übermittlung von Metadaten an Apple unterbunden werden kann. Das Deaktivieren der Analytik schaltet zwar den eigentlichen Analysemechanismus aus, doch die funktionalen Dienste melden dem Server weiterhin, um welches Gerät es sich handelt, mit welchem Konto es verknüpft ist, in welchem Zustand es sich befindet und was mit seinen Systemeinstellungen geschieht.

Alle beschriebenen Daten werden über verschlüsselte HTTPS-Verbindungen übertragen. Der Provider oder Betreiber eines gewöhnlichen WLAN-Netzwerks kann diese Daten nicht einsehen. Sie werden direkt von Apple empfangen. Eine Aussage darüber, ob Daten an gateway.icloud.com und an andere Dienste, die SSL-Pinning verwenden, übertragen worden sein könnten, können wir nicht bestätigen.