macOS 内部的 EntityTagging_Family.mlmodelc 文件中确实存在名为 photosPersonPosteriorProbabilityGivenSaturdayNight 的特征变量名。这意味着“两人在周六晚间照片中共同出现的频率”是用于判断“是否属于家人”的 144 个数值信号之一。安全研究团队 8rank.ai 的 Dario Pasquini 和 Michał Bazyli 分析了该文件,发现 Apple 在不向服务器传输数据的情况下,仅通过设备内的机器学习来估计家庭关系,并发布了允许用户直接查看结果的开源工具 iKnow 1。

自 macOS 13(2022年)起,所有 Mac 设备均内置了两个守护进程(在后台自动运行的系统程序):knowledgeconstructiond 和 intelligenceplatformd。这些守护进程通过比对联系人、照片中的面部、日程和消息对象等,在设备内部构建个人知识图谱(网络)。8rank.ai 团队分析 macOS 26.6.2 版本后发现,确实存储了结合用户与周围人物之间的关系、位置和行为习惯模式的推理数据 1, 2。

相同姓氏、地址、照片频率:由 144 个信号构成的分类器

用于估计家庭或朋友关系的分类器涉及两个文件,分别是 EntityTagging_Family.mlmodelc 和 EntityTagging_FamilyAndFriends.mlmodelc。8rank.ai 团队确认这些文件是二进制 XGBoost 分类器(一种接收数字输入并计算特定关系概率的机器学习模型)1, 2。这两个模型接收具有固定顺序的 144 个数值特征,这些特征分为身份、通信和照片三个组别。

与身份相关的 20 个信号包括:相同姓氏、家庭住址和工作地址、电子邮件域名、生日、别名、是否被标记为收藏夹或 VIP、是否参与 iCloud 家庭共享、年龄差等。与通信相关的 40 个信号衡量的是短期和长期联系频率、星期几和时间段、联系地点、工作日和周末的条件频率以及主要联系手段等。此时,消息内容本身不用于特征计算。与照片相关的 84 个信号则按星期几、时间段和地点细分,计算在同一照片帧中共同出现的频率 1。

分类器计算的分数并未存储在图谱本体中,而是保存在名为 entityTagging.db 的独立文件中。每个人物对应一行记录,分为母亲、父亲、兄弟、姐妹、儿子、女儿、伴侣、同事、朋友等 17 个关系列,并每日重新计算 1, 2。不过,8rank.ai 团队确认其模型仅连接到 17 列中的 2 列;对于其余 15 列如何填充,以及这些概率如何转换为图谱置信度,本次分析未能追踪到具体路径 1, 2。

在 8rank.ai 用于分析的 Mac 上的输出:仅“母亲”列达到最高分数

虽然提到“家庭估计数据”容易让人联想到完整的家庭名册,但实际分类器输出的更接近于未确定的概率。8rank.ai 团队公开了他们在用于分析的 Mac 上直接读取到的分数表结果。分析显示,仅在“母亲”列达到了最高分数,而对于其他部分人物,兄弟、姐妹、子女等多个家庭关系列同时被赋予了较低的分数。分数表中记录的值表现为 0.125、0.25、0.5、0.96 等少数离散值,且大多数人物并未偏离默认值。对于校友或未确认条目,甚至没有分配分数 1。

这种输出形式表明,这些数据并非已确定的家庭信息,而是当多个弱信号叠加时形成分数的未完成估计结果。由于本次分析未能确认分类器分数如何转化为图谱置信度,因此很难将分数表中的值解读为确定性判断结果。

人物识别过程与数据存储位置

人物识别过程与数据存储位置

要推断家庭关系,前提是先进行“这张脸属于这个人”的人物识别。在图谱存储库中,观察到了将人物实体与面部聚类连接的谓词 nm_hasVisualIdentifier,以及以概率判断姓名与面部同一性的 nm_entityAliasRelationship 结构。2026年5月,公布此存储结构的软件工程师 Nic Lydon 提取并展示了别名关系与 nm_confirmationConfidence(确认置信度)分数一同记录的事实 3。这意味着即使照片中的面部与用户指定的姓名不匹配,系统也会尝试建立连接。

相关数据位于用户 Mac 内部的 ~/Library/IntelligencePlatform 路径下。该文件夹内以明文形式(无需额外加密即可识别其结构)存储了 51 个 SQLite 数据库文件,该位置受 TCC(完整磁盘访问权限保护功能)保护 1, 2。

需要准确区分通信记录的范围。存储在图谱中的通信元数据包括“与谁”、“何时”、“通过哪个应用”、“发送还是接收”等信息。Apple 并未将消息正文本身包含在此元数据表中 1, 2。位置移动、屏幕锁定、Wi-Fi 连接状态等信号也存在于相同的存储结构中,但即便架构(数据设计结构)中声明了相应条目,也不意味着所有类别的数据都在被实际收集。

使用 iKnow 工具直接查询关系分数

为了让用户能够直接查看设备上的数据,8rank.ai 团队发布了开源工具 iKnow。这是一个仅使用 Python 标准库制作的本地 Web 仪表盘,运行时会绑定到 127.0.0.1(本机)并以只读方式查询数据库。它不写入数据也不保留日志,即使在网络断开的环境下也能运行,因此屏幕上显示的值不会传输到设备外部 1, 2。

iKnow 界面提供的主要信息如下:

界面显示内容特点及注意事项
亲属关系分数表17 个关系列及上位类别(母亲+父亲→父母等)伴侣分数未包含在上位类别中,需单独确认
社会关系图谱人物、雇主、群组聊天、共享日程的连接示例屏幕中的分数为合成数据
照片面部索引由同一张照片出现形成的面部聚类网络无需联系人,仅凭照片共同出现即可形成网络
年度通信记录收发和通话次数以及按星期几的时间分布不包含消息正文
撤回记录已删除事实的置信度和来源可确认数据在删除后的残留状态

即使删除了联系人,估计结果可能会暂时保留。8rank.ai 团队确认,被删除的连接会移动到 expired_stable_graph 表中并残留一段时间。虽然看似在约 48 小时后被移除,但在用于分析的 Mac 上仍能读取到更久之前的记录,因此确切的保留期限尚未确认。例如,通过日程邀请相识的两个人物,在图谱中移除后的第二天,其关系分数表中仍保留有记录 1。

macOS 系统设置界面并未提供允许用户查看或修改关系分数的官方用户界面 2。由于缺乏专门的官方查询手段和纠正错误推断的方法,使用 iKnow 等工具直接查看分数表状态是一条有用的途径。在升级到 macOS 27(27.0.1)的环境中,观察到从联系人、日程、Siri Suggestions、家庭共享和应用列表生成的大部分行在暂时撤回后,会在接下来的一天内重新构建 2。

基于 144 个数值信号每日计算得出的家庭关系分数,存储在设备内的 SQLite 文件中。在 8rank.ai 团队的用于分析的 Mac 上,仅“母亲”列达到最高分数,其余部分则是低分数分散在多个列中,这有力地表明这是估计值而非确定的数据库。运行 iKnow 后,用户可以以只读方式打开并查看其 Mac 上相同的分数表。

参考资料

  1. ↩
  2. ↩
  3. ↩