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「選擇性展示」造成的假象。
準備工作
如上所述，「隱私報告」功能在 iOS 15 中沒有預設開啟，需要手動啟用。方法是進入「設定」>「隱私」>「記錄 App 活動」，開啟「記錄 App 活動」開關。iOS 會開始記錄所有 App 活動。
此後，需要給 iOS 一定時間積累資料；一段時間後回到同一介面，原本灰色的「儲存 App 活動」按鈕將變為可以點選狀態，此時點選該按鈕即可彈出分享選單，將 格式的日誌檔案匯出。
根據ndjson官網說明，ndjson 全稱為「Newline Delimited JSON」；如其名稱所標明，ndjson 格式檔案的本質就是 json 物件的集合，其每一行都是一個有效的 json 物件。這樣，既能充分利用 json 格式的廣泛支援和簡明語法，又能便於與 Unix 風格的文字處理工具相結合，非常適合儲存一條一行、需要頻繁追加新內容的日誌檔案。這或許就是 Apple 選擇用該格式儲存隱私
日誌
的原因。
更具體的技術內容這裡就不展開講解了。得益於 R 語言活躍的社群力量，我們可以使用ndjson包方便的讀取 檔案並將其轉換為我們熟悉的表格樣式。
（
注：
由於本文中進行了一定量的分析工作，為了避免程式碼過多影響閱讀，這裡主要展示結果，更詳細分析步驟可以參考我的部落格。）
讀取與預覽
我們首先讀取 檔案並儲存為資料幀結構：
輸出結果如下：
從第一行可知，從 10 月 8 日到 10 月 10 日的三天裡，筆者手機中所有的 App 總共留下了 19687 條隱私請求日誌（後文將會介紹一次隱私請求可能對應兩條記錄，因此實際請求數會小於這個數字，但不會低於其 1/2）。怎麼說呢，這些 App 就還挺勤勞的吧。
至於 ndjson 檔案中出現的各鍵（key）的具體含義，儘管筆者並不是 iOS 開發者，App 隱私報告功能暫時也沒有官方文件說明，但可以透過一些分析來推斷出各列的意義：
：
是指該條訪問記錄所屬的「大類」，包括 access（請求資料或感測器資訊）和 networkActivity（網路活動）兩種。
和
：
均指訪問隱私資訊的應用包名（bundle ID）。
需要注意的是，這兩者在日誌中是擇其一記錄的：如果該條的 為 ，即應用訪問的是資料或感測器，那麼只會在 中記錄包名， 則留空（顯示為 NA）；如果 為 ，即應用是在訪問網路，則正好相反。（筆者在一開始在這裡走過些彎路，以為只有 是包名，但後來發現以此為條件分析資料會漏掉近一半的日誌資訊；於是回頭檢查，這才發現了上面的門道。）
：
適用於 型別的記錄，是指具體訪問的資料或感測器型別，包括 （相機）、（通訊錄）、（定位）以及 （相簿）。
和
：
表示每次請求開始和結束的時間。在相鄰成對的兩條記錄中， 為 的記錄，其 代表該次請求開始的時間； 為 的記錄，其 代表該次請求結束的時間。
：
為每次請求的內部編號，使用 UUID 格式。
（
注：
對於型別為網路活動的日誌，還會涉及其他型別的資訊，包括訪問的域名（）、訪問的頻次（）等；由於如今 App 訪問網路非常普遍，而不同 App、不同使用習慣會得到的日誌差異較大，該類日誌能揭示的隱私訪問情況不具有代表性，故不作為本文介紹和分析重點。）
資料視覺化
下面，我們透過 R 的資料視覺化功能，對匯出的資料作進一步分析。
（
注：
由於資料視覺化程式碼長度較長且晦澀，為了文章簡潔，我把相關程式碼放在我的部落格。）
結合上文對資料內容的分析：
考慮到 和 都是包名，只是用在不同型別的訪問記錄中，我們將其合併為 ，代表發出請求的 App；
將 （網路活動）也視作 的一種，與其他訪問資料或感測器資訊的請求一起分析。
我們首先按照 中隱私請求和網路活動二分類進行視覺化，檢視每個 App 請求使用者資料的大類是怎樣一種趨勢：
我們可以從上圖得出如下資訊：
總共有 85 款 App 請求了隱私資料，平均下來一款 App 的請求日誌數量為 115。81 條。
我們預想中以 （美團點評）在柱狀圖中並沒有很搶眼，不過這很有可能是因為我早已關閉了「大眾點評」和「美團」 App 後臺重新整理以及始終定位的許可權的原因；
不顯山不漏水的 （米家）這位小老弟靠實力詮釋了什麼是一騎絕塵；猜測是因為我開啟了它「始終定位」許可權所致。這個功能最開始是為了方便「回家自動開燈」這類地理圍欄功能方才許可的，然而後出於實用性等原因並沒有開啟這些智慧化，因此實際上並沒有什麼事情需要「米家」對我進行定位。與它相比，除了排在後面的兩款網路除錯 App 資料請求數量還能在圖表中展示出來，其它 App 相比之下彷彿什麼資料都沒有請求過一般。
實際上，如果再按照 中多分類資料請求進行視覺化：
「米家」龐大的定位請求次數，也掩蓋了圖中其它 App 的所有潛在趨勢。
分析至此，筆者不禁對米家何以會如此頻繁地請求位置資訊產生了好奇。後面的分析也將以它為「主角」。
米家 App 的定位請求分析
為了分析米家 App 的訪問請求，我們只選擇 為 的資料進行單獨分析。
（
注：
本文寫作時使用的米家 App 版本為 v6。11。201-build6。11。201。2。）
首先，我們畫一個餅圖，看看「米家」到底都請求了哪類資料：
除了少量的網路請求之外，「米家」只專注於請求使用者定位。網路請求，很好理解，畢竟智慧家居什麼的還是要跟家裡面跟伺服器溝通的，至少筆者認為這是必要的資料請求。然而這個定位，是真的太太太讓人印象深刻了。
因此，我們接下來聚焦於「米家」的定位請求，先對日誌顯示的定位起止時間求差值，看看每次定位持續多久：
由如上輸出可知，米家在 3 天裡進行了 2052 次定位（），最短定位耗時 10。01 秒，最長耗時 18 分鐘（這是在羞辱 iPhone 訊號強度嗎？）；耗時中位數為 10。19 秒。
再來畫張折線圖，看看米家都是什麼時候請求使用者定位的：
可見，米家還真是夜以繼日的請求使用者資料的，可以說是「007」了；只有在凌晨才捨得勉強剋制一點。
這些統計資料，與 iOS「電池」選項中的顯示的米家耗電量遙相呼應。這間接印證了系統日誌沒有冤枉「米家」。
關鍵是，正如前文說過的，筆者根本沒有開啟米家中需要用到「地理圍欄」的任何功能，所以它完全沒有理由一刻不停的請求我的定位資訊。
對此，筆者目前沒有更好的解決方法，只能「斬草除根」，徹底關閉米家的定位許可權；幾天下來，發現完全沒有影響到筆者的使用體驗（但需要地理圍欄功能的小夥伴這麼做之前需要慎重考慮）。
總結
總的來說，根據使用 R 分析 App 隱私報告，筆者並未發現美團與微信的頻繁訪問，不過這並不能說明它們沒有問題，因為我已經關掉了此二者的後臺重新整理以及始終定位功能，使得他兩個沒有辦法實現頻繁喚醒；不過讓人意外的是，筆者無意中發現了潛在的耗電大戶——米家。
在這裡，筆者根據分析結果給廣大 iOS 使用者一個使用建議：無論是出於隱私保護，亦或是降低無謂的耗電量，強烈建議大家謹慎開啟 App 的後臺重新整理以及始終允許訪問位置資訊的許可權。你永遠也想不到那些主流的 App 到底在揹著你幹些什麼。
