Withdrawing is believing? Detecting Inconsistencies Between Withdrawal Choices and Third-party Data Collections in Mobile Apps

Withdrawing is believing? Detecting Inconsistencies Between Withdrawal Choices and Third-party Data Collections in Mobile Apps

Speakers: Xiaolin Du, Zhemin Yang, Jiapeng Lin, Yinzhi Cao, Min Yang

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=4pKKJnC6y6o

Overview

This talk, presented at IEEE S&P by a collaborative team from Fudan University and Johns Hopkins University, delves into a critical yet often overlooked aspect of mobile application privacy: withdrawal inconsistencies. The research highlights a significant gap between users' explicit choices to withdraw consent for data collection and the actual data practices of mobile apps, particularly concerning third-party libraries. As global privacy regulations like GDPR and CCPA empower consumers with the right to object to or opt out of personal data processing, violations of these rights can lead to severe user privacy leakage. The talk introduces M Checker, a novel static analysis tool designed to automatically detect these inconsistencies in Android applications.

The core problem identified is that while users may request a complete cessation of data collection by third-party services, certain data flows often remain "unguarded" and continue to transmit sensitive information. This discrepancy erodes user trust and potentially exposes individuals to unwanted tracking and profiling. The presenters emphasize that existing research primarily focuses on website inconsistencies or general privacy leakage detection in mobile apps, leaving a significant void in understanding and addressing the specific challenges of withdrawal options in the mobile ecosystem. Their work provides a systematic study of this problem, offering both a technical solution and a large-scale empirical analysis of its prevalence and impact.

Background

▶ Watch: Introduction, privacy regulations, and mobile app inconsistencies (0:00)

The landscape of digital privacy has been significantly reshaped by comprehensive regulations such as the European Union's General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). GDPR, for instance, enshrines the "right to object," allowing consumers to withdraw consent for the processing of their personal information. Similarly, CCPA grants consumers the "right to opt-out," enabling them to request that businesses do not sell or share their personal information. These regulations are designed to provide users with greater control over their data, and non-compliance can result in substantial penalties and reputational damage.

Despite these legal frameworks, the practical implementation of privacy choices, especially in the complex mobile app ecosystem, presents considerable challenges. Mobile applications frequently integrate numerous third-party libraries for functionalities like analytics, advertising, and crash reporting. These libraries often collect extensive user data, creating intricate data flows that are difficult for app developers to fully monitor and control, let alone for users to comprehend. Previous research has explored privacy inconsistencies on websites, where user choices regarding cookies or tracking might not always align with actual data practices. Other studies have focused on general privacy leakage detection in mobile apps, often examining the correlation between user consent and app behavior without specifically addressing the dynamic nature of withdrawal options.

The unique complexity of mobile app withdrawals stems from several factors. User interfaces for withdrawal can be convoluted, involving multiple toggles or checkboxes. More critically, the underlying mechanisms for stopping data collection by third-party libraries are diverse. A withdrawal request might involve invoking a specific API provided by the third-party SDK (e.g., SDK.disableAnalytics()), or it might rely on setting a "guarding condition" variable that prevents data transmission. The research highlights a critical vulnerability: even when an app intends to honor a withdrawal, some data collections might be missed, leading to what the researchers term an unguarded collection. For example, a user might opt-out of all analytics, and the app correctly disables most third-party tracking, but a specific event logger within a Firebase SDK might continue to transmit data without being subject to the withdrawal condition. This fundamental disconnect between user expectation, app developer intent, and the actual behavior of third-party components forms the core problem addressed by this research.

Key Findings

▶ Watch: Two types of withdrawal mechanisms: uncooperated and cooperated (2:50)

The research conducted a comprehensive, large-scale evaluation of withdrawal inconsistencies across a vast dataset of Android applications, revealing significant and concerning findings. The primary discovery is the widespread prevalence of these inconsistencies: 39.4% of apps containing withdrawal options were found to be inconsistent. This means that a substantial portion of mobile applications fail to fully honor users' requests to cease data collection, even when explicit withdrawal mechanisms are provided.

Delving deeper into the data, the study differentiated between high-profile and long-tail applications. In the high-profile dataset, comprising top apps from major categories in the United States and Germany, 50.5% of apps exhibited withdrawal inconsistencies. This figure underscores that even widely used and well-resourced applications are not immune to this privacy flaw. While the long-tail dataset showed a slightly lower rate of 31.65% inconsistency, the overall trend is clear: the problem is pervasive across the mobile app ecosystem.

Further analysis elucidated the nature of these inconsistencies:

• Deceptive Descriptions: Over 50% of the withdrawal options were found to be "totally deceptive," often using confusing language like "and I do not sell my personal information." Such phrasing can mislead users into believing their data will not be shared, even when it continues to be collected by third parties.
• Multiple Third-Party Libraries: On average, each inconsistent withdrawal option failed to correctly withdraw data from 1.3 third-party libraries. This indicates that the complexity of managing multiple SDKs is a significant contributing factor to the problem. The study found that over 75% of withdrawal options involved fewer than three third-party libraries, suggesting that even a small number of integrations can introduce considerable risk.
• Affected Data Types: The most frequently affected personal data type was user data, accounting for 19.9% of inconsistencies. This category encompasses highly sensitive information used for tracking user behaviors and preferences, such as gender, political views, location, and user interactions. This highlights the direct impact on user profiling and targeted advertising.
• Involved Third-Party Libraries: The inconsistencies primarily involved analytics libraries (26.4%) and advertising libraries (19%). Prominent examples cited include Firebase Analytics and InMobi. This confirms that the primary beneficiaries of these unguarded collections are services focused on understanding and monetizing user behavior.

The automated detection tool, M Checker, demonstrated strong performance in identifying these issues. In a manually verified ground truth dataset of 100 withdrawal options, M Checker achieved an accuracy of 82.86% and a recall of 90.63%. Specifically, it identified 35 withdrawal inconsistencies, with 29 of them being true positives. This validates the effectiveness of the proposed static analysis approach in practical scenarios. The analysis time for M Checker averaged 286 seconds per application, with a median of 178 seconds, indicating its scalability for large-scale assessments.

In summary, the key findings paint a stark picture: mobile app privacy choices are frequently undermined by persistent, unguarded data collections, driven by complex third-party integrations and sometimes deceptive user interfaces. This not only violates privacy regulations but also erodes user trust, making the development of robust detection mechanisms like M Checker critically important.

Technical Deep Dive

▶ Watch: Phase 1: Identifying complex withdrawal interfaces in apps (4:00)

The core of this research is M Checker, a novel static analysis framework designed to automatically detect inconsistencies between a user's withdrawal choices and actual third-party data collections in mobile applications. M Checker operates in three distinct phases: identifying withdrawal interfaces, detecting privacy data collection data flows, and finally, checking for inconsistencies.

Phase 1: Identifying Withdrawal Interfaces

The first challenge for M Checker is to accurately identify the user interface elements that allow users to express their withdrawal choices. These interfaces are often complex, but the researchers observed two key features:

1. UI Elements: Mobile withdrawal interfaces typically utilize standard UI components that allow users to switch choices, such as checkboxes and switch preferences. M Checker leverages this by analyzing the app's layout files to locate these interactive elements.
2. Keywords and Grammatical Patterns: Withdrawal interfaces almost always contain specific phrases related to data collection or sharing. Examples include "disclosure of your personal information" or "share this data with certain parties."

Based on these observations, M Checker employs a two-pronged approach:

• Keyword Search: It collects a list of common state-related phrases from Android documentation and other sources. M Checker then searches for these phrases within the app's resource files as initial candidates for withdrawal interfaces.
• Grammatical Pattern Matching: The researchers manually summarized grammatical patterns indicative of withdrawal semantics (e.g., "send my personal information to advertisers"). M Checker then identifies candidates that conform to these pre-defined grammatical structures, refining the initial set of potential withdrawal interfaces.

Phase 2: Detecting Privacy Data Collection Data Flows

Once potential withdrawal interfaces are identified, M Checker needs to understand where and how personal data is collected and transmitted. This phase focuses on extracting data collection APIs and tracing the flow of sensitive data.

• API Extraction: A semi-automatic approach is used to extract all relevant data collection APIs from the Java documentation of common third-party libraries. This involves manually generating API definition files that record the collection types associated with each API.
• Privacy Data Flow Detection: M Checker then employs techniques similar to existing data flow analysis tools, such as FlowDroid, to detect all privacy data collection data flows within both the app's own code and its integrated third-party libraries. This involves tracking how sensitive data (e.g., user identifiers, location, usage data) originates within the app and flows towards network transmission points or storage mechanisms, especially those linked to third-party SDKs. The paper provides further technical details on this process.

Phase 3: Inconsistency Check Phase

This is the most critical phase, where M Checker analyzes the correlation between user withdrawal choices and the detected data flows to identify inconsistencies. This phase consists of two main components:

1. Flow-to-Choice Correlation Analyzer

This component uses Multi-Source Bidirectional Data Analysis to establish a link between withdrawal interfaces and the actual data collection behaviors.

• Guarding Conditions: The primary mechanism for apps to honor withdrawals is through guarding conditions. These are variables (often booleans) whose state is controlled by the withdrawal choice and which, in turn, control whether a data collection API is invoked. M Checker performs a forward data flow analysis to track the influence of the withdrawal choice (e.g., an opt_state variable from a UI switch) to the guarding variable. For example, if opt_state is set to false, a forward analysis tracks this to ensure it correctly disables a privacy collection in a later line of code.
• "Catch the Field" Concept: The researchers found that some withdrawal-related fields might not directly control the opt_state variable but instead influence other intermediate variables or "catch fields" (e.g., catch_opt_in_field) which then control the option states. To address this, M Checker employs backward data flow analysis. If a guarding condition is found, a backward analysis can trace its dependencies back to the initial fields controlled by the withdrawal choice, even if indirect.
• Bidirectional Identification: M Checker first identifies all withdrawal fields, tracing paths from withdrawal options to storage and marking all relevant values. It then records the privacy data flows that are guarded by these withdrawal fields as the "withdrawn behaviors."
• Direct API Invocations: In addition to guarding conditions, M Checker also identifies withdrawals that directly invoke third-party APIs (e.g., SDK.disableAnalytics()). This is done by checking data flow dependencies to locate correlated data flows of third-party withdrawal APIs.

2. Intention-to-Behavior Checker

This component matches the semantic intent of the user's withdrawal choice with the actual withdrawn data behaviors. A significant challenge here is matching cross-component statements with differing data flows. The researchers address this using a data ontology map.

• Data Ontology Map: This map serves as a standardized vocabulary to bridge the gap between how data types are described in withdrawal interfaces (e.g., "personal data") and how they are handled in code (e.g., location, ad_IDs, usage_data). For example, M Checker maps "personal data" to specific data types like location information, advertising IDs, and usage data.
• Matching and Inconsistency Detection: By using this map, M Checker can compare the data types that the user intended to withdraw (based on the UI text and the ontology map) with the data types that were actually withdrawn (based on the Flow-to-Choice Correlation Analyzer). If a data type that should have been withdrawn is still detected in an unguarded collection, an inconsistency is flagged. For instance, if the user withdraws "usage data" and "advertising IDs" via the UI, M Checker matches this intent with the actual withdrawn data. If usage data is correctly withdrawn but advertising IDs continue to be collected, an inconsistency is reported.

This multi-stage, sophisticated static analysis approach allows M Checker to systematically dissect complex mobile app code, understand user privacy choices, and pinpoint precise instances where these choices are not being honored, providing a robust tool for detecting withdrawal inconsistencies.

Demo / Proof of Concept

▶ Watch: Overall workflow for checking withdrawal inconsistencies (6:15)

The practical effectiveness of M Checker was rigorously evaluated through a large-scale privacy auditing study of real-world mobile applications on Google Play. This evaluation served as both a demonstration of the tool's capabilities and a comprehensive proof of concept for the prevalence of withdrawal inconsistencies.

The study, conducted in January 2023, involved crawling two distinct batches of data:

1. High-Profile Data Site: This batch comprised the top 500 apps from each category in both the United States and Germany. This resulted in a substantial dataset of 22,725 apps, representing applications with significant user bases and likely higher development resources.
2. Long-Tail Data Site: To ensure broader coverage, an additional 50,000 randomly crawled apps were collected, specifically excluding those already present in the high-profile set. This "long-tail" dataset aimed to capture the behavior of a wider range of developers and less popular applications.

To establish ground truth and validate M Checker's performance, the researchers randomly sampled 100 withdrawal options from the evaluated apps. These options were then manually verified for inconsistencies. This manual review identified 32 inconsistent options and 15 undecidable options (where the inconsistency could not be definitively confirmed or denied through manual inspection).

Against this ground truth, M Checker demonstrated strong performance metrics:

• Accuracy: M Checker achieved an overall accuracy of 82.86%.
• Recall: It exhibited a high recall rate of 90.63%, indicating its effectiveness in identifying most of the true inconsistencies.
• True Positives: Out of 35 identified inconsistencies, 29 were confirmed as true positives, further validating the tool's precision.

The research also provided insights into the runtime performance of M Checker. The analysis time per application varied, ranging from 17 seconds to 44 minutes, with an average analysis time of 286 seconds and a median of 178 seconds. The most time-consuming phases were identified as privacy data flow detection and inconsistency checking, primarily due to the intensive data flow analysis required. This performance profile suggests that M Checker is scalable enough for large-scale audits, making it a viable tool for continuous monitoring or regulatory compliance checks.

Beyond the tool's performance, the large-scale evaluation provided compelling statistical evidence of the problem's scope:

• Overall Inconsistency Rate: 39.4% of apps containing withdrawal options were found to be inconsistent.
• High-Profile vs. Long-Tail: 50.5% of apps in the high-profile dataset had inconsistencies, compared to 31.65% in the long-tail dataset.
• Affected Data and Libraries: The demo/proof of concept further revealed that user data (19.9%) was the most affected data type, and analytics libraries (26.4%) such as Firebase Analytics and advertising libraries (19%) like InMobi were the primary culprits.

This comprehensive evaluation not only showcased M Checker's technical capabilities but also provided a robust, data-driven understanding of the prevalence and nature of withdrawal inconsistencies in the mobile app ecosystem, underscoring the urgency of addressing this privacy challenge.

Defensive Implications

▶ Watch: How MoChecker matches withdrawal intentions with actual behaviors (9:20)

The findings from this research carry significant defensive implications for various stakeholders within the mobile app ecosystem, including app developers, third-party library providers, users, and privacy regulators. The widespread prevalence of withdrawal inconsistencies necessitates a proactive and multi-faceted approach to safeguard user privacy.

For App Developers:

• Comprehensive Auditing: Developers must move beyond simply integrating SDKs and assume their privacy settings are correctly configured. They should regularly audit their applications, particularly after integrating or updating third-party libraries, to ensure that all data collection flows are correctly governed by user withdrawal choices. Tools like M Checker can be invaluable for automated detection.
• Clearer UI and Semantics: The research highlighted deceptive descriptions in withdrawal options. Developers should prioritize clear, unambiguous language in their privacy UIs, ensuring that users fully understand what data will and will not be collected upon withdrawal.
• Robust Guarding Mechanisms: Implement robust guarding conditions that are thoroughly tested across all potential data flows. This includes ensuring that "catch fields" and indirect dependencies are also accounted for.
• SDK Management: Carefully review the privacy implications and documentation of every third-party SDK integrated. Understand how each SDK handles user consent withdrawal and ensure that the app's implementation correctly invokes the necessary APIs or sets the appropriate flags to cease data collection.
• Internal Training: Educate development teams on the nuances of privacy regulations and the technical challenges of managing data flows, especially with third-party components.

For Third-Party Library Providers:

• Transparent APIs: SDK providers should offer clear, well-documented APIs for managing user consent and withdrawal. These APIs should be reliable and ensure that all data collection, including logging and analytics, truly ceases when a withdrawal is invoked.
• Granular Control: Provide app developers with more granular control over data collection within their SDKs, allowing for specific data types or features to be disabled independently.

For Mobile Operating System Vendors (e.g., Google, Apple):

• Enhanced API Visibility: Consider offering enhanced APIs or frameworks that provide developers with greater visibility and control over data flows generated by third-party SDKs, potentially even at the OS level.
• Developer Guidelines: Enforce stricter guidelines and provide better tools for developers to ensure compliance with privacy regulations regarding withdrawal mechanisms.

For Users:

• Critical Evaluation of Options: Users should be aware that even when they opt-out or withdraw consent, their data might still be collected. They should critically evaluate the language used in privacy settings.
• Advocacy and Reporting: If users suspect their withdrawal choices are not being honored, they should report such instances to the app developers and relevant regulatory bodies.

For Privacy Regulators and Researchers:

• Automated Compliance Tools: Tools like M Checker can be adapted and integrated into regulatory compliance checks, allowing for large-scale, automated auditing of mobile applications. This can significantly enhance the enforcement capabilities of privacy regulations.
• Updating Guidelines: The findings provide concrete evidence to update and refine regulatory guidance on how mobile apps must handle user data withdrawal, especially concerning third-party libraries.

Ultimately, addressing withdrawal inconsistencies requires a concerted effort across the mobile ecosystem. Developers must adopt more rigorous privacy-by-design principles, SDK providers must offer more robust consent management features, and regulators must leverage advanced tools to ensure accountability. Failure to do so risks further eroding user trust and undermining the intent of critical privacy legislations.

Key Takeaways

• Widespread Inconsistencies: A significant portion of mobile apps (39.4% overall, 50.5% in high-profile apps) fail to honor user data withdrawal choices, leading to "unguarded collections" by third-party libraries.
• Deceptive Practices: Over 50% of withdrawal options use confusing or deceptive language, misleading users about the true extent of data collection cessation.
• Third-Party Library Impact: The problem is primarily driven by complex integrations with third-party analytics and advertising libraries (e.g., Firebase Analytics, InMobi), which continue to collect sensitive user data despite withdrawal requests.
• Sensitive Data Affected: The most commonly affected data type is "user data" (19.9%), encompassing highly personal information used for tracking behaviors, preferences, and location.
• M Checker's Effectiveness: The M Checker static analysis tool effectively detects these inconsistencies, demonstrating 82.86% accuracy and 90.63% recall in identifying violations.
• Call for Action: The research highlights an urgent need for app developers to conduct thorough privacy audits, for third-party SDK providers to offer better consent management APIs, and for regulators to leverage automated tools for compliance enforcement.

About the Speaker(s)

The research presented was a collaborative effort by Xiaolin Du, Zhemin Yang, Jiapeng Lin, Yinzhi Cao, and Min Yang. The work specifically involved contributions from researchers affiliated with Fudan University and Johns Hopkins University. While the talk did not delve into specific individual biographies, the collaboration between these academic institutions underscores the rigorous scientific approach and expertise in computer science and security that underpins this significant study on mobile app privacy.