Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
在今年的全球开发者大会（WWDC）上，Apple 曾宣布将在 iOS 15 中增加一项「App 隐私报告」功能。通过该功能，用户能够「看到在过去七天里每个 app 获取地址、照片、相机、麦克风和通讯录数据的次数」，并可以「可以查看与 app 通信的所有第三方域名，借此了解他们的数据被共享给了谁。」
遗憾的是，在目前版本的 iOS 15 中，「App 隐私报告」并没有完全做完，Apple 当初承诺的专用界面尚未出现。尽管该功能有了一定雏形，底层的记录机制已经做好，但还是需要手动开启、且没有直观的查询方式。因此，很多用户完全不知道这个功能的存在。
但一些有心的用户已经借助这一功能对常用 App 进行了观察，并发现不少 app 的确存在频繁、非必要地读写用户信息的行为；其中具有代表性的就是微信在后台读取用户相册的情况（一个较为完整的梳理可见 用户 Hackl0us 在知乎的回答）。对此，微信的反应整体还算快速，在 10 月 11 日发布的新版似乎修复了这个问题。
然而，并不是每个受到质疑的开发商都做出了积极的回应。
例如，美团也被用户通过「App 隐私报告」功能发现存在每 5 分钟获取一次用户定位的行为。根据 IT 之家的报道，美团工程师的回应是：「之所以出现这种情况，是因为这类软件 [编注：指用于辅助分析系统隐私记录日志的第三方 app「隐私洞见」] 在单方面读取系统操作日志后，进行了选择性展示，经测试，在相关权限开启且 App 后台仍处于活跃状态时，大部分主流 App 均会被该软件检测出频繁读取用户信息，且监测结果高度相似。」
报道称，该工程师还表示，「并未对上述读取 iOS 15 系统日志的软件进行安全性和保密性测试，建议大家谨慎下载。」
这里，我们无意讨论美团的回应是否合理，也暂且不纠结这种第三方辅助 app 是否有「隐私泄漏风险」；但是这段略显傲慢的回复仍然透露出一个信息：大部分主流 App 均会被 iOS 的「隐私报告」测出频繁读取用户信息，且监测结果高度相似。
虽然这句话很符合我们对于主流 App 的认知，不过没有调查就没有发言权，我们不妨试试手动分析 iOS 系统日志，顺便也验证一番主流App对于用户信息频繁的读取，是不是由第三方 App「选择性展示」造成的假象。
（注：在本次分析中，笔者使用了自己熟悉的 R 语言，并加载了 ndjson 以及 tidyverse 包进行分析。有相关专业能力的读者也可以选择其他自己熟悉的分析方式。）
如上所述，「隐私报告」功能在 iOS 15 中没有默认开启，需要手动启用。方法是进入「设置」>「隐私」>「记录 App 活动」，打开「记录 App 活动」开关。iOS 会开始记录所有 App 活动。
此后，需要给 iOS 一定时间积累数据；一段时间后回到同一界面，原本灰色的「存储 App 活动」按钮将变为可以点击状态，此时点击该按钮即可弹出分享菜单，将 ndjson 格式的日志文件导出。
根据 ndjson 官网说明，ndjson 全称为「Newline Delimited JSON」；如其名称所标明，ndjson 格式文件的本质就是 json 对象的集合，其每一行都是一个有效的 json 对象。这样，既能充分利用 json 格式的广泛支持和简明语法，又能便于与 Unix 风格的文本处理工具相结合，非常适合存储一条一行、需要频繁追加新内容的日志文件。这或许就是 Apple 选择用该格式存储隐私日志的原因。
更具体的技术内容这里就不展开讲解了。得益于 R 语言活跃的社区力量，我们可以使用 ndjson 包方便的读取 ndjson 文件并将其转换为我们熟悉的表格样式。
（注： 由于本文中进行了一定量的分析工作，为了避免代码过多影响阅读，这里主要展示结果，更详细分析步骤可以参考我的博客。）
我们首先读取 ndjson 文件并保存为数据帧结构：
# 读取日志并保存为数据帧 app_privacy_report_tb
app_privacy_report_tb <-
ndjson::stream_in(
"resource/App_Privacy_Report_v4_2021-10-11T22_36_54.ndjson"
,
cls =
"tbl"
)
# 预览数据帧
glimpse(app_privacy_report_tb)
输出结果如下：
Rows: 19,687
Columns: 15
$ accessor.identifier <chr> "com.xiaomi.mihome", "com.xiaomi.mihome", "com…
$ accessor.identifierType <chr> "bundleID", "bundleID", "bundleID", "bundleID"…
$ category <chr> "location", "location", "location", "location"…
$ identifier <chr> "60E8004B-D969-4ABB-B83F-460663BCC29F", "60E80…
$ kind <chr> "intervalBegin", "intervalEnd", "intervalBegin…
$ timeStamp <chr> "2021-10-08T13:30:43.340+08:00", "2021-10-08T1…
$ type <chr> "access", "access", "access", "access", "acces…
$ bundleID <chr> NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA…
$ context <chr> NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA…
$ domain <chr> NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA…
$ domainOwner <chr> NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA…
$ domainType <dbl> NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA…
$ firstTimeStamp <chr> NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA…
$ hits <dbl> NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA…
$ initiatedType <chr> NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA…
从第一行可知，从 10 月 8 日到 10 月 10 日的三天里，笔者手机中所有的 App 总共留下了 19687 条隐私请求日志（后文将会介绍一次隐私请求可能对应两条记录，因此实际请求数会小于这个数字，但不会低于其 1/2）。怎么说呢，这些 App 就还挺勤劳的吧。
至于 ndjson 文件中出现的各键（key）的具体含义，尽管笔者并不是 iOS 开发者，App 隐私报告功能暂时也没有官方文档说明，但可以通过一些分析来推断出各列的意义：
type： 是指该条访问记录所属的「大类」，包括 access（请求数据或传感器信息）和 networkActivity（网络活动）两种。
accessor.identifier 和 bundleID： 均指访问隐私信息的应用包名（bundle ID）。
需要注意的是，这两者在日志中是择其一记录的：如果该条的 type 为 access，即应用访问的是数据或传感器，那么只会在 accessor.identifier 中记录包名，bundleID 则留空（显示为 NA）；如果 type 为 networkActivity，即应用是在访问网络，则正好相反。（笔者在一开始在这里走过些弯路，以为只有 accessor.identifier 是包名，但后来发现以此为条件分析数据会漏掉近一半的日志信息；于是回头检查，这才发现了上面的门道。）
category： 适用于 access 类型的记录，是指具体访问的数据或传感器类型，包括 camera（相机）、contacts（通讯录）、location（定位）以及 photos（相册）。
kind 和 timeStamp： 表示每次请求开始和结束的时间。在相邻成对的两条记录中，kind 为 intervalBegin 的记录，其 timeStamp 代表该次请求开始的时间；kind 为 intervalEnd 的记录，其 timeStamp 代表该次请求结束的时间。
identifier： 为每次请求的内部编号，使用 UUID 格式。
（注： 对于类型为网络活动的日志，还会涉及其他类型的信息，包括访问的域名（domain）、访问的频次（hits）等；由于如今 App 访问网络非常普遍，而不同 App、不同使用习惯会得到的日志差异较大，该类日志能揭示的隐私访问情况不具有代表性，故不作为本文介绍和分析重点。）
下面，我们通过 R 的数据可视化功能，对导出的数据作进一步分析。
（注： 由于数据可视化代码长度较长且晦涩，为了文章简洁，我把相关代码放在我的博客。）
结合上文对数据内容的分析：
accessor.identifier 和 bundleID 都是包名，只是用在不同类型的访问记录中，我们将其合并为 app_id，代表发出请求的 App；networkActivity（网络活动）也视作 access 的一种，与其他访问数据或传感器信息的请求一起分析。我们首先按照 type 中隐私请求和网络活动二分类进行可视化，查看每个 App 请求用户数据的大类是怎样一种趋势：
我们可以从上图得出如下信息：
com.dianping/com.meituan（美团点评）在柱状图中并没有很抢眼，不过这很有可能是因为我早已关闭了「大众点评」和「美团」 App 后台刷新以及始终定位的权限的原因；com.xiaomi.mihome （米家）这位小老弟靠实力诠释了什么是一骑绝尘；猜测是因为我开启了它「始终定位」权限所致。这个功能最开始是为了方便「回家自动开灯」这类地理围栏功能方才许可的，然而后出于实用性等原因并没有开启这些智能化，因此实际上并没有什么事情需要「米家」对我进行定位。与它相比，除了排在后面的两款网络调试 App 数据请求数量还能在图表中展示出来，其它 App 相比之下仿佛什么数据都没有请求过一般。实际上，如果再按照 category 中多分类数据请求进行可视化：
「米家」庞大的定位请求次数，也掩盖了图中其它 App 的所有潜在趋势。
分析至此，笔者不禁对米家何以会如此频繁地请求位置信息产生了好奇。后面的分析也将以它为「主角」。
为了分析米家 App 的访问请求，我们只选择 app_id 为 com.xiaomi.mihome 的数据进行单独分析。
（注： 本文写作时使用的米家 App 版本为 v6.11.201-build6.11.201.2。）
首先，我们画一个饼图，看看「米家」到底都请求了哪类数据：
除了少量的网络请求之外，「米家」只专注于请求用户定位。网络请求，很好理解，毕竟智能家居什么的还是要跟家里面跟服务器沟通的，至少笔者认为这是必要的数据请求。然而这个定位，是真的太太太让人印象深刻了。
因此，我们接下来聚焦于「米家」的定位请求，先对日志显示的定位起止时间求差值，看看每次定位持续多久：
| skim_variable | n_missing | complete_rate | min | max | median | n_unique |
|---|---|---|---|---|---|---|
| duration | 0 | 1 | 10.01 secs | 1129.66 secs | 10.19 secs | 2052 |
由如上输出可知，米家在 3 天里进行了 2052 次定位（n_unique），最短定位耗时 10.01 秒，最长耗时 18 分钟（这是在羞辱 iPhone 信号强度吗？）；耗时中位数为 10.19 秒。
再来画张折线图，看看米家都是什么时候请求用户定位的：
可见，米家还真是夜以继日的请求用户数据的，可以说是「007」了；只有在凌晨才舍得勉强克制一点。
这些统计数据，与 iOS「电池」选项中的显示的米家耗电量遥相呼应。这间接印证了系统日志没有冤枉「米家」。
关键是，正如前文说过的，笔者根本没有开启米家中需要用到「地理围栏」的任何功能，所以它完全没有理由一刻不停的请求我的定位信息。
对此，笔者目前没有更好的解决方法，只能「斩草除根」，彻底关闭米家的定位权限；几天下来，发现完全没有影响到笔者的使用体验（但需要地理围栏功能的小伙伴这么做之前需要慎重考虑）。
总的来说，根据使用 R 分析 App 隐私报告，笔者并未发现美团与微信的频繁访问，不过这并不能说明它们没有问题，因为我已经关掉了此二者的后台刷新以及始终定位功能，使得他两个没有办法实现频繁唤醒；不过让人意外的是，笔者无意中发现了潜在的耗电大户——米家。
在这里，笔者根据分析结果给广大 iOS 用户一个使用建议：无论是出于隐私保护，亦或是降低无谓的耗电量，强烈建议大家谨慎开启 App 的后台刷新以及始终允许访问位置信息的权限。你永远也想不到那些主流的 App 到底在背着你干些什么。
> 下载少数派 客户端 、关注 少数派公众号 ，了解更妙的数字生活 🍃
> 想申请成为少数派会员？冲！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。