该实验在五部运行 iOS 26.5.2 系统的 iPhone 17e 上进行。所有设备均出现了相同的行为。网络流量是在受控的 Wi-Fi 网络中进行分析的。研究的主要结果：

即使关闭系统分析功能，也不会停止向苹果基础设施自动传输元数据。 此操作仅会停用特定类别的诊断报告，但不会停止“查找我的 iPhone”、Apple 账户、地理位置服务、广告组件、App Store、MobileAsset 以及系统级签到机制。

iPhone具体传输了什么

在解密后的请求中发现了以下内容：

  • Apple 账户地址；
  • 账户的 DSID 和备用 DSID；
  • 广告用 ADSID；
  • 序列号；
  • 设备UDID；
  • APNs 和推送令牌；
  • IDS 设备 ID；
  • 手机型号；
  • iOS 版本和构建号；
  • 硬件平台；
  • 运行内存容量；
  • 设备名称；
  • 账户所在地区；
  • 语言和时区；
  • 电池状态；
  • 充电状态；
  • 屏幕锁定状态；
  • “查找我的”状态；
  • 位置服务状态；
  • 周围 Wi-Fi 接入点的 BSSID；
  • WeatherKit所需的坐标；
  • 已安装系统组件的版本；
  • 已连接的 Apple 设备信息。

这并非一份统一的“分析报告”。这些数据分散在Apple的多个功能服务中。但从技术角度来看，这属于自动遥测：手机会向远程服务器传输关于自身、其状态及周围环境的信息。

Apple会接收地理位置功能的开启和关闭事件

最具代表性的机制与“查找我的”功能相关。

每当定位服务状态发生变化时，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 版本和构建号；
  • 手机名称；
  • APNs令牌；
  • 推送令牌列表；
  • IDS 设备 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. 手机将这些BSSID（即接入点的MAC地址）发送给Apple。
  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 账户所在地区的资料。这表明，即使用户已关闭地理位置访问权限，地理子系统仍会继续接收服务器配置。

WeatherKit 将坐标传递至 URL

iOS的天气组件调用了：

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

坐标直接包含在 URL 路径中，精度达到小数点后三位——约 100 米。

此外还传输了：

  • 时区；
  • 国家；
  • 设备语言；
  • iOS 版本；
  • 构建号；
  • 天气数据集列表；
  • 时间范围；
  • 请求 UUID；
  • Bearer JWT。

该 JWT 用于 WeatherKit 的授权，其中不包含 DSID、UDID 或序列号。然而，HTTPS 请求本身仍包含坐标和源 IP 地址。

在其中一次抓包中，Apple服务器成功处理了此类请求并返回了 HTTP 200.

因此，向 WeatherKit 传输坐标不仅涉及本地生成的请求，还包含经过服务器端验证的数据交换。

“查找我的”会传输手机的状态

“查找我的 iPhone”不仅在切换地理位置时会被使用。

iPhone 重启后会发送相同类型的注册请求，并附带原因： cause = DeviceRestart

设备中包含：

  • 序列号；
  • UDID；
  • 设备名称；
  • 机型；
  • iOS 版本；
  • 推送令牌；
  • IDS 设备 ID；
  • 电池电量；
  • 充电状态；
  • 是否连接了充电器；
  • 屏幕是否锁定；
  • 地理位置服务是否开启；
  • “查找我的”功能是否处于激活状态。

服务器会获取设备重启的确切时间及其当前状态。

在此情况下，“查找我的”充当了一个完整的运行状态遥测通道，该通道与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;
  • 地区；
  • 时区；
  • 设备认证；
  • 服务器端Cookie；
  • 广告配置文件的系统标志。

归因端点获取了：

  • App Store 中的应用标识符；
  • Bundle ID；
  • 归因密钥；
  • iPhone 机型；
  • iOS 版本；
  • 构建版本；
  • 应用商店；
  • 时间戳；
  • 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-metric主题；
  • 性能指标主题；
  • 发送间隔；
  • 采样参数；
  • 轮询的客户端 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；
  • 系统映像 ID；
  • 更新状态；
  • 回滚状态；
  • 已安装组件的版本；
  • 会话 ID；
  • 非重复码；
  • 资源受众。

响应中包含已签名的清单：

  • 系统存档的URL；
  • 组件版本；
  • 构建版本；
  • 归档ID；
  • 归档解密密钥；
  • 摘要；
  • 大小；
  • 兼容的 iOS 版本范围；
  • 缓存规则。

这里不包含语音、Siri文本或用户请求的传输。这是对系统组件更新的检查。

然而，即使禁用这些功能，设备仍会继续接受相关组件的服务：iPhone 仍会定期检查这些组件的版本，并向 Apple 传输详细的软硬件配置信息。

重启和飞行模式会触发一系列连接操作

重启是系统中最“喧闹”的事件之一。

iPhone启动后立即：

  • 会向“查找我的 iPhone”注册，并以 DeviceRestart;
  • 执行 Apple 账户签到；
  • 检查网络可用性；
  • 确定外部IP地址；
  • 下载 App Store 数据包；
  • 恢复与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时受保护的服务会消失

在浏览HTTPS流量时，部分Apple服务会持续无法正常运行。

该实验在

  • 在五部 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分钟。

结论

研究未发现明显的崩溃报告、堆栈跟踪或完整的诊断日志。很可能，“iPhone 分析”开关确实禁用了这一类报告。

但它并未关闭iOS作为系统的遥测功能。

即使用户设置已关闭，iPhone 17e仍会向Apple传输：

  • 账户标识符；
  • Apple 账户邮箱；
  • DSID 和 ADSID；
  • 序列号；
  • UDID；
  • 推送令牌；
  • 设备 ID（IDS）；
  • 电池状态；
  • 锁定状态；
  • 重启状态；
  • 地理位置切换状态；
  • 网络状态变更情况；
  • 周围Wi-Fi接入点的BSSID；
  • 用于天气服务的坐标；
  • 已连接设备的信息；
  • 详细的软硬件指纹；
  • 广告受众细分与归因数据。

关键结论：

iOS中不存在一个统一的用户开关，能够停止向Apple自动传输元数据。 关闭分析功能仅会停用单独的分析机制，但功能性服务仍会持续向服务器报告：该设备属于哪种类型、绑定到哪个账户、当前处于何种状态，以及其系统设置发生了哪些变化。

上述所有数据均通过加密的 HTTPS 连接传输。普通 Wi-Fi 网络的提供商或所有者无法看到这些数据。这些数据直接由 Apple 接收。至于是否可能被传输至 gateway.icloud.com 及其他使用SSL Pinning的服务，我们无法予以证实。