Експеримент проводився на п’яти iPhone 17e під управлінням iOS 26.5.2. Таке ж явище спостерігалося на всіх пристроях. Мережевий трафік аналізувався в контрольованій мережі Wi-Fi. Головний результат дослідження:

Вимкнення системної аналітики не припиняє автоматичну передачу метаданих до інфраструктури Apple. Воно вимикає окремий клас діагностичних звітів, але не зупиняє Find My, Apple Account, геосервіси, рекламні компоненти, App Store, MobileAsset та системні механізми check-in.

Що саме передає iPhone

У розшифрованих запитах виявлено:

  • адреса Apple Account;
  • DSID та альтернативний DSID облікового запису;
  • рекламний ADSID;
  • серійний номер;
  • UDID пристрою;
  • APNs- та push-токен;
  • IDS (ідентифікатор пристрою);
  • модель телефону;
  • версія та збірка iOS;
  • апаратна платформа;
  • обсяг оперативної пам'яті;
  • назва пристрою;
  • регіон облікового запису;
  • мова та часовий пояс;
  • стан акумулятора;
  • стан заряджання;
  • стан блокування екрана;
  • стан Find My;
  • стан служб геолокації;
  • BSSID навколишніх точок Wi-Fi;
  • координати для WeatherKit;
  • версії встановлених системних компонентів;
  • відомості про підключені пристрої Apple.

Це не єдиний «аналітичний звіт». Дані розподілені між кількома функціональними сервісами Apple. Але з технічної точки зору йдеться про автоматичну телеметрію: телефон передає віддаленим серверам інформацію про себе, свій стан та оточення.

Apple отримує повідомлення про увімкнення та вимкнення геолокації

Найбільш показовий механізм пов’язаний із Find My.

При кожній зміні стану служб геолокації iPhone надсилає запит:

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

Після вимкнення геолокації в тілі HTTP-запиту містилося:

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

При подальшому увімкненні:

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

Обидва запити були прийняті сервером Apple з відповіддю: HTTP 204 No Content

Таким чином, Apple отримує не лише поточний стан геолокації. Сервер отримує окрему подію, яка повідомляє, що користувач змінив відповідне налаштування.

Сам прапорець true або false є лише невеликою частиною запиту. Разом із ним передаються:

  • DSID облікового запису Apple;
  • UDID телефону;
  • серійний номер;
  • модель пристрою;
  • версія та збірка iOS;
  • назва телефону;
  • APNs-токен;
  • список push-токенів;
  • IDS Device ID;
  • заряд акумулятора;
  • стан заряджання;
  • стан блокування;
  • локаль;
  • часовий пояс;
  • атестаційні заголовки Apple.

Це повністю ідентифікована подія. Вона пов’язана одночасно з обліковим записом, конкретним пристроєм та його поточним станом.

Що відбувається після увімкнення геолокації?

При вимкненій геолокації запити з вивантаженням BSSID припинялися. Протягом двох з половиною годин не було жодного звернення до основного Wi-Fi-сервісу позиціонування.

Відразу після увімкнення геолокації iPhone почав звертатися до: http://gs-loc.apple.com/clls/wloc

Системний процес locationd надсилав Apple списки навколишніх точок доступу.

В одному із запитів передавалося 19 BSSID. У відповідь Apple повернула 119 Wi-Fi-записів, що стосуються навколишньої території.

Механізм працює наступним чином:

  1. iPhone сканує доступні Wi-Fi-точки.
  2. Телефон надсилає Apple їхні BSSID — MAC-адреси точок доступу.
  3. Сервер повертає географічні дані щодо знайдених і сусідніх точок.
  4. Телефон обчислює своє місцезнаходження локально.

Формально пристрій не надсилає повідомлення «я перебуваю за цією адресою». Але список із кількох навколишніх BSSID разом із часом запиту дозволяє серверу визначити район перебування телефону з високою точністю.

Окремо процес geod звертається до: http://gspXX-ssl.ls.apple.com/wifi_request

У цьому запиті передається один BSSID — ймовірно, ідентифікатор поточної точки підключення або основної точки, що використовується під час позиціонування.

Геосервіси продовжують працювати при вимкненій геолокації

Вимкнення служб геолокації припиняло завантаження списків навколишніх BSSID, але не зупиняло сам географічний стек iOS.

Процеси geod та locationd продовжували звертатися до:

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

У запитах передавалися:

  • модель iPhone;
  • версія iOS;
  • номер збірки;
  • ідентифікатор системного процесу;
  • мова;
  • регіон;
  • тип запиту Apple Maps;
  • службові параметри географічної конфігурації.

У відповідях dispatcher.arpc були присутні регіональні дані та блоки зворотного геокодування.

На однакові запити різні серверні вузли повертали відомості для Японії або регіону Apple Account. Це свідчить про те, що географічна підсистема продовжує отримувати серверну конфігурацію навіть при вимкненому доступі користувача до геолокації.

WeatherKit передає координати в URL

Погодний компонент iOS звертався до:

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

Координати містилися безпосередньо в URL-адресі з точністю до трьох знаків після коми — приблизно до ста метрів.

Додатково передавалися:

  • часовий пояс;
  • країна;
  • мови пристрою;
  • версія iOS;
  • номер збірки;
  • перелік наборів даних про погоду;
  • часовий діапазон;
  • UUID запиту;
  • Bearer JWT.

JWT використовувався для авторизації WeatherKit і не містив DSID, UDID або серійного номера. Однак сам HTTPS-запит все одно містив координати та IP-адресу джерела.

В одному з перехоплень сервер Apple успішно обробив такий запит і повернув HTTP 200.

Отже, передача координат у WeatherKit — це не лише локально сформований запит, а й підтверджений серверний обмін.

Find My передає стан телефону

Find My використовується не тільки під час перемикання геолокації.

Після перезавантаження iPhone надсилає той самий тип реєстрації з причиною: cause = DeviceRestart

У теле знаходяться:

  • серійний номер;
  • UDID;
  • назва пристрою;
  • модель;
  • версія iOS;
  • push-токен;
  • IDS (ідентифікатор пристрою);
  • заряд акумулятора;
  • стан заряджання;
  • чи підключено зарядний пристрій;
  • чи заблоковано екран;
  • чи увімкнено геолокацію;
  • чи активна функція Find My.

Сервер отримує точний час перезавантаження та поточний стан пристрою.

У цьому випадку Find My виступає повноцінним каналом експлуатаційної телеметрії, прив’язаним до Apple Account та конкретного фізичного пристрою.

Apple Account check-in

Після перезавантаження системний процес com.apple.NewDeviceOutreach надсилає запит:
POST sse-ws-p189.apple.com/device/api/v1/checkIn

У ньому містяться:

  • адреса електронної пошти Apple Account;
  • основний DSID;
  • альтернативний DSID;
  • серійний номер;
  • модель пристрою;
  • назва телефону;
  • колір корпусу;
  • регіон;
  • магазин;
  • мова;
  • часовий пояс;
  • хеш гарантії;
  • список локальних пристроїв Apple;
  • відомості про пов’язані Apple Watch;
  • службові ідентифікатори Apple Media Services;
  • апаратна атестація.

Сервер повертає результат SUCCESS та час наступного check-in.

Це один із запитів, що містить найбільше персональних даних. Він об’єднує обліковий запис, фізичний пристрій, гарантійні дані та інформацію про пов’язані пристрої.

Рекламна інфраструктура працює при вимкненій персоналізації

При вимкненій персоналізованій рекламі продовжували працювати системні процеси:

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

Вони зверталися до:

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

У запитах рекламної сегментації передавалися:

  • DSID;
  • ADSID;
  • storefront;
  • локаль;
  • часовий пояс;
  • machine-attestation;
  • серверні файли cookie;
  • службові прапорці рекламного профілю.

Endpoint атрибуції отримував:

  • ідентифікатор додатка в App Store;
  • bundle ID;
  • ключ атрибуції;
  • модель iPhone;
  • версію iOS;
  • збірку;
  • storefront;
  • час створення;
  • підпис Apple.

У тілі містилося таке значення: attribution = false

Це означає, що позитивна рекламна атрибуція не була встановлена. Але сам механізм атрибуції та рекламної сегментації продовжував працювати.

Вимкнення персоналізованої реклами не вимикає рекламний стек. Воно змінює правила використання даних, але не припиняє мережевий обмін.

App Store завантажує конфігурацію метрик через bag.itunes.apple.com/bag.xml

iPhone отримує конфігурацію App Store та медіасервісів.

У запитах телефон передає:

  • модель;
  • клас пристрою;
  • версію та збірку iOS;
  • storefront;
  • мову;
  • часовий пояс;
  • ідентифікатор системного процесу.

У відповідях містяться адреси:

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

Також сервер передає:

  • теми usage-метрик;
  • теми performance-метрик;
  • інтервали відправки;
  • параметри вибірки;
  • змінні client ID;
  • правила обмеження подій та полів.

З'єднання з xp.apple.com були зафіксовані, але їхній вміст залишався зашифрованим. Тому встановити точний склад подій, надісланих туди, за наявними даними неможливо.

Можна стверджувати лише наступне: конвеєр метрик був налаштований, а iPhone встановлював з’єднання з сервером прийому звітності.

Siri та Apple Intelligence продовжують отримувати системні маніфести

Навіть при вимкнених Siri та Apple Intelligence телефон продовжував звертатися до: gdmf-ados.apple.com/v2/assets

Запитувалися системні пакети:

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

У запитах передавалися:

  • модель телефону;
  • апаратна платформа;
  • обсяг оперативної пам'яті;
  • версія та збірка iOS;
  • Build ID;
  • System Image ID;
  • стан оновлення;
  • стан rollback;
  • версії встановлених компонентів;
  • Ідентифікатор сеансу;
  • Nonce;
  • Asset Audience.

Відповіді містили підписані маніфести:

  • URL системного архіву;
  • версію компонента;
  • build;
  • ID архіву;
  • ключ розшифрування архіву;
  • digest;
  • розмір;
  • діапазон сумісних версій iOS;
  • правила кешування.

Передачі голосу, тексту Siri або запитів користувачів тут немає. Це перевірка оновлень системних моделей.

Однак відключення функцій не знімає пристрій з обслуговування відповідних компонентів: iPhone продовжує регулярно перевіряти їхні версії та передавати Apple детальну апаратно-програмну конфігурацію.

Перезавантаження та авіарежим запускають каскад з’єднань

Перезавантаження є однією з найбільш «гучних» подій.

Відразу після запуску iPhone:

  • реєструється в Find My із зазначенням причини DeviceRestart;
  • виконує Apple Account check-in;
  • перевіряє доступність мережі;
  • визначає зовнішню IP-адресу;
  • завантажує App Store bags;
  • відновлює з'єднання з iCloud;
  • перевіряє MobileAsset;
  • оновлює географічні конфігурації.

Протягом однієї хвилини після перезавантаження фіксувалися десятки звернень до:

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

Аналогічна поведінка спостерігалася під час увімкнення та вимкнення авіарежиму.

Після повернення до мережі iPhone встановлював з’єднання з: gateway.icloud.com

та запускав повторну ініціалізацію системних сервісів Apple.

Вміст обміну з gateway.icloud.com було недоступним для розшифрування, але сам факт мережевої події та її зв’язок із перемиканням режиму «у польоті» відтворювалися в контрольованому експерименті.

Захищені сервіси зникають під час перегляду HTTPS

Частина сервісів Apple стабільно не працювала під час активного перегляду HTTPS-трафіку.

Експеримент повторювався:

  • на п’яти iPhone 17e;
  • протягом двох днів;
  • після 5–10 перезавантажень кожного пристрою.

Поки HTTPS-трафік розшифровувався, відповідні сервіси не встановлювали робочі з’єднання.

Одразу після вимкнення розшифрування вони відновлювали роботу і ставали видимими як непрозорі CONNECT-з'єднання.

Така поведінка повторювалася і не була випадковим мережевим збоєм.

Тому повна картина складалася з двох типів перехоплення:

  1. з розшифруванням — для аналізу URL, заголовків і тіл;
  2. без розшифрування — для фіксації захищених сервісів, які відмовляються працювати під наглядом.

Один CONNECT не дорівнює одному HTTP-запиту. Усередині одного тунелю може відбуватися безліч операцій. Тому кількість CONNECT не можна безпосередньо порівнювати з кількістю розшифрованих GET і POST.

Телефон продовжує звертатися до Apple у режимі простою

Під час тривалої фонової сесії iPhone перебував у стані бездіяльності користувача.

Незважаючи на вимкнені аналітику, геолокацію, Siri та синхронізацію, пристрій продовжував звертатися до інфраструктури Apple кожні кілька хвилин.

Серед найбільш регулярних звернень:

  • gspXX-ssl-background.ls.apple.com — приблизно раз на 30 хвилин;
  • configuration.ls.apple.com — приблизно раз на 50 хвилин;
  • iphone-ld.apple.com — приблизно раз на 51 хвилину;
  • gateway.icloud.com — серіями;
  • weatherkit.apple.com — приблизно раз на кілька годин;
  • caldav.icloud.com — приблизно раз на годину.

За 8,8 години не було жодного повністю «сплячого» інтервалу, тривалість якого перевищувала 21 хвилину.

Висновок

Дослідження не виявило явних crash reports, stack traces або повних діагностичних архівів. Ймовірно, перемикач «Аналітика iPhone» дійсно вимикає саме цей клас звітності.

Але він не вимикає телеметрію iOS як систему.

При вимкнених налаштуваннях користувача iPhone 17e продовжує передавати Apple:

  • ідентифікатори облікового запису;
  • адресу електронної пошти Apple Account;
  • DSID та ADSID;
  • серійний номер;
  • UDID;
  • push-токен;
  • IDS (ідентифікатор пристрою);
  • стан акумулятора;
  • стан блокування;
  • факт перезавантаження;
  • факт перемикання геолокації;
  • факт зміни стану мережі;
  • BSSID навколишніх Wi-Fi-точок;
  • координати для погодного сервісу;
  • відомості про підключені пристрої;
  • детальний апаратно-програмний відбиток;
  • дані рекламної сегментації та атрибуції.

Ключовий висновок:

В iOS відсутній єдиний користувацький перемикач, який припиняє автоматичну передачу метаданих до Apple. Вимкнення аналітики відключає окремий аналітичний механізм, але функціональні сервіси продовжують повідомляти серверу, що це за пристрій, до якого облікового запису він прив’язаний, у якому стані перебуває та що відбувається з його системними налаштуваннями.

Усі описані дані передаються через зашифровані HTTPS-з'єднання. Провайдер або власник звичайної Wi-Fi-мережі їх не бачить. Їх отримує безпосередньо Apple. Ми не можемо стверджувати, що ці дані могли бути передані gateway.icloud.com та іншим сервісам, що використовують SSL Pinning, ми не можемо.