이 실험은 iOS 26.5.2가 설치된 5대의 iPhone 17e에서 진행되었습니다. 모든 기기에서 동일한 현상이 관찰되었습니다. 네트워크 트래픽은 통제된 Wi-Fi 네트워크에서 분석되었습니다. 연구의 주요 결과:

시스템 분석 기능을 비활성화해도 Apple 인프라로 메타데이터가 자동으로 전송되는 것은 중단되지 않습니다. 이는 특정 유형의 진단 보고서를 비활성화할 뿐, ‘내 아이폰 찾기’, ‘Apple 계정’, 위치 서비스, 광고 구성 요소, App Store, MobileAsset 및 시스템 체크인 메커니즘은 중단하지 않습니다.

iPhone이 정확히 무엇을 전송하는가

해독된 요청에서 다음이 발견되었습니다:

  • Apple Account 주소;
  • 계정의 DSID 및 대체 DSID;
  • 광고용 ADSID;
  • 일련번호;
  • 기기의 UDID;
  • APNs 및 푸시 토큰;
  • IDS(Device ID);
  • 휴대폰 모델;
  • iOS 버전 및 빌드;
  • 하드웨어 플랫폼;
  • RAM 용량;
  • 기기 이름;
  • 계정 지역;
  • 언어 및 시간대;
  • 배터리 상태;
  • 충전 상태;
  • 화면 잠금 상태;
  • '내 기기 찾기' 상태;
  • 위치 서비스 상태;
  • 주변 Wi-Fi 액세스 포인트의 BSSID;
  • WeatherKit용 좌표;
  • 설치된 시스템 구성 요소의 버전;
  • 연동된 Apple 기기에 대한 정보.

이는 단일한 ‘분석 보고서’가 아닙니다. 데이터는 Apple의 여러 기능별 서비스에 분산되어 있습니다. 하지만 기술적인 관점에서 보면 이는 자동 텔레메트리입니다. 즉, 휴대폰이 원격 서버에 자신과 그 상태, 주변 환경에 대한 정보를 전송하는 것입니다.

Apple은 위치 정보 기능의 켜짐 및 꺼짐 이벤트를 수신합니다

가장 대표적인 메커니즘은 ‘내 iPhone 찾기’와 관련되어 있습니다.

위치 서비스 상태가 변경될 때마다 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 는 요청의 아주 작은 부분에 불과합니다. 이와 함께 다음 정보가 전송됩니다:

  • Apple 계정의 DSID;
  • 휴대폰의 UDID;
  • 일련번호;
  • 기기 모델;
  • iOS 버전 및 빌드;
  • 휴대폰 이름;
  • APN 토큰;
  • 푸시 토큰 목록;
  • IDS 기기 ID;
  • 배터리 잔량;
  • 충전 상태;
  • 잠금 상태;
  • 지역;
  • 시간대;
  • Apple 인증 헤더.

이는 완전히 식별 가능한 이벤트입니다. 이 이벤트는 계정, 특정 기기 및 해당 기기의 현재 상태와 동시에 연관되어 있습니다.

위치 서비스를 켠 후에는 어떤 일이 발생하나요?

위치 서비스가 꺼져 있을 때는 BSSID를 전송하는 요청이 중단되었습니다. 2시간 30분 동안 주요 Wi-Fi 위치 서비스에 대한 요청은 단 한 건도 없었습니다.

위치 서비스를 켠 직후, iPhone은 다음으로 접속하기 시작했습니다: http://gs-loc.apple.com/clls/wloc

시스템 프로세스 locationd 는 주변 액세스 포인트 목록을 Apple로 전송했습니다.

요청 중 하나에는 19개의 BSSID가 포함되어 있었습니다. 이에 대해 Apple은 주변 지역과 관련된 119개의 Wi-Fi 기록을 반환했습니다.

이 메커니즘은 다음과 같이 작동합니다:

  1. iPhone은 사용 가능한 Wi-Fi 액세스 포인트를 스캔합니다.
  2. 휴대폰은 해당 액세스 포인트의 BSSID(MAC 주소)를 애플에 전송합니다.
  3. 서버는 탐지된 액세스 포인트 및 인근 액세스 포인트에 대한 지리적 정보를 반환합니다.
  4. 휴대폰은 로컬에서 자신의 위치를 계산합니다.

형식상 기기는 ‘나는 이 주소에 있다’는 메시지를 전송하지는 않습니다. 하지만 주변의 여러 BSSID 목록과 요청 시간을 통해 서버는 휴대폰의 위치를 높은 정확도로 파악할 수 있습니다.

이와는 별도로 geod 다음으로 호출됩니다: http://gspXX-ssl.ls.apple.com/wifi_request

이 요청에서는 하나의 BSSID가 전송되는데, 이는 아마도 현재 연결 지점의 식별자이거나 위치 파악 시 사용되는 주요 지점의 식별자일 것입니다.

위치 서비스가 꺼져 있어도 지리 서비스는 계속 작동합니다

위치 서비스를 비활성화하면 주변 BSSID 목록의 로딩은 중단되었지만, iOS의 지리적 스택 자체는 중단되지 않았습니다.

프로세스 geodlocationd 다음 위치로 계속 요청을 보냈습니다:

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 버전;
  • 빌드 번호;
  • 시스템 프로세스 ID;
  • 언어;
  • 지역;
  • Apple Maps 요청 유형;
  • 지리적 구성의 서비스 매개변수.

응답에는 dispatcher.arpc 지역별 데이터와 역지오코딩 블록이 포함되어 있었습니다.

동일한 요청에 대해 서로 다른 서버 노드들은 일본 또는 Apple Account 지역의 정보를 반환했습니다. 이는 사용자의 위치 정보 접근 권한이 비활성화된 상태에서도 지리적 하위 시스템이 계속해서 서버 구성을 수신하고 있음을 보여줍니다.

WeatherKit은 좌표를 URL로 전송합니다

iOS의 날씨 구성 요소는 다음 주소로 요청을 보냈습니다:

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

좌표는 소수점 이하 세 자리까지(약 100미터)의 정확도로 URL 경로에 직접 포함되어 있었습니다.

또한 다음 정보도 함께 전송되었습니다:

  • 시간대;
  • 국가;
  • 기기 언어;
  • iOS 버전;
  • 빌드 번호;
  • 날씨 데이터 세트 목록;
  • 시간 범위;
  • 요청 UUID;
  • Bearer JWT.

JWT는 WeatherKit 인증에 사용되었으며 DSID, UDID 또는 일련번호를 포함하지 않았습니다. 그러나 HTTPS 요청 자체에는 여전히 좌표와 소스 IP 주소가 포함되어 있었습니다.

캡처된 데이터 중 하나에서 Apple 서버는 이러한 요청을 성공적으로 처리하고 다음과 같은 응답을 반환했습니다. HTTP 200.

따라서 WeatherKit으로의 좌표 전송은 단순히 로컬에서 생성된 요청일 뿐만 아니라, 서버 측에서 확인된 통신 과정이기도 합니다.

‘Find My’는 휴대폰의 상태를 전송합니다

‘내 iPhone 찾기’는 위치 서비스 전환 시에만 사용되는 것이 아닙니다.

재부팅 후 iPhone은 다음과 같은 사유를 포함한 동일한 유형의 등록 정보를 전송합니다: cause = DeviceRestart

기기에는 다음 정보가 포함되어 있습니다:

  • 일련번호;
  • UDID;
  • 기기 이름;
  • 모델;
  • iOS 버전;
  • 푸시 토큰;
  • IDS(Device ID);
  • 배터리 잔량;
  • 충전 상태;
  • 충전기가 연결되어 있는지 여부;
  • 화면이 잠겨 있는지;
  • 위치 서비스가 켜져 있는지;
  • 'Find My'가 활성화되어 있는지.

서버는 정확한 재부팅 시간과 기기의 현재 상태를 수신합니다.

이 경우 ‘Find My’는 Apple 계정과 특정 물리적 기기에 연동된 본격적인 운영 텔레메트리 채널 역할을 합니다.

Apple 계정 체크인

재부팅 후 시스템 프로세스가 com.apple.NewDeviceOutreach 이 요청을 전송합니다:
POST sse-ws-p189.apple.com/device/api/v1/checkIn

여기에는 다음 정보가 포함됩니다:

  • Apple 계정의 이메일 주소;
  • 기본 DSID;
  • 대체 DSID;
  • 일련번호;
  • 기기 모델;
  • 휴대폰 이름;
  • 본체 색상;
  • 지역;
  • 스토어프론트;
  • 언어;
  • 시간대;
  • 보증 해시;
  • 로컬 Apple 기기 목록;
  • 연동된 Apple Watch 정보;
  • Apple Media Services 서비스 식별자;
  • 하드웨어 인증.

서버는 결과와 SUCCESS 및 다음 체크인 시간을 반환합니다.

이는 개인 데이터가 가장 많이 포함된 요청 중 하나입니다. 이 요청은 계정, 물리적 기기, 보증 정보 및 연결된 기기에 대한 정보를 통합합니다.

개인화 기능이 비활성화된 상태에서도 광고 인프라는 작동합니다

개인화 광고가 비활성화된 상태에서도 다음 시스템 프로세스는 계속 작동했습니다:

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;
  • 로케일;
  • 시간대;
  • 기기 인증;
  • 서버 쿠키;
  • 광고 프로필의 서비스 플래그.

어트리뷰션 엔드포인트는 다음 정보를 수신했습니다:

  • App Store 내 앱 식별자;
  • 번들 ID;
  • 어트리뷰션 키;
  • iPhone 모델;
  • iOS 버전;
  • 빌드;
  • 스토어프론트;
  • 타임스탬프;
  • Apple 서명.

본문에는 다음과 같은 값이 포함되어 있었습니다: attribution = false

이는 긍정적인 광고 어트리뷰션이 설정되지 않았음을 의미합니다. 하지만 어트리뷰션 및 광고 세분화 메커니즘 자체는 계속 작동했습니다.

개인 맞춤 광고를 비활성화해도 광고 스택은 꺼지지 않습니다. 이는 데이터 사용 규칙을 변경할 뿐, 네트워크 간 데이터 교환을 중단하지는 않습니다.

App Store는 다음을 통해 메트릭 구성을 불러옵니다. bag.itunes.apple.com/bag.xml

iPhone은 App Store 및 미디어 서비스의 구성을 수신합니다.

요청에서 휴대폰은 다음 정보를 전송합니다:

  • 모델;
  • 기기 등급;
  • iOS 버전 및 빌드;
  • 스토어프론트;
  • 언어;
  • 시간대;
  • 시스템 프로세스 ID.

응답에는 다음 주소가 포함됩니다:

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

또한 서버는 다음을 전송합니다:

  • usage-메트릭 주제;
  • performance 메트릭 주제;
  • 전송 간격;
  • 샘플링 매개변수;
  • 순환하는 클라이언트 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

요청에는 다음 정보가 포함되었습니다:

  • 휴대폰 모델;
  • 하드웨어 플랫폼;
  • RAM 용량;
  • iOS 버전 및 빌드;
  • 빌드 ID;
  • 시스템 이미지 ID;
  • 업데이트 상태;
  • 롤백 상태;
  • 설치된 구성 요소의 버전;
  • 세션 ID;
  • 논스;
  • 자산 대상.

응답에는 서명된 매니페스트가 포함되어 있었습니다:

  • 시스템 아카이브 URL;
  • 컴포넌트 버전;
  • 빌드;
  • 아카이브 ID;
  • 아카이브 복호화 키;
  • 다이제스트;
  • 크기;
  • 호환되는 iOS 버전 범위;
  • 캐싱 규칙.

음성, 텍스트, Siri 또는 사용자 요청 전송은 여기에 포함되지 않습니다. 이는 시스템 구성 요소 업데이트 확인입니다.

그러나 기능을 비활성화하더라도 해당 구성 요소에 대한 지원이 중단되는 것은 아닙니다. iPhone은 계속해서 해당 구성 요소의 버전을 정기적으로 확인하고 Apple에 상세한 하드웨어 및 소프트웨어 구성을 전송합니다.

재시작 및 비행기 모드는 일련의 연결 반응을 유발합니다

재시작은 가장 많은 활동을 유발하는 이벤트 중 하나입니다.

iPhone이 시작되자마자:

  • 'Find My'에 다음 사유로 등록되며 DeviceRestart;
  • Apple 계정 체크인을 수행하고;
  • 네트워크 연결 상태를 확인합니다;
  • 외부 IP를 확인합니다;
  • App Store 캐시를 불러오고;
  • iCloud와의 연결을 복원합니다;
  • MobileAsset을 확인합니다;
  • 지리적 설정을 업데이트합니다.

재시작 후 1분 동안 다음 항목에 대한 수십 건의 요청이 기록되었습니다:

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를 열람할 때 보안 서비스가 사라집니다

HTTPS 트래픽을 열람하는 동안 일부 Apple 서비스는 지속적으로 작동하지 않았습니다.

실험은 다음과 같이 반복되었습니다:

  • iPhone 17e 5대에서;
  • 이틀 동안;
  • 각 기기를 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분보다 긴 완전한 ‘수면’ 구간은 단 한 번도 없었습니다.

결론

조사 결과 명백한 크래시 리포트, 스택 트레이스 또는 전체 진단 아카이브는 발견되지 않았습니다. 아마도 ‘iPhone 분석’ 스위치가 실제로 바로 이 유형의 보고 기능을 비활성화하는 것으로 보입니다.

하지만 iOS 텔레메트리 자체는 비활성화하지 않습니다.

사용자 설정이 비활성화된 상태에서도 iPhone 17e는 Apple에 다음 정보를 계속 전송합니다:

  • 계정 식별자;
  • Apple 계정 이메일;
  • DSID 및 ADSID;
  • 일련 번호;
  • UDID;
  • 푸시 토큰;
  • IDS(기기 ID);
  • 배터리 상태;
  • 잠금 상태;
  • 재시작 여부;
  • 위치 정보 전환 여부;
  • 네트워크 상태 변경 여부;
  • 주변 Wi-Fi 액세스 포인트의 BSSID;
  • 기상 서비스를 위한 좌표;
  • 연결된 기기에 대한 정보;
  • 상세한 하드웨어 및 소프트웨어 지문;
  • 광고 세분화 및 어트리뷰션 데이터.

핵심 결론:

iOS에는 Apple로 메타데이터가 자동으로 전송되는 것을 중지하는 통합된 사용자 제어 스위치가 없습니다. 분석 기능을 비활성화하면 개별 분석 메커니즘만 중지될 뿐, 기능성 서비스는 계속해서 서버에 해당 기기의 정보, 연결된 계정, 현재 상태 및 시스템 설정 변경 사항을 보고합니다.

설명된 모든 데이터는 암호화된 HTTPS 연결을 통해 전송됩니다. 인터넷 서비스 제공업체나 일반 Wi-Fi 네트워크 소유자는 이 데이터를 볼 수 없습니다. 이 데이터는 애플이 직접 수신합니다. SSL Pinning을 사용하는 gateway.icloud.com 및 SSL Pinning을 사용하는 다른 서비스로 전송되었을 수 있다고 단정할 수는 없습니다.