Privacy compliance analysis method for built-in third-party library of mobile application
By combining dynamic analysis with large language models, the problem of privacy compliance detection of third-party libraries in mobile applications has been solved, efficient and accurate privacy compliance detection has been achieved, and the false alarm rate and risk of user information leakage have been reduced.
Patent Information
- Application Number
- CN202510816894.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-18
- Publication Date
- 2025-09-19
AI Technical Summary
Existing technologies have difficulty effectively detecting privacy compliance issues in third-party libraries in mobile applications, especially when privacy policies are complex and dynamic analysis tools have low coverage, resulting in a high risk of privacy information leakage.
A dynamic analysis module is used to monitor API calls and decrypted traffic, and a large language model is used to analyze privacy policies, identify data flows in third-party libraries, and detect four types of violations through a compliance analysis module, including omitted disclosure, ambiguous disclosure, incorrect disclosure, and excessively frequent API calls.
It improves the accuracy of privacy compliance detection of third-party libraries, reduces false positives, saves audit time, and ensures the security of user privacy information.
Smart Images
Figure CN120671190A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of dynamic analysis and automated testing of mobile applications and privacy compliance analysis, and specifically relates to a privacy compliance analysis method for a mobile application with a built-in third-party library. Background Art
[0002] Mobile applications often integrate third-party libraries (TPLs) to implement specific functions (such as advertising and analytics). These third-party libraries can directly call framework APIs to access personal information (PI). However, due to improper configuration of third-party library APIs (such as property setting methods), many mobile apps send personal information (such as email addresses and locations) to the third-party library's servers during runtime. After obtaining personal privacy information, the third-party library may transmit it to remote servers.
[0003] If the mobile app's privacy policy does not specify that the data flows of these third-party libraries may lead to personal privacy leaks, privacy compliance issues will arise. For example, China's Ministry of Industry and Information Technology removed 13 third-party libraries (SDKs) from the market in 2022 because these third-party libraries did not inform users when collecting personal privacy. Ensuring privacy compliance for apps' built-in third-party libraries is challenging for the following reasons: Reason 1: App privacy policies are complex, involving elements such as HTML tables, pronouns, app names, and tags. Traditional methods rely on predefined patterns or machine learning classifiers to extract the privacy behaviors of third-party libraries embedded in apps. These methods struggle with complex privacy policies and often miss key behaviors.
[0004] Reason 2: According to the EU General Data Protection Regulation (GDPR) and China's Personal Information Protection Law (PIPL), applications must display a pop-up window upon first launch to request permissions or obtain consent to privacy policies. Traditional mobile app dynamic analysis tools (such as Monkey) cannot proactively allow permission requests and consent to privacy policies, resulting in relatively low coverage of TPL privacy behaviors (i.e., system APIs and sending PI to remote servers via data streams).
[0005] Reason 3: Defining a TPL domain list is time-consuming and error-prone when analyzing data streams sent to TPL remote servers to check traffic consistency with privacy policies. Without accurate identification of TPL data streams sent to remote servers, compliance issue detectors will produce many false negative results. Summary of the Invention
[0006] In order to solve the above problems, the present invention provides a method for analyzing the privacy compliance of a third-party library built into a mobile application, which includes the following steps: Step 1: Because static analysis can generate numerous false positives and waste human resources, the dynamic analysis module dynamically tests the mobile application (APP). This module collects and decrypts plaintext traffic, monitors API calls, and saves traffic and API call log files. Based on the parsed traffic and log files, the app is reverse engineered to identify the data flow within the app's built-in third-party library (TPL).
[0007] Step 2: Because the information in the privacy policy tables cannot be extracted using traditional natural language processing techniques, this step uses a large language model (LLM) to preprocess the app privacy policy tables, identifying the list of built-in third-party libraries contained in the table and the corresponding privacy information types. Natural language processing (NLP) methods are then used to extract privacy-related behaviors (privacy practices) from the app privacy policy.
[0008] Step 3: For the four defined violations, the Privacy Compliance Analysis Module compares the results of the Dynamic Analysis Module with those of the Privacy Policy Analysis Module, primarily detecting privacy compliance issues within the app's built-in third-party library, TPL. This paper does not analyze privacy compliance issues arising from the app's core engineering, but instead focuses on privacy compliance risks arising from advertising libraries, tool libraries, and social media libraries.
[0009] Preferably, step one comprises three steps: Step 1: Prepare the dynamic testing environment. For Android apps, use the official adb command to install the app. Use a predefined script to enable Frida to monitor API calls and their stack traces. Enable mitmproxy to intercept traffic from the mobile app and built-in third-party libraries.
[0010] Step 2: Identify and process permission requests and privacy policy GUIs. After installing the app and waiting 30 seconds, use UiAutomator2 to analyze the UI and determine if a pop-up window appears based on keywords. If a pop-up window appears (such as one displaying a privacy policy), use NLP sentiment analysis to determine whether the button control indicates consent. If so, click the Agree button to bypass the pop-up window. If a pop-up window requests permission, click ALLOW to grant permission.
[0011] Step 3: Dynamic Testing. Use a dynamic testing tool such as Fastbot2 to perform a dynamic test on the app for 20 minutes (this time period can be adjusted dynamically). Because pop-up prompts may appear during the test, identify and approve them again every 10 minutes. After the dynamic testing and traffic generation process is complete, save the traffic using a HAR file and save the Frida log.
[0012] Step 4: TPL Data Stream Extraction. This step primarily identifies privacy leaks from third-party libraries within the data stream. First, prepare a list of personal privacy information and its values, including the smartphone's device identifier (Device ID), MAC address, and geographic location. Because information may be encoded or hashed during transmission, preprocess this privacy information using methods such as Base64 encoding and MD5 hashing to obtain a wider range of possible privacy information values. Then, match this privacy information against the traffic. If a specific piece of personal information pi is extracted from a particular piece of traffic, it is abstracted into a tuple f = (pi, d), indicating that a certain type of personal information pi was sent to domain d.
[0013] Preferably, to identify privacy leaks caused by third-party libraries, use a decompilation tool such as Apktool to decompile the app to obtain the source code for static analysis. If the code of a third-party library is found to call an API related to obtaining the pi and use domain name d, then associate the data flow with the TPL, ultimately generating a data flow f = (tpl, pi, d), indicating that a certain tpl sent a certain type of pi to domain name d.
[0014] Preferably, Frida logs are analyzed to filter out API calls from the app's own code by analyzing the stack trace, retaining only API calls from third-party libraries. The log analysis result is expressed as (tpl,api,time), meaning that tpl called api at time.
[0015] Preferably, the privacy policy analysis module includes two steps: Step 1: Privacy Policy Preprocessing. First, use HTML tags to extract the table from the privacy policy. The table and prompt words serve as the big language input. Then, process the big language output to extract the privacy practices p = (e, c, pi) from the table. Pi represents some personal privacy information, c represents whether to collect or not collect, and e represents the entity that collects or does not collect personal privacy information.
[0016] Preferably, the large language model question template used in the present invention includes three main components: task, output format, and example.
[0017] Task: The large language model is required to determine whether the table describes the list of third-party libraries built into the mobile app and the types of private information that each third-party library may collect and transmit. If so, the table is then extracted to determine the list of third-party libraries and the private information.
[0018] Output format section: Specifies that the output be saved in JSON format for easy parsing.
[0019] Example section: Provides some manually analyzed privacy policy HTML table content (input), a list of third-party libraries described in JSON format, and a list of privacy information (output).
[0020] Considering the model hallucination problem that may exist in large models, the present invention introduces a consistency detection method to repeatedly confirm the correctness of the results by querying the large language model multiple times to remove hallucinations.
[0021] Step 2: Privacy Practice Extraction. Using a large language model, we analyze the privacy policy form to generate a series of descriptive statements describing the mobile app's built-in third-party libraries and the types of private information they collect. These statements are then merged with the original privacy policy content to facilitate privacy practice extraction.
[0022] During the extraction process, we use a set of predefined verbs (such as "collect," "share," "use," and "save" in Chinese and English) to locate privacy policy statements describing privacy practices. We then use named entity recognition (NLP) to extract the privacy practices p = (e, c, pi) from the sentences.
[0023] Preferably, the compliance detection module includes the following three steps: Step 1: Definition of Violations. This paper defines four types of violations, including three types of violations where privacy leaks in third-party library data flows are inconsistent with the privacy policy description (omission of disclosure, ambiguous disclosure, and erroneous disclosure), and one type of excessive API calls.
[0024] Step 2: Domain-to-Entity Mapping. The data stream f = (tpl, pi, d) obtained in the dynamic analysis module is used to map domains to entities. Subdomain matching is performed, and a predefined domain-to-entity mapping table is defined. The data stream f = (tpl, pi, d) is mapped to f = (tpl, pi, e), representing a certain tpl sending a certain type of pi to a certain entity e.
[0025] Step 3: Compliance Analysis. To detect inconsistencies between the privacy leaks in the third-party library data flow and the privacy policy, compare the data flow f = (tpl, pi, e) with the privacy practices p = (e, c, pi) obtained from the privacy policy analysis. The following are the detection methods for the four types of violations: (1) If there is a privacy leak in the third-party library data flow, but there is no relevant description in the privacy policy, there is an "omission of disclosure" violation, and the developer needs to supplement the privacy behavior description of the relevant third-party library.
[0026] (2) If there is a privacy leak in the data flow of a third-party library, but the privacy policy only uses vague terms such as "information", "data", "privacy information", "partial information" when describing the relevant behavior, and does not clearly indicate the type of information, then there is an "ambiguous disclosure" violation, and the developer needs to modify the privacy behavior description of the relevant third-party library.
[0027] (3) If there is a privacy leak in the third-party library data flow, but the privacy policy does not describe any privacy leaks, there is a "false disclosure" violation. The developer must correct the relevant error description, remove the negative words, and supplement the third-party library list and the corresponding leaked privacy information.
[0028] (4) To detect API frequent call violations generated by third-party libraries, the frequency of each TPL calling unused APIs is counted based on the timestamps in the Frida log. If the frequency exceeds a threshold (e.g., 10 times / minute), the third-party library is considered to be excessively called.
[0029] Compared to existing technologies, the present invention offers the following benefits: it can help app markets conduct privacy compliance checks on the built-in third-party libraries of massive mobile apps. Compared to traditional privacy compliance checks based on static analysis, dynamic data flow analysis can significantly reduce false positives and save time on auditing individual mobile apps. Furthermore, mobile app developers can use the present invention to analyze the privacy policies of their mobile apps and their built-in third-party libraries, reducing the risk of third-party libraries leaking user privacy information. BRIEF DESCRIPTION OF THE DRAWINGS
[0030] Figure 1 This is a system architecture diagram of the present invention; Figure 2 This is the dynamic test flow chart of the APP of the present invention. DETAILED DESCRIPTION
[0031] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are only used to illustrate the present invention and are not used to limit the scope of the present invention.
[0032] Example: The technical solution of the present invention is further described in detail below with reference to the accompanying drawings. This invention provides a privacy compliance analysis method for third-party libraries built into mobile applications. This method first dynamically tests the mobile application to collect data streams from the third-party library. Next, the mobile application's privacy policy is analyzed to extract privacy-related behaviors described in the privacy policy. Finally, combining the results of the dynamic analysis of the mobile application and the privacy policy analysis, the third-party library's privacy compliance issues are detected.
[0033] Module 1: Dynamic Analysis. This method dynamically tests mobile applications (APPs), collecting and decrypting plaintext traffic while monitoring API calls and saving traffic and API call log files. Based on parsing the traffic and log files, reverse engineering the APP is performed to identify data flows within the APP's built-in third-party libraries (TPLs).
[0034] Module 2: Privacy Policy Analysis. This module uses a large language model (LLM) to pre-process the app's privacy policy table, identifying the list of built-in third-party libraries and the corresponding privacy information types. Natural language processing (NLP) methods are then used to extract privacy-related behaviors (privacy practices) from the app's privacy policy.
[0035] Module 3: Privacy Compliance Analysis Module. For the four defined violations, the results of the dynamic analysis module are compared with those of the privacy policy analysis module to detect privacy compliance issues in the app's built-in third-party library, TPL.
[0036] Figure 2 This article demonstrates the basic process of dynamic testing an app, identifying the data flow of the third-party library TPL and Frida logs. Dynamic analysis mainly includes four steps: Step 1: Prepare the dynamic test environment. If the test target is an Android app, use the adb command to install the app, use Frida to monitor API calls, and use mitmproxy to capture traffic while decrypting some encrypted traffic to obtain plaintext messages.
[0037] Step 2: Identify and process the privacy policy and permission request GUI interface. After installing the app and waiting for 30 seconds until all preparations are complete, start the app using adb, and then use Uiautomator2 to analyze the UI interface. Based on the keywords in the pop-up window, determine whether there is a pop-up window for displaying the privacy policy or requesting privacy-related permissions. If there is a privacy policy display or permission request pop-up window, use NLP sentiment analysis methods to identify the control button indicating consent. Inject a click action into the UI interface to simulate an ordinary user clicking the consent button to skip the pop-up window, ensuring that the mobile application and built-in third-party libraries trigger more privacy-related API calls and data flows.
[0038] Step 3: Dynamic Testing. After bypassing the pop-up window, use dynamic testing tools such as Fastbot2 and Monkey to automatically interact with the app's interface. The dynamic testing duration is set to 20 minutes (dynamically adjustable), with pop-ups re-identified every 10 minutes and the consent button clicked (if necessary). After the dynamic testing process is complete, save the traffic generated by the mobile app and built-in third-party libraries to a HAR file. Save the results of Frida monitoring API calls to a log file.
[0039] Step 4: TPL data stream extraction. Prepare a list of personal privacy information and its values, including the smartphone's device identifier (Device ID), MAC address, and geographic location. Preprocess this privacy information using methods such as base64 encoding and MD5 hashing to obtain more possible privacy information values. Then match this privacy information from the traffic. If a certain personal information pi is extracted from a certain traffic flow, it is abstracted into a tuple f = (pi, d), indicating that a certain type of personal information pi was sent to the domain name d. For example: If precise location information (latitude and longitude) is found in the payload of a traffic flow, and the destination domain of the traffic flow is fb.com, then this behavior is abstracted into a data stream: f = (location, fb.com).
[0040] Use Apktool to decompile the app to obtain the source code and perform static program analysis. If static analysis detects that a third-party library calls an API to obtain the pi and uses domain d, then associate the data flow with the TPL, generating a data flow f = (tpl, pi, d), indicating that the TPL sent pi to domain d. For example, for the data flow f = (location, fb.com), if the code of the mobile app's built-in third-party library com.fb.ads calls an API to obtain location information, and Frida logs also show that the TPL calls this API and generates the domain fb.com, then it is assumed that the third-party library generated the data flow. This data flow is abstracted as f = (com.fb.ads, location, fb.com).
[0041] Use the script to parse the logs obtained by Frida and extract (tpl,api,time), which means that tpl called api at time.
[0042] The privacy policy analysis module consists of two steps: Step 1: Privacy Policy Preprocessing. First, use HTML tags to extract the table from the privacy policy. The table content and prompt words are used as the large language input. Using the large language model, the privacy practice p = (e, c, pi) is extracted from the table. Pi represents a type of personal information, c represents whether to collect or not collect, and e represents the entity that collects or does not collect personal information. To improve accuracy, a prompt engineering method is introduced. The large language model question template consists of three main components: task, output format, and example.
[0043] (1) Task: The large language model is required to determine whether the table describes the list of third-party libraries built into the mobile application and whether it describes the types of private information that each third-party library may collect and transmit. If so, the third-party library list and private information list are extracted.
[0044] (2) Output format: The output is saved in JSON format for easy parsing.
[0045] (3) Example section: This section provides some manually analyzed privacy policy HTML table content (input), a list of third-party libraries described in JSON format, and a list of privacy information (output).
[0046] When asking questions, in order to further improve the output accuracy of the large model, the Chain of Thought (CoT) method was introduced. "Let's think step by step" was added to the end of the prompt word template to guide the large model to think according to certain steps to ensure the correctness of the results.
[0047] After the question is asked, a consistency check method is introduced to address the potential model hallucination problem in the large model. By repeatedly querying the large language model, the correctness of the results is repeatedly confirmed to eliminate hallucinations. If hallucinations still exist, the question is processed by multiple large language models separately, and their results are voted on. The result with the most votes is selected as the final result for the table analysis.
[0048] Step 2: Privacy Practice Extraction. Based on the results of analyzing the privacy policy form using a large language model, a series of statements are generated describing the list of third-party libraries and the types of private information collected. These statements are first merged with the original privacy policy content to facilitate privacy practice extraction.
[0049] Sentences containing privacy practices are located through a set of predefined verbs, and then the privacy practices p=(e,c,pi) are extracted from the sentences using named entity recognition.
[0050] For example, for the sentence in the privacy policy: we will not share your personal information with a third party. We locate the sentence through the verb share, and then extract the privacy practices about the third party p = (third party, not collect, personal information) from the sentence.
[0051] The compliance detection module consists of the following three steps: Step 1: Define violations. Four types of privacy violations related to third-party libraries are defined. The first three types involve data flow privacy leaks that are inconsistent with the privacy policy: omission of disclosure, ambiguous disclosure, and erroneous disclosure. The last type involves frequent calls to third-party library APIs.
[0052] Step 2: Mapping domain names and entities. The data stream f = (tpl, pi, d) obtained in the dynamic analysis module is used to map domain names and entities. By matching subdomains, a set of domain name and entity mapping tables is predefined. Mapping the data stream f = (tpl, pi, d) to f = (tpl, pi, e) represents that a certain tpl sends a certain type of pi to a certain entity e. For example: for the data stream f = (com.fb.ads, location, fb.com), the entities fb and fb.com have the same second-level domain name, so the domain name fb.com can be considered to belong to the entity fb. For domain names that do not apply to such rules, a domain name and entity mapping table is constructed. The final result is the data stream f = (com.fb.ads, location, fb).
[0053] Step 3: Compliance Analysis: For the three types of violations where TPL behavior is inconsistent with the privacy policy, compare the data flow f = (tpl, pi, e) with the privacy practice p = (e, c, pi) obtained from the privacy policy analysis.
[0054] If there is a privacy leak in the data flow of a third-party library, but there is no relevant description statement in the privacy policy, there is an "omission of disclosure" violation.
[0055] If there is privacy leakage in the data flow of a third-party library, but the privacy policy only uses vague terms such as "information" and "privacy information" to describe the relevant behavior without clearly indicating the type of information, there is an "ambiguous disclosure" violation.
[0056] If a third-party library's data flow leaks privacy, but the privacy policy doesn't describe any privacy leaks, this constitutes a "false disclosure" violation, and the developer must correct the misrepresentation. For example, dynamic analysis generates a data flow f = (com.fb.ads, location, fb), and the privacy policy contains a privacy practice p = (third party, not collect, personal information). fb is a third party, location is a personal information, but the verb is "not collect." The privacy policy incorrectly discloses TPL's behavior, resulting in a false disclosure issue.
[0057] To detect frequent API call violations by third-party libraries, we count the frequency of each TPL calling different APIs based on the timestamps in Frida's logs. If the frequency exceeds a threshold (e.g., 10 calls per minute), we determine that the third-party library is being called excessively frequently. For example, if the same third-party library calls an API more than 20 times within a minute, this behavior is reported as a violation.
[0058] The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiment. Any equivalent modifications or changes made by ordinary technicians in this field based on the contents disclosed in the present invention should be included in the protection scope recorded in the claims.
[0059] It should be noted that the above content merely illustrates the technical idea of the present invention and cannot be used to limit the scope of protection of the present invention. For ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications all fall within the scope of protection of the claims of the present invention.
Claims
1. A privacy compliance analysis method for a third-party library built into a mobile application, characterized by: include: Step 1: Dynamically test the app using the dynamic analysis module. While collecting and decrypting plaintext traffic, monitor API calls and save traffic and API call log files. Based on the parsed traffic and log files, reverse analyze the app to identify the data flow of the app's built-in third-party libraries. In step 2, the privacy policy analysis module uses a large language model to pre-process the app's privacy policy table, identifying the list of built-in third-party libraries contained in the table and the corresponding privacy information types. Then, it uses natural language processing methods to extract privacy-related behaviors from the app's privacy policy. In step 3, the privacy compliance analysis module compares the results of the dynamic analysis module in step 1 with the results of the privacy policy analysis module in step 2 for the defined violations, and detects privacy compliance issues of the third-party library TPL built into the app.
2. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1 is characterized in that: Step one includes: Use the adb command to install the APP, use a predefined script to start Frida to monitor API calls and their stack information, start mitmproxy to intercept traffic of mobile applications and built-in third-party libraries, analyze the UI interface, and determine whether there is a pop-up window based on the keywords of the pop-up window. If there is a pop-up window, use the NLP sentiment analysis method to determine whether the button control indicates consent. If so, click to skip the pop-up window. If the pop-up window requests the user to grant permission, click ALLOW to grant permission. On this basis, use the dynamic testing tool to dynamically test the APP, identify and agree to the pop-up window again every 10 minutes. After the dynamic testing and traffic generation process is completed, use the har file to save the traffic, and Frida to save the API call monitoring log.
3. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1 is characterized in that: Step one includes: TPL data stream extraction: Identify privacy leaks in third-party libraries in data streams. First, prepare a list of personal privacy information and its values. Then, match this privacy information from the traffic. If a certain personal information pi is extracted from a certain traffic, it is abstracted into a tuple f=(pi,d), indicating that a certain type of personal information pi is sent to the domain name d.
4. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1 is characterized in that: Step one includes: Decompile the APP to obtain the source code. If it is found that the code of a third-party library calls the API related to the pi and uses the domain name d, then the data stream is associated with the TPL, and finally the data stream f=(tpl,pi,d) is generated, indicating that a certain tpl sends a certain type of pi to the domain name d.
5. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1 is characterized in that: Step one includes: Frida logs are analyzed. By analyzing the stack trace, API calls in the app's own code are filtered out, and only API calls in third-party libraries are retained. The log analysis results are expressed as (tpl,api,time), which means that tpl called the api at time.
6. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1 is characterized in that: The privacy policy analysis module includes: Privacy policy preprocessing first uses HTML tags to extract the table in the privacy policy, takes the table and prompt words as the big language input, and then processes the big language output to extract the privacy practice p=(e,c,pi) from the table, where pi represents some personal privacy information, c represents collection / non-collection, and e represents the entity that collects or does not collect personal privacy information.
7. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1 is characterized in that: The privacy policy analysis module includes: Privacy practice extraction: Based on the results of the privacy policy form analysis using a large language model, a series of descriptive statements are generated to describe the third-party libraries built into the mobile app and the types of private information collected. These statements are then merged with the original privacy policy content to extract privacy practices. During extraction, a set of predefined verbs are used to locate privacy policy statements that describe privacy practice behaviors. Then, the named entity recognition method in the NLP field is used to extract privacy practices p=(e,c,pi) from the sentences.
8. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1, characterized in that: The privacy compliance analysis module includes: Definition of violation: This includes three types of violations: privacy leaks in third-party library data flows that are inconsistent with the privacy policy description, and one type of violation: excessively frequent API calls.
9. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1, characterized in that: The privacy compliance analysis module includes: Domain name and entity mapping: The data stream f=(tpl,pi,d) obtained in the dynamic analysis module is used to map domain names and entities. By matching subdomains and predefining a set of domain name and entity mapping tables, the data stream f=(tpl,pi,d) is mapped to f=(tpl,pi,e), which means that a certain tpl sends a certain type of pi to a certain entity e.
10. The privacy compliance analysis method for a third-party library built into a mobile application according to claim 1, characterized in that: The privacy compliance analysis module includes: Compliance analysis: To detect inconsistencies between privacy leaks in third-party library data flows and the privacy policy, the data flow f = (tpl, pi, e) is compared with the privacy practices p = (e, c, pi) obtained from the privacy policy analysis.