Towards Privacy-Preserving Social-Media SDKs on Android

Towards Privacy-Preserving Social-Media SDKs on Android

Speakers: Haoran Lu

Conference: USENIX Security '24

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

Overview

In an era where mobile applications are increasingly reliant on third-party libraries, the security and privacy implications of these dependencies have become a critical concern. Haoran Lu's talk, "Towards Privacy-Preserving Social-Media SDKs on Android," addresses a significant vulnerability in the Android ecosystem: the Cross-Library Data Harvesting (XL-DH) attack. This presentation highlights how malicious or compromised SDKs within a single application can illicitly access sensitive user data handled by legitimate social media SDKs, posing substantial privacy risks and legal liabilities for both app developers and SDK providers.

The research presented by Lu, originating from Indiana University Bloomington, introduces a novel architectural design aimed at enhancing the privacy guarantees of social media SDKs on Android without compromising their functionality or requiring modifications to the Android operating system. By proposing a system that ensures controlled data flow, utilizes privacy-preserving UI components, and implements a public, auditable policy mechanism, this work offers a robust solution to mitigate XL-DH attacks. It provides a blueprint for a more secure and transparent mobile app ecosystem, particularly for handling personally identifiable information (PII) and credentials.

The talk underscores the urgent need for improved isolation mechanisms beyond what current solutions, such as the Android Privacy Sandbox, offer. It demonstrates a practical approach to protecting user data from internal threats within the app process, ensuring compliance with stringent privacy regulations like GDPR and CCPA. This research is pivotal for any organization involved in mobile app development, third-party SDK integration, or those concerned with safeguarding user privacy in the complex software supply chain of Android applications.

Background

▶ Watch: Introduction: Problem of Cross-Elaborate Data Harvesting (0:00)

The pervasive integration of third-party SDKs into mobile applications has become a cornerstone of modern app development. Data from 2018 indicates that an average Android app incorporates approximately 18 SDKs, reflecting the widespread reliance on these components for various functionalities, from analytics to advertising and social media integration. While these SDKs streamline development, they also introduce significant security vulnerabilities, particularly the Cross-Library Data Harvesting (XL-DH) attack.

The XL-DH attack exploits the lack of isolation between co-located SDKs within the same Android application. In this scenario, a legitimate social media SDK (e.g., Facebook, Twitter) runs alongside a malicious or compromised third-party library. Due to Android's default security model, which grants all components within an app process the same privileges, the malicious library can easily call APIs provided by the social SDK and harvest sensitive user data. A notable incident in 2021 revealed that XL-DH attacks affected over 19,000 apps, accumulating more than 9 billion downloads, with one malicious library, "One Audience," specifically targeting data from Facebook and Twitter SDKs.

Social media SDKs are particularly vulnerable targets because they handle highly sensitive user data, including personally identifiable information (PII) such as email addresses, first names, last names, contact lists, and even user credentials and photos. The theft of such data not only compromises user privacy but also exposes social SDK owners and app developers to severe legal and compliance issues, including fines under regulations like GDPR (General Data Protection Regulation), CCPA (California Consumer Privacy Act), and penalties from the FTC (Federal Trade Commission).

Combating XL-DH attacks presents several challenges:

1. Difficulty in Isolation: It is extremely challenging to isolate all potentially malicious libraries from social SDKs. Many third-party SDKs, such as RX Android and EventBus, serve as essential development components (e.g., for asynchronous functions or message passing), making their removal or strict isolation impractical for developers.
2. Supply Chain Complexity: The intricate software supply chain makes it difficult to predict which libraries might be malicious or to detect all potential threats. Developers often integrate libraries that, in turn, depend on other libraries, creating a complex web of dependencies where vulnerabilities can easily hide.
3. Limitations of Existing Solutions: Current privacy-enhancing solutions, including the Android Privacy Sandbox, face significant limitations. The Android Privacy Sandbox, in its current state, primarily focuses on supporting advertising-related libraries. While it creates a dedicated SDK runtime process for ad libraries, its design does not adequately address the data flow from this SDK runtime back to the main app process. This means sensitive user information from social SDKs could still be accessed by malicious libraries operating within the app process. Furthermore, the Privacy Sandbox's design does not support complex interactive use cases common to social media SDKs, such as Facebook Login or detailed profile interactions, which involve more than just serving ads. These limitations highlight a critical gap in protecting sensitive PII within non-advertising SDKs.

This background establishes the urgent need for a more comprehensive and robust solution that can provide strong privacy guarantees for social media SDKs while maintaining their full functionality and ensuring compatibility with the existing Android ecosystem.

Key Findings

▶ Watch: Limitations of Android's Privacy Sandbox for social SDKs (3:20)

The core problem identified by Haoran Lu's research is the inherent vulnerability of sensitive user data within social media SDKs to Cross-Library Data Harvesting (XL-DH) attacks due to insufficient isolation mechanisms in the Android ecosystem. Existing solutions, including the Android Privacy Sandbox, are not designed to adequately protect complex, data-rich social media interactions from co-located malicious or compromised SDKs.

To address this, the research proposes a novel design for privacy-preserving social media SDKs on Android, guided by three primary goals:

1. Enhance Privacy: Significantly improve the privacy guarantees for sensitive user data handled by social media SDKs.
2. Maintain Functionality: Ensure that all existing functionalities and user cases of social media SDKs (e.g., login, profile display, sharing) remain fully supported and unimpaired.
3. Facilitate Legal Compliance: Provide a framework that helps social SDK owners and app developers comply with stringent privacy laws and regulations like GDPR and CCPA, mitigating legal risks.

To achieve these goals, the design is built upon two fundamental principles:

1. Isolation: Similar to the Android Privacy Sandbox, a dedicated SDK runtime is created where social media SDKs operate. However, a critical enhancement is implemented: controlled data flow. This ensures that sensitive social data never flows directly into the main app process, preventing malicious libraries from accessing it.
2. Compatibility: To preserve existing functionalities and user experiences, a privacy-preserving UI component is introduced. This component ensures that complex user interactions can still occur, and sensitive information can be displayed to the user, without the app process itself gaining unauthorized access to that data.

The research introduces several key architectural components to realize this design:

• OpDataHandle: A mechanism that allows referencing sensitive information without providing direct data access.
• Sensitive Module Sandbox: An isolated process for injecting developer code that needs access to sensitive data, but with strictly controlled outbound data flow.
• Privacy-Preserving UI Component: A compartmentalized UI element that leverages Android's Surface Control to display sensitive data to the user while keeping it inaccessible to the embedding application.
• Public Accessible Policy: A novel policy file hosted by SDK owners that defines, controls, and makes auditable the data collection and flow processes.

The evaluation of this proposed system focuses on three critical metrics:

1. Property Maintenance: Verifying that the design effectively maintains the intended privacy properties, particularly regarding data isolation and controlled flow.
2. Use Case Preservation: Conducting case studies on popular SDKs like Facebook SDK and Twitter SDK to confirm that all existing user cases are fully supported without degradation. The data and code from these case studies are made publicly available.
3. Performance Assessment: Measuring the overhead introduced by the new architecture to ensure that the system does not incur unacceptable latency or degrade the user experience.

These findings collectively demonstrate a viable and effective approach to securing social media SDKs against XL-DH attacks, offering a significant step forward in mobile application privacy.

Technical Deep Dive

▶ Watch: Proposed design goals and principles for privacy (4:40)

The proposed privacy-preserving architecture for social media SDKs on Android is meticulously designed to operate on Android 13 without requiring any modifications to the underlying operating system. This ensures broad compatibility and ease of adoption for developers and SDK providers. The core of this design revolves around several key technical components that collectively enforce isolation and controlled data flow while maintaining full functionality.

1. OpDataHandle:

At the foundation of controlled data access is the OpDataHandle. This concept, adopted from previous research in privacy-enhancing techniques, is essentially a pointer to sensitive information without providing actual data access. Instead of directly passing sensitive data (like a user's email or access token) between processes, the system passes an OpDataHandle. When the app process needs to interact with this data, it can only do so through predefined, controlled interfaces that operate on the OpDataHandle within the secure SDK runtime. This prevents the app's potentially malicious components from directly reading or copying the raw sensitive data.

1. Sensitive Module Sandbox:

The system introduces a Sensitive Module Sandbox, which is an isolated process specifically designed to allow developers to inject their own custom code logic. This code logic might require access to sensitive information for specific operations, such as custom data processing or analytics that must occur on the device. Crucially, within this sandbox, all data flows are still strictly controlled. This ensures that even though the injected code has temporary, limited access to sensitive data, this data cannot flow out of the sandbox into the main app process or even the broader SDK runtime without explicit, policy-driven permission. This compartmentalization prevents a compromised developer module from becoming an exfiltration point.

1. Privacy-Preserving UI Component:

Perhaps the most innovative aspect for user interaction is the Privacy-Preserving UI Component. This component addresses the challenge of displaying sensitive information (e.g., a login screen, a user's profile picture, or a list of friends) to the user while simultaneously preventing the embedding application's code from accessing or manipulating that displayed data.

• It achieves this through compartmentalization of the UI component, leveraging the Surface Control mechanism provided by Android. Surface Control allows different processes to render directly onto specific regions of the screen without sharing their underlying pixel buffers or input events with other processes.
• In practice, this means that the sensitive UI elements (e.g., the username and password fields in a Facebook login dialog, or the user's profile picture and name) are rendered directly by the enhanced social media SDK within its isolated runtime. The main app process, while hosting the overall UI, only sees a "greyed-out" or placeholder area where the sensitive UI component is displayed.
• The user interacts directly with the UI rendered by the SDK's runtime, providing input (like typing credentials) directly to the secure process. The app developer's code does not have any access to the information shown on the screen in these sensitive areas. This allows users to complete login flows or view their profiles normally, while guaranteeing that the app cannot snoop on their input or screen content.

1. Public Accessible Policy:

A cornerstone of transparency, accountability, and control in this design is the public accessible policy file. This file is not embedded within the app or the SDK but is instead hosted and maintained by the social SDK owners (e.g., Facebook, Twitter) on their public servers. By providing such a policy file, the system fulfills three key properties:

• Deterministic Data Collectors: The policy file explicitly defines the destination of data flow for sensitive social information. The social media SDK and the app developer collaboratively define where specific pieces of data (e.g., user ID, email) are permitted to go. This ensures that any data collector is known and that data flow is predictable, significantly increasing transparency in the data collection process.
• Controllable Data Collectors: The policy enables both the app developer and the SDK owner to control what kind of data is needed and what kind of data is provided. For instance, a policy might dictate that Twitter can only provide a user ID and email, while Facebook can only provide an access token. This fine-grained control allows app owners to specifically request and SDKs to specifically provide only the data necessary for a particular functionality, aiding compliance with privacy laws.
• Auditable Data Collectors: Because the policy file is publicly hosted and accessible, anyone on the internet can download and audit it. This public auditability ensures that the policy adheres to privacy laws and best practices. It provides fine-grained, public accountability and transparency in data practices, fostering trust and enabling external oversight.

The evaluation of this technical architecture focused on its practical implications. Performance assessments, specifically for use cases like "login with Facebook," "display user profile," and "login with Twitter," showed minimal overhead. For a single social SDK running in a single app, the highest observed delay was around 72 milliseconds. Even with multiple social SDKs running concurrently across multiple apps, delays remained consistently under 100 milliseconds. These figures are considered acceptably low, ensuring that the user experience is not negatively impacted by the enhanced security measures.

This robust technical framework provides a comprehensive solution to the XL-DH problem, offering strong privacy guarantees without sacrificing the rich functionality users expect from social media integrations.

Demo / Proof of Concept

▶ Watch: Demo of privacy-preserving UI for sensitive data (6:40)

While the talk doesn't detail a live, interactive demonstration, it clearly describes the implementation and evaluation of the proposed design as a proof of concept (PoC). The speaker references a "demo screenshot" to illustrate a key aspect of the Privacy-Preserving UI Component. This screenshot visually represents how "greyed areas UI and sensitive information are provided by the enhanced Facebook SDK," effectively demonstrating that the app itself "does not have any access to it." This visual evidence confirms that the user can still perceive and interact with the UI normally for tasks like login or profile viewing, while the underlying sensitive data remains isolated from the app's code.

Furthermore, the research conducted a comprehensive case study on Facebook SDK and Twitter SDK, which serves as a practical demonstration of the system's capabilities. This case study aimed to validate two critical aspects: maintaining existing user cases and assessing performance overhead. By implementing the privacy-preserving design for these widely used social media SDKs, the researchers showed that functionalities such as "login with Facebook," "display user profile," and "login with Twitter" could be fully supported within the new architecture. The fact that "all the data online" was released for this case study further implies a functional implementation that could be inspected and replicated.

The evaluation results, particularly the low latency figures (e.g., 72 milliseconds for the highest delay in a single-SDK scenario, and consistently under 100 milliseconds for multiple SDKs), provide concrete evidence that the PoC is not only functional but also performs efficiently enough for real-world deployment. This practical demonstration, through implementation and rigorous evaluation, confirms the feasibility and effectiveness of the privacy-preserving social media SDK design.

Defensive Implications

▶ Watch: Crucial public accessible policy for data control (7:20)

The design presented in "Towards Privacy-Preserving Social-Media SDKs on Android" carries significant defensive implications for various stakeholders in the mobile application ecosystem. Its adoption can fundamentally shift how sensitive user data is handled, offering robust protection against Cross-Library Data Harvesting (XL-DH) attacks and improving overall data governance.

For Social Media SDK Owners (e.g., Facebook, Twitter):

• Mitigation of XL-DH Attacks: By moving sensitive data handling and UI rendering into an isolated SDK runtime and utilizing an OpDataHandle for controlled access, SDK owners can effectively prevent malicious libraries within the same app from directly accessing or exfiltrating user PII. This directly addresses the attack vector responsible for compromising billions of downloads.
• Enhanced Legal Compliance: The framework's design, particularly the Public Accessible Policy, directly aids compliance with stringent privacy regulations such as GDPR and CCPA. The ability to define deterministic and controllable data collectors ensures that SDKs only handle data in accordance with user consent and legal requirements. This significantly reduces the risk of legal penalties and reputational damage associated with data breaches.
• Increased Transparency and Accountability: Hosting a public, auditable policy file allows SDK owners to clearly communicate their data collection practices. This transparency fosters user trust and provides a mechanism for external auditing, ensuring accountability in data handling.
• Maintaining Functionality: Crucially, the design ensures that existing functionalities like user login and profile display are preserved through the Privacy-Preserving UI Component. This means SDK owners can implement enhanced security without forcing developers or users to adapt to degraded experiences.

For App Developers:

• Reduced Liability and Risk: By integrating privacy-enhanced social SDKs, app developers can significantly reduce their exposure to liability stemming from data breaches caused by third-party SDKs. They can assure users that sensitive data handled by social logins is protected, even if other components within their app are compromised.
• Improved User Trust: Apps that visibly adopt strong privacy-preserving measures are likely to gain more user trust. This can be a significant competitive advantage in a market increasingly sensitive to data privacy.
• Simplified Compliance: While the SDK owners manage the policy, developers benefit from a clearer, more controlled interface for data interaction, simplifying their own efforts to comply with data privacy regulations.

For the Android Platform and Ecosystem:

• Compatibility and Enhancement of Android Privacy Sandbox: The research highlights that this design is compatible with the current Android Privacy Sandbox and can provide "substantial improvements on privacy assurance." This suggests a potential path for Google to extend the robust privacy guarantees of the Sandbox beyond advertising to other sensitive SDK categories.
• Broader Applicability: The speaker emphasizes that the design is not limited to social media SDKs but can "provide privacy assurance for any SDKs that provide data." This broad applicability suggests a universal framework for securing data-providing SDKs, potentially leading to a more secure and privacy-centric Android ecosystem overall.
• Standardization Potential: The proposed components and principles could serve as a blueprint for future Android platform features or industry standards for secure SDK integration, promoting a consistent approach to data protection across all third-party libraries.

In essence, this work provides a practical, technically sound, and legally beneficial framework for defending against a prevalent and dangerous form of data exfiltration in mobile applications. Its adoption would mark a significant step towards a more secure and trustworthy mobile experience for users.

Key Takeaways

• Cross-Library Data Harvesting (XL-DH) Attacks are a Critical Threat: Malicious or compromised SDKs co-located within an Android app can easily steal sensitive user data from legitimate social media SDKs, impacting billions of downloads and posing severe privacy risks.
• Existing Android Security Mechanisms are Insufficient: The current Android Privacy Sandbox is primarily focused on advertising and lacks the necessary isolation and complex interaction support to protect sensitive PII handled by social media SDKs.
• Novel Design for Enhanced Privacy: The proposed solution introduces a new architecture based on strong isolation (dedicated SDK runtime, Sensitive Module Sandbox) and controlled data flow via OpDataHandle to prevent sensitive data leakage to the main app process.
• Privacy-Preserving UI is Key to Functionality: A unique Privacy-Preserving UI Component, leveraging Android's Surface Control, allows users to interact with sensitive data (e.g., login screens) without the app's code gaining access to the displayed information, preserving functionality while enhancing security.
• Public, Auditable Policies Ensure Transparency and Control: A Public Accessible Policy file, hosted by SDK owners, defines deterministic and controllable data flows, making data collection practices transparent and auditable for compliance with privacy regulations like GDPR and CCPA.
• Minimal Performance Overhead and Broad Compatibility: The design introduces negligible performance delays (under 100 milliseconds) and is compatible with Android 13 without OS modifications, offering a practical solution that can extend beyond social media SDKs to protect any data-providing third-party library.

About the Speaker(s)

Haoran Lu is the presenter of the talk "Towards Privacy-Preserving Social-Media SDKs on Android." He is affiliated with Indiana University Bloomington, where this research work was conducted. The specific role or department within the university is not detailed in the provided transcript or metadata.