王申奧，王亞龍，王乾旭，賀紫怡，李 暉

(西安電子科技大學(xué) 網(wǎng)絡(luò)與信息安全學(xué)院，陜西 西安 710071)

0 引言

近年來(lái)，移動(dòng)應(yīng)用超范圍收集用戶隱私信息，強(qiáng)制索取敏感權(quán)限等現(xiàn)象屢見(jiàn)不鮮。為了保護(hù)用戶的個(gè)人隱私信息，監(jiān)管部門(mén)要求企業(yè)或組織在隱私政策以簡(jiǎn)潔易讀的方式告知用戶他們?nèi)绾问占?、存?chǔ)和管理用戶的個(gè)人信息。然而，根據(jù)武漢大學(xué)2021 年的相關(guān)調(diào)查[1]顯示，77.8%的用戶在安裝App時(shí)“很少或從未”閱讀過(guò)隱私協(xié)議，69.69%的用戶會(huì)忽略App 隱私協(xié)議的更新提示。盡管一些服務(wù)提供商已經(jīng)提高了其隱私政策的可理解性和可讀性，但這些政策仍然篇幅太長(zhǎng)，難以閱讀[2-3]。此外，2021 年國(guó)家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心和中國(guó)網(wǎng)絡(luò)空間安全協(xié)會(huì)共同發(fā)布的《App 違法違規(guī)收集使用個(gè)人信息監(jiān)測(cè)分析報(bào)告》[4]中也顯示，超范圍收集用戶隱私信息，違反用戶“知情同意”原則的違法違規(guī)應(yīng)用在各主流應(yīng)用市場(chǎng)仍然廣泛存在。

近來(lái)，隱私合規(guī)分析的相關(guān)工作在國(guó)外頗受關(guān)注，逐漸被應(yīng)用到大規(guī)模網(wǎng)站隱私合規(guī)性分析、移動(dòng)應(yīng)用隱私泄露檢測(cè)等領(lǐng)域。移動(dòng)應(yīng)用的隱私合規(guī)分析主要包括隱私政策文本分析與程序分析兩個(gè)部分。靜態(tài)程序分析執(zhí)行效率高，然而由于缺乏運(yùn)行時(shí)路徑信息，靜態(tài)分析往往會(huì)產(chǎn)生一定程度的誤報(bào)。動(dòng)態(tài)污點(diǎn)分析通常是利用插裝和代碼重寫(xiě)為污點(diǎn)數(shù)據(jù)創(chuàng)建污點(diǎn)標(biāo)記，優(yōu)點(diǎn)是準(zhǔn)確率更高，但插裝和代碼重寫(xiě)往往帶來(lái)更大的性能開(kāi)銷(xiāo)。隱私合規(guī)研究往往是在程序分析的基礎(chǔ)上結(jié)合隱私政策文本進(jìn)行合規(guī)性檢查。隱私政策文本分析作為國(guó)外新興的研究熱點(diǎn)，已經(jīng)陸續(xù)建立起豐富的隱私政策語(yǔ)料庫(kù)。然而在中文領(lǐng)域，隱私政策命名實(shí)體識(shí)別的研究仍然缺乏，中文隱私政策的公開(kāi)語(yǔ)料庫(kù)也仍處于空白。這些問(wèn)題制約了國(guó)內(nèi)隱私政策與程序分析相結(jié)合的自動(dòng)化合規(guī)檢測(cè)技術(shù)的發(fā)展。

為了解決上述問(wèn)題，本文通過(guò)人工注釋構(gòu)建危險(xiǎn)權(quán)限術(shù)語(yǔ)詞典，提出利用雙向最大匹配算法實(shí)現(xiàn)基于詞典的隱私政策自動(dòng)標(biāo)注，從而構(gòu)建中文隱私政策權(quán)限詞實(shí)體識(shí)別語(yǔ)料庫(kù)。在此基礎(chǔ)上，本文為隱私政策語(yǔ)料構(gòu)建預(yù)訓(xùn)練字嵌入，通過(guò)雙向長(zhǎng)短期記憶神經(jīng)-條件隨機(jī)場(chǎng)(Bi-directional Long Short-Term Memory -Conditional Random Field，BiLSTM -CRF) 架構(gòu)實(shí)現(xiàn)最優(yōu)標(biāo)簽序列預(yù)測(cè)，從而完成權(quán)限詞實(shí)體識(shí)別任務(wù)。在應(yīng)用程序動(dòng)靜態(tài)混合分析部分，基于Androguard 實(shí)現(xiàn)交叉引用并對(duì)程序?qū)嶋H調(diào)用的危險(xiǎn)權(quán)限進(jìn)行靜態(tài)分析。通過(guò)隱私政策聲明權(quán)限集與實(shí)際調(diào)用權(quán)限集的一致性分析，實(shí)現(xiàn)了對(duì)超范圍收集敏感信息行為的檢測(cè)。此外，依托 Frida 動(dòng)態(tài)插樁與Hook 技術(shù)，對(duì)敏感應(yīng)用編程接口(Application Programming Interface，API)進(jìn)行重載，記錄函數(shù)調(diào)用堆棧、調(diào)用頻次、關(guān)鍵參數(shù)等行為日志信息，針對(duì)同意隱私政策前收集、靜默狀態(tài)下頻繁訪問(wèn)敏感信息實(shí)現(xiàn)運(yùn)行時(shí)狀態(tài)監(jiān)測(cè)。

1 相關(guān)工作

自2018 年歐盟出臺(tái)《通用數(shù)據(jù)保護(hù)條例》(General Data Protection Regulation，GDPR)以來(lái)，國(guó)內(nèi)外學(xué)者針對(duì)安卓隱私泄露與合規(guī)檢測(cè)等問(wèn)題進(jìn)行了大量研究。關(guān)于安卓隱私合規(guī)檢測(cè)的工作最早可以追溯到對(duì)隱私泄露的研究，但二者的側(cè)重又有所不同。安卓隱私泄露的相關(guān)研究關(guān)注于數(shù)據(jù)流的動(dòng)靜態(tài)混合污點(diǎn)分析，目標(biāo)是確定安卓隱私泄露的潛在路徑，而從技術(shù)上講，如果這些數(shù)據(jù)流在隱私政策中被披露，它們就不屬于“泄露”行為。因此，相比單純基于數(shù)據(jù)流的動(dòng)靜態(tài)污點(diǎn)分析，合規(guī)檢測(cè)更關(guān)注于隱私聲明自動(dòng)化分析與安卓隱私數(shù)據(jù)泄露的交叉領(lǐng)域。目前的相關(guān)工作重點(diǎn)關(guān)注于提取隱私政策中聲明的權(quán)限信息并與實(shí)際權(quán)限調(diào)用進(jìn)行一致性分析，下面分類(lèi)介紹這兩個(gè)方面的研究進(jìn)展。

1.1 動(dòng)靜態(tài)混合污點(diǎn)分析

總體來(lái)說(shuō)，程序分析方法主要包括靜態(tài)分析和動(dòng)態(tài)分析兩種。其中靜態(tài)分析主要是通過(guò)對(duì)APK文件進(jìn)行反編譯，分析從源點(diǎn)(Source)到匯點(diǎn)(Sink)的潛在數(shù)據(jù)流路徑，從而檢測(cè)隱私泄露的方法。典型的靜態(tài)污點(diǎn)分析工具有FlowDroid[5]和IccTA[6]等。FlowDroid[5]拓展了Soot 框架，提出了按需追蹤的反向別名分析方法，從而支持上下文敏感、流敏感、域敏感、對(duì)象敏感，對(duì)于直接賦值，函數(shù)調(diào)用和別名傳播三種污點(diǎn)傳播方式都能實(shí)現(xiàn)高精度分析。IccTA在FlowDroid 的基礎(chǔ)上為每個(gè)組件創(chuàng)建虛函數(shù)，并建立組件間連接，解決了組件間通信導(dǎo)致的隱私泄露問(wèn)題。但是由于缺乏運(yùn)行時(shí)路徑信息，以上靜態(tài)分析方法都很難正確地對(duì)分支語(yǔ)句(判斷和控制)進(jìn)行處理，可能衍生出一些實(shí)際場(chǎng)景中根本不可能被執(zhí)行的程序路徑，從而產(chǎn)生一定的誤報(bào)。

動(dòng)態(tài)分析則是通過(guò)模擬應(yīng)用的實(shí)際運(yùn)行情況，獲取應(yīng)用運(yùn)行時(shí)的行為數(shù)據(jù)，從而檢測(cè)數(shù)據(jù)能否從污染源點(diǎn)傳播到污染匯點(diǎn)。典型的動(dòng)態(tài)分析方法包括TaintDroid[7]和TaintEraser[8]，它們通常是利用插裝和代碼重寫(xiě)為污點(diǎn)數(shù)據(jù)創(chuàng)建污點(diǎn)標(biāo)記，根據(jù)指令類(lèi)型和指令操作數(shù)設(shè)計(jì)相應(yīng)的傳播邏輯，在此基礎(chǔ)上進(jìn)行污點(diǎn)標(biāo)記的存儲(chǔ)與追蹤。然而，插裝和代碼重寫(xiě)往往帶來(lái)更大的性能開(kāi)銷(xiāo)，在純動(dòng)態(tài)的情況下，原始程序的每條指令通常需要6～8 次額外的污點(diǎn)追蹤指令來(lái)傳播污點(diǎn)標(biāo)簽。

目前安卓隱私泄露的最新研究更多地集中在輕量級(jí)動(dòng)靜態(tài)混合分析?；旌戏治鲋械撵o態(tài)部分旨在預(yù)優(yōu)化追蹤邏輯，縮減追蹤范圍，從而減小動(dòng)態(tài)分析的性能開(kāi)銷(xiāo)。FSAFlow[9]通過(guò)修改FlowDroid[5]框架實(shí)現(xiàn)目標(biāo)路徑與關(guān)鍵分支信息的搜索，選擇違反預(yù)定義的隱私策略的潛在路徑，利用有限狀態(tài)自動(dòng)機(jī)進(jìn)行編碼，將少量狀態(tài)管理代碼插裝到程序相應(yīng)位置，防止運(yùn)行時(shí)信息泄露。

1.2 隱私聲明與權(quán)限調(diào)用一致性分析

相比于動(dòng)靜態(tài)混合污點(diǎn)分析的隱私泄露研究，隱私聲明與權(quán)限調(diào)用的一致性分析更關(guān)注于隱私聲明的自動(dòng)化解析，從而為應(yīng)用行為動(dòng)靜態(tài)隱私泄露分析提供判斷依據(jù)。

早期研究[10-11]大多是利用AndroidManifest.xml 文件或者應(yīng)用描述信息來(lái)識(shí)別開(kāi)發(fā)者對(duì)于應(yīng)用權(quán)限調(diào)用的相關(guān)聲明，一些經(jīng)典的工作如WHYPER[10]和AutoCog[11]利用自然語(yǔ)言處理技術(shù)從應(yīng)用描述中提取權(quán)限信息并與應(yīng)用實(shí)際調(diào)用的權(quán)限進(jìn)行對(duì)比，從而識(shí)別隱私違規(guī)行為。然而，應(yīng)用描述信息字符有限，不能夠完整地表達(dá)開(kāi)發(fā)者對(duì)于權(quán)限調(diào)用的實(shí)際聲明。此外，AndroidManifest.xml 文件中列舉的權(quán)限信息也不能夠直接反映開(kāi)發(fā)者的權(quán)限聲明和用戶所知情的授權(quán)范圍，因此其研究局限性較強(qiáng)。

最近的一些工作[12-17]更關(guān)注于隱私政策與應(yīng)用程序關(guān)聯(lián)分析的合規(guī)檢測(cè)方法。Slavin[12]等人構(gòu)建了最早的隱私聲明與權(quán)限調(diào)用的一致性分析框架，通過(guò)對(duì)50 個(gè)移動(dòng)應(yīng)用隱私政策的人工注釋構(gòu)建了隱私策略術(shù)語(yǔ)詞典，使用基于描述邏輯的形式化語(yǔ)言構(gòu)建權(quán)限術(shù)語(yǔ)本體，在此基礎(chǔ)上構(gòu)建了隱私策略本體短語(yǔ)與API 方法的映射，從而識(shí)別弱違規(guī)和強(qiáng)違規(guī)行為。這項(xiàng)工作的局限性在于沒(méi)有區(qū)分弱違規(guī)的程度，用戶隱私的范圍也只限于通過(guò)安卓權(quán)限獲取的敏感信息，而忽略了用戶的動(dòng)態(tài)輸入的隱私信息(如手機(jī)號(hào)碼、身份證ID 等)。Wang[13]等人隨后在這項(xiàng)工作的基礎(chǔ)上做了改進(jìn)，他們考慮了用戶通過(guò)UI 界面輸入的隱私信息，通過(guò)構(gòu)建UI 控件樹(shù)從控件標(biāo)簽中獲取語(yǔ)義，從而識(shí)別應(yīng)用收集的敏感信息類(lèi)型，完成隱私政策聲明與敏感信息收集行為的一致性檢測(cè)。

另外一些工作如Polisis[14]和PolicyLint[15]則是將深度學(xué)習(xí)應(yīng)用到隱私政策的自動(dòng)化分析任務(wù)中。Polisis[14]通過(guò)訓(xùn)練特定于隱私聲明領(lǐng)域的詞嵌入并構(gòu)建CNN 多層次分類(lèi)模型，以88.4%的準(zhǔn)確率實(shí)現(xiàn)了隱私政策的結(jié)構(gòu)化的解析。PolicyLint[15]在這項(xiàng)工作的基礎(chǔ)上考慮數(shù)據(jù)對(duì)象和實(shí)體的否定，從語(yǔ)義層面對(duì)谷歌應(yīng)用市場(chǎng)中11 430 個(gè)應(yīng)用程序的隱私聲明中存在的矛盾進(jìn)行分析，實(shí)現(xiàn)了否定詞敏感的隱私政策結(jié)構(gòu)化解析。Andow 等人提出的PoliCheck[16]則是在二者的基礎(chǔ)上將隱私政策解析進(jìn)一步細(xì)化，通過(guò)區(qū)分敏感信息收集的第一方主體與第三方SDK，對(duì)數(shù)據(jù)流路徑末端匯點(diǎn)的目的域名進(jìn)行匹配，實(shí)現(xiàn)了實(shí)體敏感的隱私合規(guī)檢測(cè)。Nguyen[17]等人著重關(guān)注于用戶同意隱私政策前的違規(guī)收集行為，通過(guò)與應(yīng)用無(wú)UI 交互狀態(tài)下的網(wǎng)絡(luò)流量審計(jì)，檢測(cè)程序中存在的違規(guī)敏感信息傳輸。

然而，目前隱私政策自動(dòng)化解析的相關(guān)研究還主要集中在英文領(lǐng)域。隱私政策文本分析作為國(guó)外新興的研究熱點(diǎn)，已經(jīng)陸續(xù)建立起豐富的隱私政策語(yǔ)料庫(kù)。Usable Privacy Policy 項(xiàng)目提供了十余個(gè)常用的英文隱私政策語(yǔ)料庫(kù)，如OPP-115 Corpus[18]、APP-350 Corpus[19]、Opt-out Choice[20]等?；谶@些語(yǔ)料數(shù)據(jù)訓(xùn)練的自然語(yǔ)言處理模型能夠從隱私政策中自動(dòng)提取隱私信息相關(guān)的結(jié)構(gòu)化數(shù)據(jù)。但目前國(guó)內(nèi)尚未建立相關(guān)中文隱私政策語(yǔ)料庫(kù)，中文隱私政策文本自動(dòng)分析的相關(guān)研究也比較缺乏。

2 隱私政策自動(dòng)化解析

為了實(shí)現(xiàn)隱私政策與應(yīng)用程序的聯(lián)合分析，需要實(shí)現(xiàn)隱私政策的自動(dòng)化信息抽取，得到其中權(quán)限聲明相關(guān)的結(jié)構(gòu)化數(shù)據(jù)。在隱私政策解析部分，本文將權(quán)限信息的結(jié)構(gòu)化抽取作為命名實(shí)體識(shí)別任務(wù)，構(gòu)建了中文隱私政策權(quán)限詞實(shí)體識(shí)別語(yǔ)料庫(kù)，并基于BiLSTM-CRF 完成模型訓(xùn)練，方案架構(gòu)如圖1 所示。

圖1 隱私政策自動(dòng)化解析方案架構(gòu)

2.1 中文隱私政策語(yǔ)料庫(kù)構(gòu)建

為了完成隱私政策中危險(xiǎn)權(quán)限詞的命名實(shí)體識(shí)別任務(wù)，需要構(gòu)建人工標(biāo)記的隱私語(yǔ)料數(shù)據(jù)集用于模型訓(xùn)練。因此，在本部分，本文首先獲取隱私政策原始語(yǔ)料數(shù)據(jù)，原始語(yǔ)料的收集主要考慮了以下兩個(gè)方面：

(1)樣本量：為了防止數(shù)據(jù)集過(guò)小造成的過(guò)擬合現(xiàn)象，同時(shí)綜合考慮模型的準(zhǔn)確度和人工標(biāo)注的時(shí)間成本，最終選定了用于人工標(biāo)記的隱私政策語(yǔ)料93 篇，待拓展隱私政策語(yǔ)料965 篇。

(2)抽樣方法：為了使樣本分布盡可能與所有在架應(yīng)用分布保持一致，本文按照以下兩條規(guī)則進(jìn)行抽樣。一是樣本空間熱門(mén)應(yīng)用(high-profile)和冷門(mén)應(yīng)用(long-tail)比例適當(dāng)(即樣本要符合在架應(yīng)用下載量的冪律分布規(guī)律)，結(jié)合小米應(yīng)用市場(chǎng)的應(yīng)用下載量，最終選取頭部應(yīng)用231 款，冷門(mén)應(yīng)用827款；二是樣本應(yīng)用類(lèi)型覆蓋范圍盡可能廣泛，最終選取包括金融理財(cái)、社交聊天、圖書(shū)閱讀等在內(nèi)的14 類(lèi)常見(jiàn)類(lèi)型應(yīng)用。

(3)收集方法：應(yīng)用隱私政策的獲取方式有兩種，一是提取應(yīng)用內(nèi)嵌在安裝包內(nèi)的隱私政策，但這種方法需要對(duì)應(yīng)用進(jìn)行反編譯，時(shí)間成本高昂；二是通過(guò)提取開(kāi)發(fā)者上傳到應(yīng)用市場(chǎng)的隱私政策，通常這些隱私政策存儲(chǔ)在服務(wù)器上，因此可以利用Selenium 自動(dòng)請(qǐng)求隱私政策鏈接，進(jìn)一步調(diào)用Beautiful Soup 庫(kù)進(jìn)行格式化解析，去除多余標(biāo)簽，從而完成隱私政策提取。

在隱私政策的自動(dòng)化解析中，應(yīng)重點(diǎn)關(guān)注危險(xiǎn)權(quán)限詞的實(shí)體識(shí)別任務(wù)。因此在本小節(jié)，本文以Android 定義的危險(xiǎn)權(quán)限組歸納出九類(lèi)實(shí)體類(lèi)型，如表1 所示。

表1 九類(lèi)危險(xiǎn)權(quán)限術(shù)語(yǔ)詞類(lèi)型

命名實(shí)體識(shí)別廣義上屬于序列標(biāo)記任務(wù)的范疇，因此其語(yǔ)料標(biāo)注規(guī)范也遵循序列標(biāo)記的通用規(guī)范，常見(jiàn)的序列標(biāo)注格式有三種：BIO 格式、BMES 格式以及BIOES 格式。三者都是字符粒度級(jí)別的標(biāo)注格式，各標(biāo)簽含義如表2 所示。

表2 常用序列標(biāo)注規(guī)范中的標(biāo)簽含義

在此選擇BIOES 格式進(jìn)行標(biāo)注(B 代表實(shí)體詞的開(kāi)始；I 代表實(shí)體詞中間位置的字符；O 代表非實(shí)體字符；E 表示實(shí)體詞的結(jié)束；S 代表單個(gè)字符組成的實(shí)體)。相比于其他兩種標(biāo)注格式，BIOES 格式提供了更豐富的信息，便于在模型預(yù)測(cè)時(shí)提取實(shí)體。

在中文隱私政策危險(xiǎn)權(quán)限詞實(shí)體識(shí)別任務(wù)中，共安排三位注釋員分別對(duì)93 篇隱私政策原始語(yǔ)料進(jìn)行注釋。為了解決人工標(biāo)注文本存在的歧義，評(píng)估標(biāo)注序列的共現(xiàn)頻率，結(jié)合注釋規(guī)則確定有效標(biāo)注：當(dāng)兩位注釋員同時(shí)為某個(gè)詞序列添加標(biāo)記后，才將該注釋作為實(shí)體標(biāo)記，引入第三位注釋員進(jìn)行判斷。對(duì)93篇隱私政策標(biāo)注并去重后共獲得危險(xiǎn)權(quán)限詞注釋964 份，但由于標(biāo)注歧義等情況，最終經(jīng)過(guò)注釋規(guī)則與人工審核確定了有效危險(xiǎn)權(quán)限詞標(biāo)記677 個(gè)。

通過(guò)人工標(biāo)注獲取的熟語(yǔ)料注釋準(zhǔn)確性高，不容易出現(xiàn)注釋歧義，但缺點(diǎn)是人工注釋費(fèi)時(shí)費(fèi)力，由于泛化能力的需求，實(shí)際場(chǎng)景中的命名實(shí)體識(shí)別任務(wù)很難僅靠人工標(biāo)注的語(yǔ)料數(shù)據(jù)進(jìn)行模型訓(xùn)練。解決小樣本命名實(shí)體識(shí)別語(yǔ)料缺乏的方法之一是通過(guò)雙向最大匹配算法(Bidirectional Maximal Matching，BMM)進(jìn)行語(yǔ)料拓展。

雙向最大匹配算法是一種典型的基于詞典的序列標(biāo)注方法，它通過(guò)比較正向最大匹配(Forward Maximal Matching，F(xiàn)MM) 和反向最大匹配(Reverse Maximal Matching，RMM)的標(biāo)注結(jié)果得到正確的標(biāo)注序列。

正向匹配算法從文本串起始處正向掃描，取出子串與字典進(jìn)行匹配。后向匹配算法同理，差別在于后向匹配算法從結(jié)尾處對(duì)字符進(jìn)行切分匹配。雙向匹配算法正是在二者結(jié)果的基礎(chǔ)上進(jìn)行綜合。如果前向匹配和后向匹配的切分結(jié)果詞數(shù)不同，則返回詞數(shù)較少的；如果詞數(shù)相同且切分結(jié)果相同，則返回任意一個(gè)結(jié)果；如果詞數(shù)相同但分詞結(jié)果不同，則返回單字較少的分詞結(jié)果。

本文將人工標(biāo)記的93 篇語(yǔ)料和BMM 拓展的965 篇語(yǔ)料進(jìn)行合并，得到最終的1 058 篇隱私政策語(yǔ)料數(shù)據(jù)，作為隱私政策權(quán)限詞實(shí)體識(shí)別訓(xùn)練語(yǔ)料。

2.2 隱私政策權(quán)限詞命名實(shí)體識(shí)別

在該小節(jié)中，本文利用先前獲得的標(biāo)記語(yǔ)料構(gòu)建數(shù)據(jù)集，在此基礎(chǔ)上訓(xùn)練特定于隱私詞領(lǐng)域的雙向長(zhǎng)短期記憶神經(jīng)-條件隨機(jī)場(chǎng)(Privacy Specific Bi-directional Long Short-Term Memory -Conditional Random Field，PRI-BiLSTM-CRF)模型，從而完成中文隱私政策權(quán)限詞實(shí)體識(shí)別任務(wù)。

首先，對(duì)數(shù)據(jù)集進(jìn)行劃分。按照18:1:1 的比例切分得到訓(xùn)練集、驗(yàn)證集、測(cè)試集。得到訓(xùn)練、驗(yàn)證、測(cè)試集的語(yǔ)句數(shù)量分別為103 553、6 543、6 305，分別加載數(shù)據(jù)集并進(jìn)行預(yù)處理。預(yù)處理過(guò)程首先是對(duì)數(shù)據(jù)集進(jìn)行分句，之后對(duì)標(biāo)注格式進(jìn)行檢查，最后利用word2vec 預(yù)訓(xùn)練100 維字向量特征。為了充分地利用隱私政策中危險(xiǎn)權(quán)限詞的長(zhǎng)度特性，本文額外構(gòu)建20 維的詞長(zhǎng)度特征。根據(jù)語(yǔ)句分詞結(jié)果，將單字成詞的特征標(biāo)記為0，詞首長(zhǎng)度特征為1，詞間長(zhǎng)度特征為2，詞尾長(zhǎng)度特征為3，按照以上規(guī)則為每個(gè)字構(gòu)造詞長(zhǎng)度id，通過(guò)Embedding 層將詞長(zhǎng)度id處理為20 維的向量特征，作為字向量特征的補(bǔ)充，提供更豐富的信息。之后將100 位字向量特征與20維詞長(zhǎng)度特征拼接，最終得到120 維向量輸入模型，在此基礎(chǔ)上進(jìn)行訓(xùn)練與更新。

接下來(lái)對(duì)模型架構(gòu)進(jìn)行介紹，該模型由Embedding 層(字向量嵌入層)、BiLSTM 隱藏層、Linear 層(線性層)與CRF 輸出層構(gòu)成。模型結(jié)構(gòu)如圖2 所示。

圖2 PRI-BILSTM-CRF 模型架構(gòu)

在Embedding 層，首先加載預(yù)訓(xùn)練的100 維字向量并將詞長(zhǎng)度id 轉(zhuǎn)化為20 維詞長(zhǎng)度特征，然后拼接得到120 維向量輸入。BiLSTM 層則是以Embedding 層的120 維向量特征作為輸出，通過(guò)前向和后向傳播得到各自的隱狀態(tài)，最后將前向LSTM(128 維)和后向LSTM(128 維)的隱狀態(tài)拼接(256 維)送入Linear 層獲得發(fā)射分?jǐn)?shù)(標(biāo)簽向量)。而CRF 層接收發(fā)射矩陣作為輸入，通過(guò)計(jì)算標(biāo)簽的轉(zhuǎn)移分?jǐn)?shù)生成標(biāo)簽序列的概率分布，使用Viterbi 算法解碼得到最優(yōu)路徑。

在模型評(píng)估方法上，命名實(shí)體識(shí)別模型的評(píng)估方式通常分為兩種：一是通用的基于字符標(biāo)簽進(jìn)行直接評(píng)估，二是考慮實(shí)體邊界和實(shí)體類(lèi)型的評(píng)測(cè)。前者是字符級(jí)別的評(píng)估，主要方法是將所有測(cè)試樣本的真實(shí)標(biāo)簽列表和預(yù)測(cè)標(biāo)簽列表進(jìn)行比對(duì)，直接計(jì)算Precision、Recall 和F1 值。然而這種評(píng)估方式應(yīng)用于序列標(biāo)注時(shí)效果并不理想。在序列標(biāo)注中，單個(gè)錯(cuò)誤的字符標(biāo)簽的實(shí)際影響范圍涉及整個(gè)實(shí)體，因此序列標(biāo)注任務(wù)更多采用基于實(shí)體級(jí)別的評(píng)估方法，只有當(dāng)實(shí)體邊界和實(shí)體類(lèi)別同時(shí)被標(biāo)記正確，才能認(rèn)為實(shí)體識(shí)別正確。Sang 等人提出的CoNLL-2003[21]基準(zhǔn)是一種典型的實(shí)體級(jí)別的命名實(shí)體識(shí)別模型評(píng)估方法，其中Precision 被定義為模型預(yù)測(cè)正確的命名實(shí)體占所有命名實(shí)體的百分比，Recall 是模型預(yù)測(cè)正確的命名實(shí)體占語(yǔ)料庫(kù)中所有命名實(shí)體的百分比，只有當(dāng)實(shí)體預(yù)測(cè)標(biāo)簽與真實(shí)標(biāo)簽完全匹配時(shí)才認(rèn)為預(yù)測(cè)正確。利用CoNLL-2003方法對(duì)模型訓(xùn)練結(jié)果進(jìn)行評(píng)估。根據(jù)驗(yàn)證集上的模型評(píng)估結(jié)果，保存最優(yōu)模型。

通過(guò)構(gòu)建中文隱私政策語(yǔ)料庫(kù)并訓(xùn)練隱私政策權(quán)限詞命名實(shí)體識(shí)別模型，本文實(shí)現(xiàn)了隱私政策的自動(dòng)化信息抽取，得到其中權(quán)限聲明相關(guān)的結(jié)構(gòu)化數(shù)據(jù)。

3 應(yīng)用程序動(dòng)靜態(tài)混合分析

在本節(jié)中，通過(guò)應(yīng)用程序動(dòng)靜態(tài)混合分析來(lái)識(shí)別危險(xiǎn)權(quán)限調(diào)用情況，完成隱私政策文本與程序?qū)嶋H權(quán)限調(diào)用的一致性檢測(cè)。其中，在程序靜態(tài)分析部分，通過(guò)反編譯與源碼分析實(shí)現(xiàn)基于Androguard框架的危險(xiǎn)權(quán)限調(diào)用檢測(cè)。在動(dòng)態(tài)分析部分，利用基于Frida 的Hook 技術(shù)，實(shí)時(shí)獲取應(yīng)用使用的敏感權(quán)限并返回函數(shù)調(diào)用堆棧日志等。應(yīng)用程序動(dòng)靜態(tài)混合分析整體方案如圖3 所示。

圖3 應(yīng)用程序動(dòng)靜態(tài)混合分析方案架構(gòu)

3.1 構(gòu)建API-PERMISSION 映射

根據(jù)APK 文件精確識(shí)別出應(yīng)用實(shí)際使用的危險(xiǎn)權(quán)限，是APP 合規(guī)檢測(cè)的重點(diǎn)以及難點(diǎn)所在。通過(guò)構(gòu)建權(quán)限映射關(guān)系，分析程序代碼中的敏感API，來(lái)完成危險(xiǎn)權(quán)限調(diào)用識(shí)別。

根據(jù)安卓權(quán)限機(jī)制，所有危險(xiǎn)權(quán)限都應(yīng)該在程序中動(dòng)態(tài)申請(qǐng)，因此在危險(xiǎn)權(quán)限獲取和使用的過(guò)程中，通常需要依賴(lài)某些特定的敏感API 來(lái)實(shí)現(xiàn)。此外，Intent 對(duì)象的某些特定ACTION 動(dòng)作需要申請(qǐng)相關(guān)權(quán)限，通過(guò)Uri 訪問(wèn)Content Provider 時(shí)，特定Uri對(duì)象也意味著應(yīng)用使用了相關(guān)權(quán)限。因此，敏感API、Intent ACTION 和Content Provider Uri 都能夠關(guān)聯(lián)應(yīng)用的危險(xiǎn)權(quán)限調(diào)用行為。無(wú)論是靜態(tài)分析還是動(dòng)態(tài)分析，核心思路都是捕獲程序的敏感API、Intent ACTION 或Content Provider Uri，實(shí)現(xiàn)對(duì)危險(xiǎn)權(quán)限調(diào)用及敏感信息收集的檢測(cè)。

為了能夠識(shí)別應(yīng)用程序的實(shí)際權(quán)限調(diào)用情況，首先的工作是構(gòu)建全面、精準(zhǔn)的API-PERMISSION映射關(guān)系。在以往的工作中，PScout[22]利用Soot 框架執(zhí)行靜態(tài)分析并構(gòu)建函數(shù)調(diào)用圖，在圖上執(zhí)行向后可達(dá)性分析，識(shí)別出可達(dá)權(quán)限的所有API 調(diào)用，并重復(fù)可達(dá)性分析直到權(quán)限檢查數(shù)量收斂，最終構(gòu)建出Android API 16 到23 版本的權(quán)限映射結(jié)果；Axplorer[23]研究安卓框架的內(nèi)部結(jié)構(gòu)，生成高精度調(diào)用圖，并通過(guò)控制流切片進(jìn)行分析，最終生成Android API 16 到25 版本的權(quán)限映射結(jié)果。然而PScout 和Axplorer 的工作還存在一定的局限性，由于研究年限較早等原因，所涉及的API 版本也只局限在16 到25 版本，因此，在PScout 和Axplorer 工作的基礎(chǔ)上，本文對(duì)API 26 到32 版本中危險(xiǎn)權(quán)限相關(guān)的API的映射關(guān)系進(jìn)行了補(bǔ)充。其中部分映射如表3 所示。

表3 部分API-PERMISSION 映射示例

對(duì)于Intent 和Content Provider 而言，危險(xiǎn)權(quán)限通常與特定的ACTION或Uri 相關(guān)聯(lián)。Intent 對(duì)象啟動(dòng)Activity時(shí)，某些特定ACTION 動(dòng)作需要申請(qǐng)相關(guān)權(quán)限，例如android.intent.action.CALL需要使用CALL_PHONE 權(quán)限。訪問(wèn)Content Provider 時(shí)，需要將指定Content Provider 的Uri 對(duì)象傳遞給Content-Resolver 類(lèi)，然后通過(guò)Uri 定位資源，進(jìn)而完成增刪查改等操作，因此特定Uri 對(duì)象的訪問(wèn)也意味著應(yīng)用需要提前申請(qǐng)并獲取相關(guān)敏感權(quán)限。

在對(duì)1 900 余款A(yù)pp 進(jìn)行測(cè)試和人工審核后，獲取了9 組24 種危險(xiǎn)權(quán)限的共計(jì)9 200 余種APIPERMISSION 映射關(guān)系。

3.2 基于Androguard 的靜態(tài)分析

基于Androguard 的靜態(tài)分析模塊建立在APIPERMISSION 映射庫(kù)的基礎(chǔ)上。該模塊具有兩大功能：一是識(shí)別應(yīng)用實(shí)際調(diào)用的危險(xiǎn)權(quán)限；二是識(shí)別應(yīng)用程序的頑固權(quán)限申請(qǐng)行為。

為了識(shí)別應(yīng)用實(shí)際調(diào)用的危險(xiǎn)權(quán)限，采用以下流程進(jìn)行靜態(tài)分析：首先基于Androguard 訪問(wèn)APK文件中的所有信息，并使用AnalyzeAPK()函數(shù)分析DEX文件，得到源碼中存在的所有類(lèi)與字符串；接下來(lái)根據(jù)構(gòu)建好的權(quán)限映射關(guān)系，遍歷得到的所有類(lèi)和字符串，如果存在敏感API 或特定Intent.ACTION/Content Provider Uri 對(duì)應(yīng)字符串，則根據(jù)映射關(guān)系庫(kù)輸出對(duì)應(yīng)危險(xiǎn)權(quán)限。通過(guò)上述過(guò)程識(shí)別出源碼中存在的危險(xiǎn)權(quán)限后，將識(shí)別出的危險(xiǎn)權(quán)限集與隱私政策中聲明的權(quán)限集進(jìn)行一致性分析，判斷應(yīng)用存在的違規(guī)權(quán)限調(diào)用及超范圍隱私信息收集行為。

應(yīng)用程序的頑固權(quán)限申請(qǐng)行為檢測(cè)主要包括兩個(gè)步驟：第一步是根據(jù)函數(shù)之間的交叉引用，建立程序的函數(shù)調(diào)用圖(Call Graph)；第二步是根據(jù)函數(shù)調(diào)用圖，對(duì)權(quán)限申請(qǐng)點(diǎn)進(jìn)行動(dòng)態(tài)回溯，查找可達(dá)的程序退出點(diǎn)，確定是否存在從權(quán)限申請(qǐng)函數(shù)到終止應(yīng)用函數(shù)的路徑。

首先，根據(jù)交叉引用建立函數(shù)關(guān)系圖，遍歷程序中所有方法，將這些方法作為有向圖中的節(jié)點(diǎn)，添加到函數(shù)調(diào)用圖中。然后查找每個(gè)函數(shù)節(jié)點(diǎn)的交叉引用，并通過(guò)圖中的有向邊表示函數(shù)之間的調(diào)用關(guān)系。圖4 展示了一個(gè)典型的函數(shù)調(diào)用圖示例，其中，淺灰色表示Activity 內(nèi)部節(jié)點(diǎn)的相互調(diào)用，而深灰色則表示內(nèi)部節(jié)點(diǎn)對(duì)外部節(jié)點(diǎn)的調(diào)用。

圖4 靜態(tài)分析得到的函數(shù)調(diào)用圖

為確定權(quán)限申請(qǐng)的相關(guān)入口點(diǎn)是否會(huì)在一定條件下(即用戶拒絕權(quán)限申請(qǐng)時(shí))導(dǎo)致應(yīng)用運(yùn)行終止，可采用可達(dá)性分析方法，對(duì)以此類(lèi)入口點(diǎn)為根節(jié)點(diǎn)的函數(shù)調(diào)用圖進(jìn)行遍歷，以確定是否存在從權(quán)限申請(qǐng)函數(shù)到終止應(yīng)用函數(shù)的路徑。表4 中展示了一些常見(jiàn)的權(quán)限申請(qǐng)入口點(diǎn)與程序終止出口點(diǎn)。

表4 部分權(quán)限申請(qǐng)入口點(diǎn)與程序終止出口點(diǎn)示例

當(dāng)應(yīng)用存在頑固權(quán)限申請(qǐng)行為時(shí)，權(quán)限申請(qǐng)函數(shù)和應(yīng)用終止函數(shù)通常為并列關(guān)系。checkSelfPermission 檢查程序權(quán)限申請(qǐng)狀態(tài)，該函數(shù)作為頑固索權(quán)的入口點(diǎn)，finish 函數(shù)在未獲得授權(quán)時(shí)結(jié)束程序，作為頑固索權(quán)終止點(diǎn)，二者在函數(shù)調(diào)用圖中都是通過(guò)onClick 調(diào)用，基于這種位置關(guān)系，可對(duì)入口點(diǎn)進(jìn)行有界回溯，搜索函數(shù)關(guān)系圖中是否存在對(duì)應(yīng)的程序終止點(diǎn)。

3.3 基于Frida 的動(dòng)態(tài)分析

Frida 是一款基于Python 和JavaScript 的輕量級(jí)可編程調(diào)試框架，它具有細(xì)粒度的流程控制、代碼級(jí)的可定制體系并且可以不斷進(jìn)行動(dòng)態(tài)調(diào)試。動(dòng)態(tài)分析基于Frida 框架自動(dòng)化Hook App 所有敏感API的調(diào)用行為，利用Python 實(shí)現(xiàn)遠(yuǎn)程過(guò)程調(diào)用(RPC)，通過(guò)JavaScript 腳本生成Native 函數(shù)實(shí)現(xiàn)敏感API攔截與重載，記錄待檢測(cè)樣本運(yùn)行時(shí)獲取隱私信息的行為，動(dòng)態(tài)分析方案架構(gòu)如圖5 所示。

圖5 Frida 動(dòng)態(tài)插樁分析方案架構(gòu)

Frida 框架分為客戶端和服務(wù)端，服務(wù)端中運(yùn)行著Frida-Server 后臺(tái)進(jìn)程和Hook 目標(biāo)進(jìn)程?？蛻舳薘PC 遠(yuǎn)程過(guò)程調(diào)用連接到服務(wù)端上的Frida-Server，當(dāng)Frida-Server 接收到Hook 指令時(shí)，F(xiàn)rida-Server 會(huì)向目標(biāo)進(jìn)程中注入JavaScript 腳本及其執(zhí)行引擎環(huán)境。通過(guò)Frida 動(dòng)態(tài)插樁技術(shù)，可以將JavaScript 腳本插入到平臺(tái)原生App 的內(nèi)存空間中，實(shí)現(xiàn)對(duì)程序邏輯的跟蹤、監(jiān)控甚至修改，因此Frida 框架可以實(shí)現(xiàn)從Java 層到Native 層的函數(shù)Hook。執(zhí)行Hook 操作時(shí)需要找到Hook 位置，即類(lèi)名加方法名，通過(guò)將JavaScript 注入到黑盒進(jìn)程中，F(xiàn)rida 框架能夠Hook目標(biāo)程序中幾乎任何方法。在找到Hook 位置后，需要在目標(biāo)進(jìn)程中觸發(fā)對(duì)應(yīng)的方法。Frida 框架通過(guò)修改Dalvik 虛擬機(jī)的accessFlags 標(biāo)志，將需要Hook的Java 方法注冊(cè)為Native 方法，并修改函數(shù)的入口為自定義的內(nèi)容。當(dāng)系統(tǒng)執(zhí)行到待Hook 的目標(biāo)方法時(shí)，虛擬機(jī)優(yōu)先執(zhí)行Native 方法，此時(shí)Frida 擁有了程序控制權(quán)，可以優(yōu)先執(zhí)行注入代碼，實(shí)現(xiàn)對(duì)程序邏輯的跟蹤、監(jiān)控與修改。

JavaScript 腳本是注入目標(biāo)進(jìn)程并Hook 敏感API的關(guān)鍵。在JavaScript 腳本中，首先通過(guò)java.use()函數(shù)找到目標(biāo)類(lèi)并實(shí)例化一個(gè)對(duì)象，調(diào)用目標(biāo)類(lèi)成功后，使用overload()函數(shù)對(duì)敏感API 進(jìn)行攔截并重載，在完成重載后，可以實(shí)時(shí)獲得敏感API 的參數(shù)，并可以根據(jù)需要對(duì)參數(shù)內(nèi)容進(jìn)行修改。

當(dāng)手機(jī)端進(jìn)行觸發(fā)敏感行為的操作時(shí)，返回權(quán)限調(diào)用時(shí)間、權(quán)限調(diào)用類(lèi)型、關(guān)鍵參數(shù)內(nèi)容以及函數(shù)調(diào)用堆棧等信息。通過(guò)動(dòng)態(tài)分析，可實(shí)現(xiàn)以下兩種隱私違規(guī)行為的檢測(cè)：

(1)用戶同意隱私政策前的違規(guī)權(quán)限調(diào)用與信息收集行為。通過(guò)模擬用戶操作到達(dá)隱私政策控件所在的Activity，測(cè)試在點(diǎn)擊同意的控件之前，應(yīng)用是否存在收集IMEI、設(shè)備MAC 地址、通訊錄和短信等敏感信息的行為。

(2)程序靜默狀態(tài)下的頻繁收集行為。App 在靜默狀態(tài)或后臺(tái)運(yùn)行時(shí)，如果存在權(quán)限調(diào)用與信息收集行為，也會(huì)實(shí)時(shí)觸發(fā)Hook。

4 實(shí)驗(yàn)與分析

4.1 測(cè)試方案

本文對(duì)隱私政策權(quán)限詞實(shí)體識(shí)別模型性能以及隱私合規(guī)檢測(cè)整體方案在實(shí)際場(chǎng)景下的檢測(cè)能力進(jìn)行了測(cè)試，具體測(cè)試方法如下：

(1)模型測(cè)試部分，采用考慮實(shí)體邊界和實(shí)體類(lèi)別的CoNLL-2003[21]方法進(jìn)行命名實(shí)體識(shí)別性能評(píng)估，評(píng)估指標(biāo)包括Precision、Recall 和F1-score，每100 次訓(xùn)練對(duì)模型進(jìn)行評(píng)估，累計(jì)1 000 次訓(xùn)練F1-score 無(wú)優(yōu)化后停止迭代。

(2) 檢測(cè)能力測(cè)試部分，采取實(shí)證評(píng)估方法對(duì)來(lái)自小米應(yīng)用市場(chǎng)與360 手機(jī)助手的1 941 款應(yīng)用進(jìn)行隱私合規(guī)檢測(cè)。

4.2 測(cè)試環(huán)境與系統(tǒng)架構(gòu)

本文實(shí)現(xiàn)的隱私合規(guī)檢測(cè)系統(tǒng)包括PC 端與手機(jī)模擬器端兩個(gè)部分。PC 端在Windows 10 21H1 64位系統(tǒng)上進(jìn)行測(cè)試，處理器為Inter Core i5-11300H 3.10 GHz，內(nèi)存為Micron Technology 16 GB，軟件環(huán)境包括Python 3.10，Androguard 3.3.5，Uiautomator2，PyTorch 1.11.0 等，手機(jī)模擬器采用逍遙模擬器7.6.1版本，機(jī)型為OPPO RENO PRO，系統(tǒng)版本為Android 7.1.2。隱私合規(guī)檢測(cè)系統(tǒng)整體架構(gòu)如圖6 所示，自下而上包括隱私政策語(yǔ)料庫(kù)、隱私政策解析模塊、應(yīng)用程序分析模塊、隱私合規(guī)項(xiàng)檢測(cè)模塊。

圖6 系統(tǒng)架構(gòu)圖

4.3 實(shí)驗(yàn)結(jié)果分析

模型測(cè)試部分，每100 次訓(xùn)練正向傳播和反向傳播完成后，計(jì)算模型在驗(yàn)證集上的損失函數(shù)，同時(shí)評(píng)估危險(xiǎn)權(quán)限詞實(shí)體識(shí)別F1 值，實(shí)驗(yàn)結(jié)果如圖7 所示。

圖7 中，方框坐標(biāo)軸及折線代表訓(xùn)練過(guò)程中驗(yàn)證集上的損失，三角坐標(biāo)軸及折線代表訓(xùn)練過(guò)程中驗(yàn)證集上的F1 值，在第1 800 次訓(xùn)練時(shí)獲得最小損失和最大F1 值，此后1 000 次訓(xùn)練中F1 值無(wú)優(yōu)化，模型停止迭代。

圖7 模型在驗(yàn)證集上的損失與F1 值

在測(cè)試集上對(duì)最優(yōu)模型在9 類(lèi)權(quán)限詞實(shí)體識(shí)別任務(wù)的Precision、Recall 和F1-score 進(jìn)行評(píng)估，測(cè)試結(jié)果如表5 所示。

表5 最優(yōu)模型在9 類(lèi)權(quán)限詞實(shí)體識(shí)別下的測(cè)試結(jié)果(%)

最終，在9 類(lèi)危險(xiǎn)權(quán)限詞實(shí)體識(shí)別任務(wù)上的平均Precision 為91.09%，平均Recall 為93.21%，平均F1-score 為91.92%，結(jié)果說(shuō)明模型在實(shí)體識(shí)別任務(wù)上有較優(yōu)的性能。

在檢測(cè)能力測(cè)試部分，利用該系統(tǒng)對(duì)小米應(yīng)用市場(chǎng)和360 手機(jī)助手的1 941 款應(yīng)用進(jìn)行合規(guī)檢測(cè)，共計(jì)發(fā)現(xiàn)52 款A(yù)pp 存在隱私合規(guī)問(wèn)題，包括32 款應(yīng)用未聲明全部隱私權(quán)限，即存在隱私政策聲明與權(quán)限調(diào)用不一致，5 款應(yīng)用存在用戶同意隱私政策前收集敏感信息，3 款應(yīng)用無(wú)隱私政策聲明，1 款應(yīng)用的隱私政策存在冗余聲明，1 款應(yīng)用存在強(qiáng)制索取權(quán)限等。

5 結(jié)論

隨著App 違法違規(guī)收集使用個(gè)人信息專(zhuān)項(xiàng)治理工作的不斷深入，監(jiān)管部門(mén)、企業(yè)開(kāi)發(fā)者以及個(gè)人用戶對(duì)于App 隱私合規(guī)檢測(cè)的需求都不斷增加?，F(xiàn)有隱私合規(guī)檢測(cè)產(chǎn)品由于忽略對(duì)隱私政策的評(píng)估，因而產(chǎn)生較高的誤報(bào)率和漏報(bào)率。

該研究從實(shí)際需求出發(fā)，構(gòu)建了安卓應(yīng)用隱私政策與權(quán)限調(diào)用一致性合規(guī)檢測(cè)系統(tǒng)，主要包括四個(gè)創(chuàng)新點(diǎn)：(1)構(gòu)建首個(gè)中文隱私政策語(yǔ)料庫(kù)并訓(xùn)練危險(xiǎn)權(quán)限詞實(shí)體識(shí)別模型，以平均91.92%的F1 值完成了隱私政策危險(xiǎn)權(quán)限詞信息抽取；(2)提出輕量級(jí)、低開(kāi)銷(xiāo)的安卓應(yīng)用權(quán)限調(diào)用動(dòng)靜態(tài)混合分析方案，通過(guò)對(duì)程序中的敏感API 進(jìn)行定位或重載，實(shí)現(xiàn)了程序?qū)嶋H調(diào)動(dòng)危險(xiǎn)權(quán)限的動(dòng)靜態(tài)檢測(cè)；(3)構(gòu)建半自動(dòng)化的安卓應(yīng)用隱私聲明與權(quán)限調(diào)用一致性合規(guī)檢測(cè)框架，通過(guò)將隱私聲明權(quán)限集與程序?qū)嶋H調(diào)用的危險(xiǎn)權(quán)限集進(jìn)行一致性分析，識(shí)別未聲明的權(quán)限調(diào)用與敏感信息收集行為；(4)針將強(qiáng)制索取權(quán)限、用戶同意隱私政策前收集敏感信息、后臺(tái)或靜默狀態(tài)下頻繁收集敏感信息等子功能進(jìn)行集成，實(shí)現(xiàn)對(duì)于主流違規(guī)行為的檢測(cè)。

該方案設(shè)計(jì)還存在一定的改進(jìn)空間：(1)本作品對(duì)于“隱私”的關(guān)注范疇僅限于應(yīng)用程序通過(guò)危險(xiǎn)權(quán)限獲取到的敏感信息，但在實(shí)際應(yīng)用場(chǎng)景中，仍存在部分隱私信息是用戶通過(guò)應(yīng)用的UI 界面提供的，例如手機(jī)號(hào)碼、身份證號(hào)碼、搜索偏好等，對(duì)于這類(lèi)數(shù)據(jù)的合規(guī)保護(hù)需要更多結(jié)合UI 控件及數(shù)據(jù)流的污點(diǎn)分析方法進(jìn)行研究；(2)在隱私政策解析工作中重點(diǎn)關(guān)注危險(xiǎn)權(quán)限術(shù)語(yǔ)的實(shí)體識(shí)別，對(duì)于語(yǔ)義理解與句法分析未能展開(kāi)深入探討與研究。

綜上所述，該研究在現(xiàn)階段下很好地解決了國(guó)內(nèi)App 隱私合規(guī)檢測(cè)所面臨的技術(shù)挑戰(zhàn)，有效彌補(bǔ)了隱私政策與程序分析項(xiàng)結(jié)合在一致性合規(guī)檢測(cè)領(lǐng)域的空缺。同時(shí)，該研究構(gòu)建的中文隱私政策語(yǔ)料庫(kù)也能夠?yàn)槿蘸蟮南嚓P(guān)研究提供基準(zhǔn)數(shù)據(jù)集，具有重要現(xiàn)實(shí)意義和廣闊應(yīng)用前景，對(duì)App 隱私合規(guī)的長(zhǎng)效治理工作起到積極的促進(jìn)作用。