L'expérience a été menée sur cinq iPhone 17e fonctionnant sous iOS 26.5.2. Le même comportement a été observé sur tous les appareils. Le trafic réseau a été analysé sur un réseau Wi-Fi contrôlé. Principale conclusion de l'étude :

La désactivation des analyses système n’empêche pas la transmission automatique de métadonnées vers l’infrastructure d’Apple. Elle désactive une catégorie spécifique de rapports de diagnostic, mais n'interrompt pas les services Find My, Apple Account, les services de géolocalisation, les composants publicitaires, l'App Store, MobileAsset et les mécanismes de connexion système.

Ce que l’iPhone transmet exactement

Les requêtes déchiffrées ont révélé :

  • l'adresse de l'Apple Account ;
  • le DSID et le DSID alternatif du compte ;
  • l'ADSID publicitaire ;
  • le numéro de série ;
  • l'UDID de l'appareil ;
  • les jetons APNs et push ;
  • l'identifiant IDS de l'appareil ;
  • modèle du téléphone ;
  • la version et le build d'iOS ;
  • plateforme matérielle ;
  • la quantité de mémoire vive ;
  • nom de l'appareil ;
  • la région du compte ;
  • la langue et le fuseau horaire ;
  • l'état de la batterie ;
  • état de charge ;
  • état du verrouillage de l'écran ;
  • état de la fonction « Localiser mon » ;
  • l'état des services de géolocalisation ;
  • BSSID des points d'accès Wi-Fi à proximité ;
  • les coordonnées pour WeatherKit ;
  • les versions des composants système installés ;
  • informations sur les appareils Apple associés.

Il ne s’agit pas d’un « rapport analytique » unique. Les données sont réparties entre plusieurs services fonctionnels d’Apple. Mais d’un point de vue technique, il s’agit de télémétrie automatique : le téléphone transmet à des serveurs distants des informations sur lui-même, son état et son environnement.

Apple reçoit les événements d'activation et de désactivation de la géolocalisation

Le mécanisme le plus révélateur est lié à Find My.

À chaque changement d’état des services de géolocalisation, l’iPhone envoie une requête :

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

Lorsque la géolocalisation était désactivée, le corps de la requête HTTP contenait :

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

Lors de l'activation suivante :

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

Les deux requêtes ont été acceptées par le serveur Apple, qui a renvoyé la réponse suivante : HTTP 204 No Content

Ainsi, Apple ne reçoit pas seulement l'état actuel de la géolocalisation. Le serveur reçoit un événement distinct indiquant que l'utilisateur a modifié le paramètre correspondant.

L'indicateur true ou false ne représente qu’une petite partie de la requête. Sont également transmis :

  • le DSID du compte Apple ;
  • l'UDID du téléphone ;
  • le numéro de série ;
  • le modèle de l'appareil ;
  • la version et le numéro de build d’iOS ;
  • nom du téléphone ;
  • le jeton APN ;
  • liste des jetons push ;
  • l'identifiant IDS de l'appareil ;
  • le niveau de charge de la batterie ;
  • état de charge ;
  • état de verrouillage ;
  • localisation ;
  • fuseau horaire ;
  • en-têtes de certification Apple.

Il s'agit d'un événement entièrement identifié. Il est lié à la fois au compte, à un appareil spécifique et à son état actuel.

Que se passe-t-il après l'activation de la géolocalisation ?

Lorsque la géolocalisation était désactivée, les requêtes avec envoi du BSSID cessaient. En deux heures et demie, il n’y a eu aucune requête adressée au service principal de localisation Wi-Fi.

Immédiatement après l’activation de la géolocalisation, l’iPhone a commencé à interroger : http://gs-loc.apple.com/clls/wloc

processus système locationd envoyait à Apple des listes de points d’accès environnants.

L’une de ces requêtes contenait 19 BSSID. En réponse, Apple a renvoyé 119 entrées Wi-Fi correspondant à la zone environnante.

Le mécanisme fonctionne comme suit :

  1. L'iPhone analyse les points d'accès Wi-Fi disponibles.
  2. Le téléphone envoie à Apple leurs BSSID, c'est-à-dire les adresses MAC des points d'accès.
  3. Le serveur renvoie des informations géographiques sur les points d'accès détectés et voisins.
  4. Le téléphone calcule sa position en local.

Techniquement, l'appareil n'envoie pas de message du type « je me trouve à cette adresse ». Mais la liste des différents BSSID environnants, associée à l'heure de la requête, permet au serveur de déterminer la zone où se trouve le téléphone avec une grande précision.

Par ailleurs, le processus geod s'adresse à : http://gspXX-ssl.ls.apple.com/wifi_request

Cette requête transmet un seul BSSID — probablement l’identifiant du point de connexion actuel ou du point principal utilisé pour le positionnement.

Les services de géolocalisation continuent de fonctionner lorsque la géolocalisation est désactivée

La désactivation des services de géolocalisation interrompait le chargement des listes de BSSID environnants, mais n’arrêtait pas la pile géographique iOS elle-même.

Les processus geod et locationd continuaient à accéder à :

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

Les requêtes contenaient les éléments suivants :

  • modèle d'iPhone ;
  • version d’iOS ;
  • numéro de build ;
  • identifiant du processus système ;
  • langue ;
  • la région ;
  • type de requête Apple Maps ;
  • paramètres de configuration géographique internes.

Les réponses dispatcher.arpc contenaient des données régionales et des blocs de géocodage inverse.

Pour des requêtes identiques, différents nœuds de serveur renvoyaient des informations concernant le Japon ou la région de l’Apple Account. Cela montre que le sous-système géographique continue de recevoir la configuration du serveur même lorsque l’accès utilisateur à la géolocalisation est désactivé.

WeatherKit transmet les coordonnées dans l’URL

Le composant météo d’iOS s’est connecté à :

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

Les coordonnées figuraient directement dans le chemin d’accès de l’URL avec une précision de trois décimales — soit environ une centaine de mètres.

Les informations suivantes étaient également transmises :

  • le fuseau horaire ;
  • le pays ;
  • les langues de l'appareil ;
  • la version d'iOS ;
  • le numéro de build ;
  • liste des ensembles de données météorologiques ;
  • plage temporelle ;
  • UUID de la requête ;
  • JWT Bearer.

Le JWT était utilisé pour l’authentification de WeatherKit et ne contenait ni DSID, ni UDID, ni numéro de série. Cependant, la requête HTTPS elle-même contenait tout de même les coordonnées et l’adresse IP de la source.

Dans l'une des captures, le serveur d'Apple a traité avec succès une telle requête et a renvoyé HTTP 200.

Par conséquent, la transmission des coordonnées à WeatherKit ne se limite pas à une requête générée localement, mais implique également un échange validé par le serveur.

Find My transmet l’état du téléphone

« Find My » n’est pas uniquement utilisé lors de l’activation ou de la désactivation de la géolocalisation.

Après un redémarrage, l’iPhone envoie le même type d’enregistrement avec la raison suivante : cause = DeviceRestart

L'appareil contient :

  • le numéro de série ;
  • l'UDID ;
  • le nom de l'appareil ;
  • le modèle ;
  • la version d'iOS ;
  • jetons push ;
  • IDS (identifiant de l'appareil) ;
  • niveau de charge de la batterie ;
  • état de charge ;
  • le chargeur est-il branché ?
  • si l'écran est verrouillé ;
  • la géolocalisation est-elle activée ?
  • si la fonction « Find My » est active.

Le serveur reçoit l'heure exacte de redémarrage et l'état actuel de l'appareil.

Dans ce cas précis, « Find My » fait office de canal complet de télémétrie d'exploitation, lié à un compte Apple et à un appareil physique spécifique.

Enregistrement via l'Apple ID

Après le redémarrage, le processus système com.apple.NewDeviceOutreach envoie une requête :
POST sse-ws-p189.apple.com/device/api/v1/checkIn

Elle contient :

  • l'adresse e-mail de l'Apple Account ;
  • le DSID principal ;
  • le DSID secondaire ;
  • le numéro de série ;
  • le modèle de l'appareil ;
  • nom du téléphone ;
  • couleur du boîtier ;
  • région ;
  • boutique ;
  • la langue ;
  • fuseau horaire ;
  • hachage de la garantie ;
  • liste des appareils Apple locaux ;
  • informations sur les Apple Watch associées ;
  • identifiants de service Apple Media Services ;
  • certification matérielle.

Le serveur renvoie le résultat SUCCESS et l'heure du prochain check-in.

Il s'agit de l'une des requêtes contenant le plus de données à caractère personnel. Elle regroupe le compte, l'appareil physique, les informations de garantie et les informations sur les appareils associés.

L'infrastructure publicitaire fonctionne même lorsque la personnalisation est désactivée

Lorsque la publicité personnalisée était désactivée, les processus système continuaient de fonctionner :

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

Ils accédaient à :

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

Les requêtes de segmentation publicitaire transmettaient :

  • DSID ;
  • ADSID ;
  • storefront ;
  • localisation ;
  • fuseau horaire ;
  • attestation de l'appareil ;
  • cookies de serveur ;
  • indicateurs de service du profil publicitaire.

L'endpoint d'attribution a reçu :

  • l'identifiant de l'application dans l'App Store ;
  • l'identifiant du bundle ;
  • la clé d'attribution ;
  • le modèle d’iPhone ;
  • la version d'iOS ;
  • la version ;
  • vitrine ;
  • horodatage ;
  • signature Apple.

Le corps du message contenait la valeur suivante : attribution = false

Cela signifie qu’aucune attribution publicitaire positive n’a été établie. Mais le mécanisme d’attribution et de segmentation publicitaire continuait de fonctionner.

La désactivation de la publicité personnalisée ne désactive pas la pile publicitaire. Elle modifie les règles d'utilisation des données, mais n'interrompt pas les échanges au sein du réseau.

L’App Store télécharge la configuration des métriques via bag.itunes.apple.com/bag.xml

l’iPhone reçoit la configuration de l’App Store et des services multimédias.

Dans ses requêtes, le téléphone transmet :

  • le modèle ;
  • la catégorie de l'appareil ;
  • la version et le numéro de build d’iOS ;
  • la vitrine ;
  • la langue ;
  • le fuseau horaire ;
  • l'identifiant du processus système.

Les réponses contiennent les adresses suivantes :

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

Le serveur transmet également :

  • les thèmes « usage-metric » ;
  • les thèmes des métriques de performance ;
  • les intervalles d'envoi ;
  • les paramètres d'échantillonnage ;
  • les identifiants client rotatifs ;
  • règles de limitation des événements et des champs.

Des connexions avec xp.apple.com ont été enregistrées, mais leur contenu est resté chiffré. Il est donc impossible, à partir des données disponibles, de déterminer avec précision la composition des événements qui y ont été envoyés.

On ne peut affirmer que ceci : le flux de métriques était configuré, et l’iPhone établissait des connexions avec le serveur de réception des rapports.

Siri et Apple Intelligence continuent de recevoir des manifestes système

Même lorsque Siri et Apple Intelligence étaient désactivés, le téléphone continuait à accéder à : gdmf-ados.apple.com/v2/assets

Les paquets système suivants ont été demandés :

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

Les requêtes transmettaient :

  • le modèle du téléphone ;
  • la plateforme matérielle ;
  • la capacité de la mémoire vive ;
  • la version et le numéro de build d'iOS ;
  • l'identifiant de build ;
  • ID de l'image système ;
  • état de la mise à jour ;
  • état de la restauration ;
  • versions des composants installés ;
  • ID de session ;
  • Nonce ;
  • Audience des ressources.

Les réponses contenaient des manifestes signés :

  • URL de l'archive système ;
  • la version du composant ;
  • la version de compilation ;
  • l'ID de l'archive ;
  • la clé de déchiffrement de l'archive ;
  • somme de contrôle ;
  • taille ;
  • plage de versions iOS compatibles ;
  • règles de mise en cache.

Il n'y a ici ni transmission vocale, ni texte Siri, ni requêtes utilisateur. Il s'agit d'une vérification des mises à jour des modèles système.

Cependant, la désactivation de ces fonctions ne retire pas l'appareil de la gestion des composants concernés : l'iPhone continue de vérifier régulièrement leurs versions et de transmettre à Apple la configuration détaillée du matériel et des logiciels.

Le redémarrage et le mode avion déclenchent une cascade de connexions

Le redémarrage est l’un des événements les plus « bruyants ».

Immédiatement après le démarrage de l’iPhone :

  • il s’enregistre dans « Localiser mon iPhone » avec la raison DeviceRestart;
  • effectue une vérification de son compte Apple ;
  • il vérifie la disponibilité du réseau ;
  • détermine l'adresse IP externe ;
  • télécharge les données de l'App Store ;
  • rétablit la connexion à iCloud ;
  • vérifie MobileAsset ;
  • met à jour les configurations géographiques.

Dans la minute qui a suivi le redémarrage, des dizaines d'accès ont été enregistrés vers :

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

Un comportement similaire a été observé lors de l'activation et de la désactivation du mode avion.

Une fois le réseau rétabli, l’iPhone établissait des connexions avec : gateway.icloud.com

et relançait l’initialisation des services système d’Apple.

Le contenu des échanges avec gateway.icloud.com n'a pas pu être déchiffré, mais le fait même de l'événement réseau et son lien avec l'activation ou la désactivation du mode avion ont pu être reproduits dans le cadre d'une expérience contrôlée.

Les services sécurisés disparaissent lors de la navigation HTTPS

Une partie des services Apple ne fonctionnait systématiquement pas lorsque le trafic HTTPS était actif.

L’expérience a été reproduite :

  • sur cinq iPhone 17e ;
  • pendant deux jours ;
  • après 5 à 10 redémarrages de chaque appareil.

Tant que le trafic HTTPS était en cours de décryptage, les services concernés ne parvenaient pas à établir de connexion opérationnelle.

Dès la désactivation du décryptage, ils reprenaient leur fonctionnement et apparaissaient sous forme de CONNECT.

Ce comportement se répétait et ne constituait pas une défaillance réseau aléatoire.

C’est pourquoi le tableau complet était constitué de deux types de captures :

  1. avec décryptage — pour l'analyse des URL, des en-têtes et des corps de message ;
  2. sans décryptage — pour recenser les services sécurisés refusant de fonctionner sous surveillance.

Une CONNECT ne correspond pas à une seule requête HTTP. De nombreuses opérations peuvent avoir lieu au sein d’un même tunnel. C’est pourquoi ce nombre CONNECT ne peut pas être comparé directement au nombre de requêtes GET et POST déchiffrées.

Le téléphone continue de communiquer avec Apple en mode veille

Au cours d’une longue session en arrière-plan, l’iPhone est resté inactif, sans intervention de l’utilisateur.

Bien que les fonctionnalités d’analyse, de géolocalisation, de Siri et de synchronisation aient été désactivées, l’appareil a continué à communiquer avec l’infrastructure d’Apple toutes les quelques minutes.

Parmi les fréquences les plus régulières :

  • gspXX-ssl-background.ls.apple.com — environ toutes les 30 minutes ;
  • configuration.ls.apple.com — environ toutes les 50 minutes ;
  • iphone-ld.apple.com — environ toutes les 51 minutes ;
  • gateway.icloud.com — par séries ;
  • weatherkit.apple.com — environ toutes les quelques heures ;
  • caldav.icloud.com — environ une fois par heure.

En 8,8 heures, il n’y a pas eu un seul intervalle de « sommeil » complet de plus de 21 minutes.

Conclusion

L'étude n'a révélé aucun rapport de plantage, aucune trace de pile ni aucune archive de diagnostic complète. Il est probable que le commutateur « Analyses de l'iPhone » désactive effectivement ce type de rapports.

Mais il ne désactive pas la télémétrie iOS en tant que système.

Même lorsque les paramètres utilisateur sont désactivés, l’iPhone 17e continue de transmettre à Apple :

  • les identifiants de compte ;
  • l'adresse e-mail du compte Apple ;
  • le DSID et l’ADSID ;
  • le numéro de série ;
  • l'UDID ;
  • les jetons push ;
  • IDS (identifiant de l'appareil) ;
  • état de la batterie ;
  • état de verrouillage ;
  • réinitialisation ;
  • le fait d'un changement de géolocalisation ;
  • la modification de l'état du réseau ;
  • BSSID des points d'accès Wi-Fi environnants ;
  • les coordonnées pour le service météo ;
  • informations sur les appareils connectés ;
  • une empreinte matérielle et logicielle détaillée ;
  • les données de segmentation et d'attribution publicitaires.

Conclusion principale :

Il n'existe pas, sous iOS, de commutateur utilisateur unique permettant de désactiver la transmission automatique de métadonnées à Apple. La désactivation des analyses désactive un mécanisme analytique spécifique, mais les services fonctionnels continuent d’indiquer au serveur de quel appareil il s’agit, à quel compte il est associé, dans quel état il se trouve et ce qui se passe au niveau de ses paramètres système.

Toutes les données décrites sont transmises via des connexions HTTPS chiffrées. Le fournisseur d’accès ou le propriétaire d’un réseau Wi-Fi classique ne les voit pas. Elles sont reçues directement par Apple. Nous ne pouvons pas affirmer que des données auraient pu être transmises à gateway.icloud.com et à d’autres services utilisant le SSL Pinning.