PolicyGapper 論文閱讀分析：很多 App 真正先出問題的，不是偷拿資料本身，而是商店頁面把你會拿什麼講得太乾淨
本文由 AI 產生、整理與撰寫。
論文基本資訊
- 論文標題：Automated Detection of Inconsistencies Between Google Play Data Safety Sections and Privacy Policies Using LLMs
- 作者：Luca Verderame、Billel Habbati、Meriem Guerar、Mariano Ceccato
- 年份：2026
- 來源：arXiv:2604.16128
- 論文連結：https://arxiv.org/abs/2604.16128
- DOI：10.48550/arXiv.2604.16128
- 主題：Privacy Compliance、Android Security、Google Play、Privacy Policy Analysis、LLM Audit、App Store Governance
這篇 paper 我覺得最有意思的地方，不是它又拿 LLM 去做一個文件比對器，而是它抓到了一個很實際、也很常被忽略的風險：很多 app 的隱私問題，不一定先爆在 binary 裡，也可能先爆在「商店頁面怎麼對人說明自己會拿哪些資料」這一層。
Google Play 的 Data Safety Section（DSS）本來就是要把 app 的資料蒐集、分享與用途壓成比較短、比較能被一般使用者讀懂的標準化揭露。但現實世界裡，真正完整的敘述通常躲在冗長的 privacy policy 裡，兩邊一旦沒有對齊，用戶看到的就很可能是一個被摘要過頭、甚至被摘要歪掉的版本。
這篇提出的 PolicyGapper，就是想把這個 DSS–PP gap 變成可自動盤點的問題：不用抓 APK、不用做動靜態分析，單靠 Google Play 上公開的 Data Safety Section 加上 privacy policy，就去找出policy 有寫、但 DSS 沒有揭露的 omitted declarations。
它要解的不是「app 到底有沒有偷資料」，而是「你對外講的跟你文件裡寫的是不是同一回事」
這個 framing 很重要。很多 Android 隱私研究都在做另一件事：看實際 code、permission、network traffic 跟 privacy policy 是否一致。那條線當然重要，但這篇切的角度不一樣，它專注的是cross-document inconsistency：
- Privacy Policy：長、法律導向、資訊比較完整
- Data Safety Section：短、結構化、面向一般使用者
如果 PP 寫了會收集某些資料、或會分享某些資料給第三方，但 DSS 沒有把這些揭露出來，那使用者在商店頁面上得到的 privacy impression 就可能是錯的。這種錯不一定代表 app 行為一定違法或一定惡意，但它至少代表透明度聲稱和正式文件之間有落差。
而且這種落差很麻煩，因為它不是單純 keyword matching 就能抓到。政策文字常常寫得又繞、又條件式、又有法律保留句，真正難的是：某段 policy 文字到底對應到 Google Play 那 14 個 data categories / 38 個 data types 裡的哪一格？又算 collection 還是 sharing？
PolicyGapper 怎麼做：把 LLM 放在一條五段式文件稽核流程裡
作者的方法不是把整份 policy 和 DSS 一股腦丟給模型問「有沒有不一致」，而是把任務拆成幾段：
- Scraping：抓 Google Play 上的 DSS 與 privacy policy
- Pre-processing：先從 policy 裡抽出和資料收集 / 資料分享相關的聲明
- Analysis：把 policy 聲明和 DSS 對照，找出疑似 omitted declarations
- Post-processing：再過一次語意與規則檢查，把 hallucination、誤配對、重複項目洗掉
- Reporting：輸出 collection 與 sharing 兩份結構化結果
我覺得這個設計算是蠻務實的。因為它承認 LLM 有兩個老問題：
- 輸入太長會亂：所以先把 policy 中真正相關的段落抽出來
- 會自信亂連結：所以再做 post-processing，把語意不相干或不符合 Google 規則的結果剔掉
換句話說，這篇不是把 LLM 當萬能法官，而是把它當語意映射與文件比對引擎，再用流程分層把它的毛病壓低。
為什麼這題值得看：它碰的是 app store governance 的一個真空地帶
作者在背景裡點得很準：Google Play 雖然要求 DSS 與 privacy policy 要一致，也提供一些 compliance dashboard，但目前缺的不是規則本身，而是自動驗證兩份文件語意是否對齊的工具。
這就形成一個治理落差：
- 開發者被要求揭露
- 使用者被鼓勵相信 Data Safety Section
- 但平台和開發者其實都缺少能持續稽核 DSS–PP alignment 的實用工具
所以這篇的價值，不只是幫研究者做大規模 measurement，而是很像在補一個真正該存在的 pre-review / self-audit compliance layer。對平台方來說，這可當上架前或版本更新前的檢查器；對開發團隊來說，這更像是 release pipeline 裡該有的一道文件一致性 lint。
實驗數字其實蠻刺眼
作者把 PolicyGapper 跑在 330 個 app 上，涵蓋 Google Play 全部 33 個類別 的 top-ranked apps，資料蒐集時間是 2025 年第三季。結果抓出：
- 2,689 個 omitted disclosures
- 其中 2,040 個屬於 data collection
- 649 個屬於 data sharing
- 而且作者說 超過 95% 的受測 app 都含有已驗證的 omitted declarations
這個量級很有殺傷力。它意味著問題不是少數 app 忘了填，而比較像是整個 Android 隱私揭露生態都還沒把 DSS–PP 對齊當成工程與治理上的常規工作。
在人工驗證的 10% 分層樣本上，作者報告三次獨立執行後的平均表現為：
- Precision：0.75
- Recall：0.77
- Accuracy：0.69
- F1-score：0.76
這不是那種「神準到可以直接當執法系統」的數字，但對我來說已經足夠說明它能當一個很有實用價值的 triage / audit 輔助器。這種任務本來就不該期待完全無誤差；更合理的定位，是把人工法遵 / 隱私審查的工作量先壓下來，把高風險不一致先撈出來。
我最認同的一點：它避開了 binary analysis 的昂貴成本，先處理文件治理這塊更容易落地的問題
很多人看到隱私合規研究，第一反應都是去抓 app 行為、做 network tracing、做 static / dynamic analysis。那方向很硬，也很重要，但它有幾個老問題：
- 大規模分析成本高
- 動態分析 coverage 不夠
- 混淆、反偵錯、反封裝會干擾結果
- 平台或中小開發團隊很難把這些檢查真正塞進日常流程
這篇反而走一條比較聰明的路：先從公開文件本身找治理不一致。它不宣稱這能取代 app behavior analysis，但它把問題放在一個更容易大規模、自動化、快速納入 CI / release governance 的位置。
這件事其實很有營運價值。因為真實世界裡，很多合規事故不是因為公司完全不知道自己 app 在拿什麼，而是：
- 法務寫了 policy
- 產品或發行端手動填了 DSS
- 版本更新後資料流改了
- 但兩邊沒人持續對齊
最後造成的不是 code exploit，而是透明度債（transparency debt） 越積越大。
它也補了一個很值得注意的盲點：使用者看的通常不是 privacy policy，而是商店上的短揭露
這點非常現實。大多數使用者根本不會讀完整份 privacy policy，他們真正會看到、而且在安裝前最可能依賴的，通常就是 app store 那塊精簡版揭露。
所以如果 DSS 比 policy 更乾淨、更少、更安全，看起來就像 app 比實際文件承認的更克制。這不是純法律問題，這是decision-interface security 問題：使用者的安裝判斷，是在一個可能被低估風險的介面上做出的。
從這個角度看，PolicyGapper 抓的其實不只是文件不一致，而是使用者決策介面和正式責任文件之間的資訊落差。
當然，這篇也有很清楚的限制
- 它檢查的是 PP 與 DSS 的一致性，不是 DSS 與真實程式行為的一致性
- 如果 privacy policy 自己就寫錯、寫模糊、故意保留，這套系統也可能跟著失真
- LLM 仍可能誤解法律語句或 data type 映射，所以 0.76 F1 比較適合用在審查輔助，而不是全自動裁決
- Google 的 disclosure taxonomy 與例外規則本身也會演化，工具需要跟著平台政策更新
不過這些限制大多不是致命缺陷，而是提醒你要把它放在正確的位置上：它不是法院，也不是 reverse engineering 替代品；它比較像是app store privacy governance 的自動稽核前哨站。
我的看法
如果你關心的是 Android 隱私、AppSec、平台治理或 compliance automation，這篇值得看。它最有價值的地方，不在於又一次證明 LLM 可以讀文件，而在於它把問題定義得很對：
很多隱私風險真正先崩掉的，不是資料流本身，而是使用者被告知的那個版本，早就和正式文件不是同一個世界。
在這個意義上，PolicyGapper 的意義不是「幫 Google Play 多抓幾個填錯欄位的 app」而已，而是把隱私揭露從一次性的表單填寫，往持續對齊、可自動稽核、可納入 release 流程的工程問題推進一步。
簡單講，這篇提醒我們：很多產品真正該被稽核的，不只是它偷偷蒐集了什麼，而是它到底有沒有把自己蒐集與分享的事情，好好、完整、誠實地說給使用者聽。