Leaking the Privacy of Groups and More: Understanding Privacy Risks of Cross-App Content Sharing in Mobile Ecosystem

Leaking the Privacy of Groups and More: Understanding Privacy Risks of Cross-App Content Sharing in Mobile Ecosystem

Speakers: Jiangrong Wu

Conference: NDSS Symposium

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

Overview

Cross-app content sharing, or Cracs, is a pervasive feature in modern mobile applications, enabling users to effortlessly share content like videos or articles between different platforms. While seemingly convenient and innocuous, this talk by Jiangrong Wu at the NDSS Symposium exposes the significant and often overlooked privacy implications embedded within these sharing mechanisms. The research reveals that Cracs activities can inadvertently expose highly sensitive user data, extending far beyond the scope of traditional web trackers, and impacting both the sharer and the sharee.

The core problem identified is the pervasive violation of the data minimization principle, where shared URLs and underlying app implementations embed excessive user-identifiable information. This practice leads to new avenues for privacy leakage, including the exposure of users' social relations, unnecessary revelation of user identities, and the leakage of associated personal data such as user accounts in other applications. To systematically investigate and quantify these risks, the researchers developed Shark, an automated pipeline combining static and dynamic analysis. Their findings are stark: over 55% of top-downloaded apps in China and 10% in the US exhibit problematic privacy leakage patterns.

This study represents the first in-depth analysis of Cracs' privacy implications, introducing key new understandings and generalizing three distinct privacy-exposure venues found in the wild. Beyond identifying the threats, the research includes a comprehensive user study confirming deep user concerns about these breaches and proposes practical countermeasures for various stakeholders. The insights provided are crucial for users, developers, system vendors, and regulators alike, highlighting a previously underexplored dimension of mobile privacy threats.

Background

▶ Watch: Introduction: Ubiquitous cross-app sharing and privacy risks (0:00)

The technical implementation of Cracs primarily involves transferring a URL that hosts the shared content from a source app (e.g., YouTube) to a target app (e.g., Facebook Messenger). This transfer is facilitated by standard cross-app communication mechanisms, such as Android's Intent via IPC channel. Two main types of SDKs support Cracs: those provided directly by target platforms (like Facebook or Twitter) and third-party SDKs that integrate multiple target app SDKs for developer convenience. In this context, the user initiating the share is the sharer, and the recipient is the sharee.

The fundamental privacy problem lies in the structure of the shared URL itself. Ideally, this URL should contain only an identifier for the content being shared. However, real-world applications frequently embed much more complicated and sensitive data within these URLs. A common example cited is the inclusion of a uid parameter, which can uniquely identify an app user. Such parameters allow the source app to record the viewing interests of both the sender and receiver, enabling persistent tracking beyond the immediate sharing event. This practice directly contravenes the principle of data minimization, a cornerstone of major privacy regulations worldwide, including GDPR, CCPA, and PIPL. These regulations explicitly mandate that personal data collected and processed should be adequate, relevant, and strictly limited to what is necessary for the stated purpose.

Despite the clear violation of data minimization and the potential for significant privacy intrusion, these tracking behaviors within the mobile ecosystem, particularly in the context of Cracs, have remained largely unexplored. The research aims to fill this gap, providing a systematic framework to understand and quantify these risks.

Key Findings

▶ Watch: Shark tool and alarming app privacy leakage findings (1:20)

The research uncovered three distinct patterns of privacy threats in cross-app content sharing, stemming from designs and implementations that violate data minimization and least privilege principles. These patterns are:

1. Sharing Behavior Tracking (SBT): The source app tracks sharing activities between the sharer and sharee, often by implanting a tracker (associated with the sharer's identity) directly into the shared URL. Additionally, when the sharee clicks the shared content, the source app may force a login or redirect to its own app, binding the content-viewing activity to the sharee's identity. This allows the source app to infer social connections and shared interests on the target app.
2. Sharing Data Interception (SDI): An adversary (often a third-party SDK) explicitly intercepts the shared content and user information, sending it to its own server via an unnecessary network request, rather than solely relying on local IPC mechanisms.
3. Sharer Data Exposure (SDE): The shared URL or content itself exposes the sharer's sensitive data, such as user IDs or account names, to the sharee. A privacy-curious sharee can then use this information to construct a URL to the sharer's profile in the source app, potentially accessing their likes, collections, and followers, or even see the username directly displayed on the shared content.

To gauge user perception of these risks, a comprehensive user study with 300 participants in China revealed several critical insights:

• RQ1: Cracs is commonly used. A significant 75% of participants use sharing functions often, and 94.67% share content at least once a month, highlighting the feature's widespread adoption.
• RQ2: Users are not fully aware of data exposure. A large majority (86.33%) stay logged in by default, and many would log in if required to share (59.67%) or view (65.33%) content, indicating a general unawareness of associated privacy implications.
• RQ3: Users place a high value on private data and deem leakage unacceptable. A strong consensus emerged, with 94% perceiving SBT as a leak, 81% for SDI, and 73% for SDE. Critically, 63.67% found it unacceptable for a video app to obtain their social relationships from other social media apps.
• RQ4: Willingness to share drops significantly after understanding implications. Over half (55.33%) of participants would cease sharing to preserve privacy, and among those who would still share, 29.33% felt compelled due to a lack of alternatives. When confronted with login requirements, 40.33% would refuse to log in to share, and 34.67% would refuse to log in to view. This reveals a stark disconnect between current app practices and user expectations.

Through the automated analysis with the Shark pipeline, the researchers evaluated 300 top-downloaded apps (150 from China, 150 from the US). Out of 186 apps featuring sharing functions, 74 exhibited at least one privacy leakage pattern. The prevalence was significantly higher in China, where 67 out of 120 apps with sharing functions (55.83%) were problematic (SBT in 43.33%, SDI in 15.83%, SDE in 21.67%). In contrast, in the US, 7 out of 66 apps (10.60%) were problematic (SBT in 7.57%, SDI in 4.54%, SDE in 1.5%). The study also confirmed that at least 81.69% of the problematic Android apps had similar privacy leakage patterns in their iOS counterparts. Identified trackers included 28 UserIDs, 31 custom identifiers (e.g., 1ch), and 3 IMEI/DeviceIDs, many of which were not explicitly labeled. The research also highlighted two third-party sharing SDKs (SDK-1 and SDK-2) aggressively collecting sharing data, affecting 5 apps with over 1.3 billion downloads, primarily in China.

Technical Deep Dive

▶ Watch: Core problem: Shared URLs embed sensitive user identifiers (2:00)

The privacy threats in Cracs fundamentally arise from designs that disregard data minimization and least privilege principles. The threat model assumes a curious, opportunistic adversary actively collecting sensitive user data not essential for Cracs, which could be the source app, target app, third-party SDKs, or even the sharee. The primary victims are the sharer and sharee, whose identities, personal interests, and social relations are exposed without their explicit consent or awareness.

The three identified patterns of privacy threat operate as follows:

• Sharing Behavior Tracking (SBT): This pattern allows the source app to infer social connections. It manifests in two ways:
• Tracking the sharer: The source app embeds a tracker, often linked to the sharer's identity, directly into the shared URL. This enables persistent tracking of the content in relation to the sharer.
• Tracking the sharee: When the sharee opens the shared content, the source app might force a login or redirect to its own app if already installed, thereby binding the content-viewing activity to the sharee's identity. By associating content with both identities, the source app can infer shared interests and social connections, which should ideally remain confidential. This provides a perfect side channel to infer social relations, mapping friends across platforms or identifying close family members based on shared content patterns.
• Sharing Data Interception (SDI): This involves an adversary explicitly intercepting shared content and user information and sending it to their own server. This is fundamentally unnecessary for Cracs, which should operate locally via system-provided IPC. The talk provides a code example (Listing 1) where a third-party sharing SDK, in addition to invoking the legitimate sharing API, makes an extra network request to send the shared content and user details to its own server.
• Sharer Data Exposure (SDE): In this scenario, the sharing URL or the content itself directly exposes the sharer's sensitive data to the sharee. This could include user IDs or account names from the source app. A sharee could then construct a URL to the sharer's profile in the source app, gaining access to their public activities like likes, collections, and followers. In more egregious cases (Figure 5 from the talk), the sharer's username is directly displayed on the shared content's UI, making it accessible even without technical expertise.

To detect these patterns, the researchers developed Shark, an automated pipeline integrating both static and dynamic analysis to overcome challenges like code obfuscation, side-channel attacks, and the difficulty of identifying custom user identifiers.

Shark's workflow involves:

1. Static Information Extraction: This phase decompiles app code and parses UI resource files to locate sharing buttons and their host activities. It constructs an Activity Transition Graph (ATG) to map feasible paths for triggering sharing. Backward data-flow analysis traces variables related to shared content from sharing APIs to UI elements. To handle obfuscation, Shark extracts obfuscation-resilient API signatures based on method body invariants, Android system-level APIs, parameter types, and data flow information.
2. Dynamic Sharing Activity Trigger: At runtime, Shark explores the app using the ATG, simulates clicks on sharing widgets, and completes the sharing process. It leverages single-sign-on features for automated logins and uses Xposed to hook sharing APIs, extracting shared content links and capturing network traffic via a proxy.
3. Leakage Detection: Specific rules are applied to the collected runtime data to confirm privacy leakage:

• SBT Detection: Shark employs differential analysis. It shares the same content twice with Account A (generating links l1 and l2), compares parameters to derive l3 (the content link without transient user-specific data). Then, the same content is shared with Account B to get l4. If l3 and l4 still differ in parameters, these are flagged as potential user-identifiable information, indicating SBT.
• SDI Detection: Shark checks if the extracted sharing link or associated user information is present in the payload body of captured network traffic that is sent to a server other than the target app's. If the sharing link is unnecessarily transmitted over the Internet, it's flagged as SDI.
• SDE Detection: Using a pre-registered account to share content, Shark inspects the shared link and the UI of the target app for the sharer's username or UID. If explicitly found, it's flagged as SDE.

Shark achieved an 83.15% coverage rate for triggering sharing widgets in tested apps, with its obfuscation-resilient API signature mechanism demonstrating 98.2% precision, proving its effectiveness in real-world app analysis.

Demo / Proof of Concept

▶ Watch: Three distinct privacy threat patterns: SBT, SDI, SDE (4:00)

While the talk did not feature a live demonstration in the traditional sense, the researchers presented compelling case studies that serve as concrete proofs of concept for each identified privacy leakage pattern, illustrating their real-world impact across popular applications.

• App with SBT (App-CN-7): This case study involved a popular video app in China, boasting over 3.6 billion downloads. The researchers demonstrated that when content, such as an HIV-related video, was shared from App-CN-7, the shared link consistently included user trackers like buvid and mid (Figure 9 from the talk). This allows the app to continuously track groups of users interested in specific, sensitive subjects. By correlating these trackers with sharing activities, the app can infer social relations among these users, creating detailed profiles of social circles with particular interests, which can have significant privacy implications, especially for sensitive health information.

• SDK with SDI (SDK-1): The research highlighted SDK-1, a third-party sharing SDK integrated into applications with a cumulative 2.2 billion downloads. This SDK was shown to aggressively collect shared content and sharer identity information, sending it to its own server, rather than solely relying on the legitimate IPC channels for sharing. Figure 10 from the talk presented intercepted network data illustrating this unnecessary data interception. This demonstrates how third-party components, often integrated for developer convenience, can become significant vectors for privacy leakage by exfiltrating user data that is not required for the core sharing functionality.

• App with SDE (App-CN-3): This example focused on another short video app, App-CN-3, with an astounding 7.6 billion downloads. Initially, this app explicitly exposed the sharer's UID within the shared video link and prominently displayed the sharer's username directly on the shared content's user interface. This design flaw enabled any sharee, regardless of technical expertise, to easily identify and profile the sharer, accessing their public activities and potentially inferring their browsing history, likes, and followers. The researchers noted that in an updated version of App-CN-3, the sharer's UI information was no longer presented, indicating an improvement in data practice, likely in response to increased privacy awareness or regulatory pressure. These case studies underscore the practical manifestation and severity of the privacy risks identified by the research.

Defensive Implications

▶ Watch: Profound implications: Inferring user profiles and social relations (6:00)

The findings from this research highlight a critical need for a multi-faceted approach to mitigate the privacy risks associated with cross-app content sharing, involving users, system vendors, and regulators.

For app users, while the immediate burden often falls on them, the primary recommendation for privacy-sensitive individuals is to avoid using app-provided sharing mechanisms that generate trackable links. Instead, users could opt for manually taking screenshots of content and sharing those images. This method effectively makes the sharing untraceable by severing the digital link to the source app's tracking infrastructure. However, this comes with a significant trade-off in usability, requiring more manual operations for both the sharer and the receiver, and losing the interactive benefits of a direct link. Users should also be highly wary of login prompts when sharing or viewing content, as these are frequently used to bind activity to their identity.

System vendors, particularly mobile OS developers, are in a unique position to implement systemic countermeasures. They could intercept sharing links at the framework level and employ filtering mechanisms to automatically strip out known user-identifiable parameters. This approach could significantly reduce the prevalence of SBT and SDE. However, this is not a complete solution, as adversaries might circumvent such filters by embedding trackers as randomized, generic URLs or by mandating a login status that then associates the activity server-side. Continuous research and updates to filtering logic would be necessary.

Finally, regulators and app markets have a crucial role in enforcing better privacy practices. Authorities like the FTC and major app markets (e.g., Google Play, Apple App Store) should explicitly mandate privacy-by-design principles for sharing data. This would require developers to minimize data collection and exposure from the outset. Implementing additional vetting mechanisms during app submission could help identify and block apps exhibiting problematic data patterns like SBT, SDI, and SDE. Stricter policies regarding third-party SDKs, especially those that engage in unnecessary data interception, are also warranted to prevent widespread leakage through common components. The research underscores the urgent need for greater data transparency and a renewed emphasis on data minimization across the entire mobile ecosystem.

Key Takeaways

• Cross-app content sharing (Cracs) poses significant, overlooked privacy risks, extending beyond traditional web tracking to expose social relations, identities, and personal data.
• Three distinct privacy leakage patterns were identified: Sharing Behavior Tracking (SBT), Sharing Data Interception (SDI), and Sharer Data Exposure (SDE), all violating data minimization principles.
• Users are largely unaware but deeply concerned about these privacy breaches, with over 55% willing to forgo sharing to protect their privacy once informed.
• Prevalence of problematic apps is high, with over 55% of top apps in China and 10% in the US exhibiting at least one leakage pattern, highlighting a global issue with regional differences.
• Automated detection tools like Shark are crucial for identifying these stealthy privacy threats by combining static and dynamic analysis, capable of handling obfuscation and complex app interactions.
• Mitigation requires a multi-stakeholder approach, involving user caution, systemic interventions from mobile OS vendors, and stringent enforcement and privacy-by-design mandates from regulators and app markets.

About the Speaker(s)

Jiangrong Wu presented this detailed research at the NDSS Symposium, demonstrating expertise in mobile security and privacy. The talk indicates that Wu is a leading researcher in this field, having spearheaded the investigation into cross-app content sharing privacy risks, developed the automated analysis tool Shark, and conducted a comprehensive user study. Their work highlights a commitment to uncovering and addressing critical, yet often overlooked, privacy vulnerabilities in ubiquitous mobile features.