Bad Diagnosis: Analyzing Consent and Data Collection Practices of Mobile Medical Apps

1

Bad Diagnosis: Analyzing Consent and Data Collection Practices of Mobile Medical Apps Ethan Myers∗ , Lorenzo De Carli† , Shantanu Sharma‡ Ritwik Banerjee§ Joel Reardon‡ Indrakshi Ray∗ ∗ Colorado State University, USA. † New Jersey Institute of Technology, USA. ‡ University of Calgary, Canada. § Stony Brook University, USA.

arXiv:2610.23851v1 [cs.HC] 16 Oct 2026

✦

Abstract—Mobile health (mHealth) apps collect personally-identifiable information while handling uniquely sensitive medical data, ranging from mental health records to real-time glucose or heart rate monitoring—yet they remain poorly understood at scale. We present the first comprehensive analysis of consent and data collection practices across 10,000+ mHealth apps on the Google Play Store, combining static analysis and privacy policy examination. We develop a rigorous operational definition to distinguish health apps from general wellness programs, and design a measurement framework to detect misuse of permissions and violations of consent. Our analyses reveal a troubling ecosystem: 69.15% of apps request at least one permission unrelated to their stated purpose, with over 52.9% apps requesting location data, and 50.5% and 34.9% apps requesting camera and microphone access, respectively— despite no functional justification based on app descriptions and stated purposes. Most alarmingly, nearly 93% of apps fail to provide users with a consent form, directly violating regulatory requirements such as GDPR; and even among the remaining 7%, 1 in 14 demonstrate a gap between the obtained consent and collection of personally identifiable information. These findings demonstrate an urgent need for stronger enforcement of privacy regulations in mHealth apps. We plan to release our dataset and measurement tools for continued monitoring of this critical space. Index Terms—Data privacy, information leakage, mobile applications, privacy

1

I NTRODUCTION

In April 2024, a mental health app was ordered to pay a $7 million financial penalty for sharing sensitive data with third parties for advertising purposes without user consent between October 2019 and January 2023 [1]. More recently, a federal class action lawsuit over a reproductive health app culminated in August 2025, when a jury found that background tracking disclosed sensitive health data to advertisers in violation of the app’s own privacy policy [2] These are not hypothetical risks, but documented failures in the mobile health (mHealth) ecosystem. Such failures point to systemic problems in the development and regulation of apps that promise to help users manage sensitive health information, while often mishandling it. Despite handling sensitive personal data and a market projected to be worth $86 billion by 2030 [3], mHealth apps remain a uniquely dangerous point of failure for privacy violations. These observations tie in with findings from past research on mobile apps in general, which lack rigorous

security and privacy practices, including inconsistent communication to users and direct violations of privacy regulations [4]–[8]. However, for mHealth apps specifically, these failures carry uniquely heightened risks: data leaks can lead to employment discrimination, insurance denial, or blackmail [9], presenting unique ethical, privacy, and trust challenges [10]. In line with previous research [11]–[15], we focus on privacy violations at the point of data collection, i.e., app installation and initial usage. This is when users decide whether to install the app, which data to provide, and which permissions to enable. It is thus a critical juncture: once data has been provided, regaining control over it becomes infeasible [16], [17]. To rigorously identify and define privacy threats at this stage, we perform an analysis of apps’ data lifecycle using the LINDDUN threat modeling framework [18], following the domain filtering approach [19]. This analysis results in three privacy threats (PTs): the acquisition of permissions beyond an app’s stated functionality (PT1), the absence of a mechanism to acquire user consent before data collection (PT2), and collecting data beyond acquired consent (PT3). Our PTs ensure comprehensive coverage of mHealth-specific privacy risks by avoiding narrow or arbitrary threat definitions noted in prior work [20]–[23] Despite the severity of these risks, there is a dearth of prior work that comprehensively addresses all three privacy threats in mHealth apps. Most existing studies either offer a broad examination of mobile apps (without mHealthspecific focus), or analyze only small samples of mHealth apps with limited scope. More critically, large-scale analyses (≥ 10,000 apps) have failed to measure the gap between acquired consent and actual data collection—leaving PT3 entirely unexamined at scale. Similarly, prior measurements focusing specifically on mHealth apps have stopped short of collectively analyzing all three privacy threat types. We close this knowledge gap by conducting the first systematic analysis of mHealth apps at scale, starting with the development of a rigorous operational definition of mHealth apps based on World Health Organization (WHO) guidelines [38] and a highly accurate classifier— 94.6% accurate with 0.92 F1 score (§ 3)—to identify 10,000+ mHealth apps on the Google Play Store. Based on the LINDDUN threat model, we distill and incorporate three types of privacy threats PT1–PT3 (§ 2) into an automated

2

TABLE 1 Comparison with privacy measurement efforts on: (i) focus on mHealth apps, (ii) analysis scale (≥10,000 apps or not), and (iii) examining PT1-PT3. Study WHYPER (2013) [24] AutoCog (2014) [25] ACNET (2019) [26] Feichtner et al. (2020) [27] HPD ROID (2020) [28] Alecakir et al. (2021) [29] HybriDiagnostic (2021) [30] Tangari et al. (2021 [31] I O TS POTTER (2022) [32] Neupane et al. (2022) [33] Nguyen et al. (2022) [11] Hassan et al. (2023) [34] Lyons et al. (2023) [35] PolicyChecker (2023) [36] Ardalani et al. (2024) [15] Li et al. (2024) [37] This work

Focus on mHealth Large Scale PT1 PT2 PT3 ✗ ✓ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✓ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ ✓

analysis pipeline. This pipeline captures discrepancies between stated app functionality, permissions requested by the app, and its actual data collection behavior. Our large-scale analysis methodology—described in § 4, with results in § 51 —reveals pervasive privacy violations: over 69% of the apps requested at least one permission unrelated to their stated purpose, and nearly 93% lack a consent acquisition mechanism, directly violating regulations like GDPR or CCPA. Why this paper? This work is the first to perform a largescale analysis of privacy implications of mHealth apps, using a comprehensive and rigorously defined threat model. Previous work (summarized in Table 1 and further discussed in § 2) either lacks mHealth focus, only performs exploratory analysis on a handful of apps, misses important privacy risks, or a combination of these factors.

2

BACKGROUND

Like us, prior work largely concentrated on the Android ecosystem, owing to its open-source platform and widespread use, and may be broadly divided into two categories: measurement studies to quantify privacy risks, and threat modeling studies that develop frameworks to understand privacy threats. The former usually focuses measuring common failure modes in mobile apps, such as the lack of consent, permission overreach, and deficient privacy policies [11], [12], [15], [24]–[26], [36], [39]. On the other hand, the latter developed theoretical models and frameworks to aid our understanding of how privacy threats manifest in software systems [18], [40]. These categories complement each other, and provide the foundation for the privacy threat types (PT1–PT3) analyzed in this work. Table 1 offers a comparison against the most closely related studies to highlight the gap bridged by this work: while some prior work achieved large scale or mHealthspecific focus, none have comprehensively measured all three privacy threat types at scale in the mHealth ecosystem. The work closer in spirit to us is Tangari et al. [31], which considered privacy properties of 15,000+ mHealth apps. Our work differs in two important way. First, Tangari et al. study is exploratory and has goals orthogonal to ours. 1. We make our dataset available at: https://tinyurl.com/bdcn9ta5

TABLE 2 The 9 personally identifiable information (PII) categories defining our scope, with brief descriptions. 1. AAID 2. Bluetooth MAC 3. BSSID 4. Device Serial Number 5. Email 6. IMEI 7. Nearby Bluetooth MAC 8. SSID 9. WiFi MAC

A unique, user-resettable, and userdeletable ID for advertising, provided by Google Play services [41] The unique hardware identifier assigned to the device’s Bluetooth. The unique identifier for the WiFi access Point (AP) to which the device is connected. The device’s serial number, provided by the manufacturer. Email address associated with the device’s Play Store account. International Mobile Equipment Identity, the unique 15-digit identifier for the device. The unique hardware identifiers of nearby Bluetooth devices. The name of the WiFi network to which the device is connected. The unique hardware identifier for device’s wireless network interface.

Notably, this work is not concernend with measuring permission gaps (the focus of our PT1), or consent or violation thereof (PT2 and PT3). Second, this work has significant methodological issues, including: (i) scraping mHealth apps based on Play Store categories without further verification (in § 3.2 we show doing so results in nearly 30% FP); (ii) no support for analysis of TLS-encrypted traffic in the presence of certificate pinning (common in modern apps); (iii) inability to detect hashed or encoded PII; and (iv) use of external tools (policy labeling and PII detection) without prior validation on their dataset. Thus, we believe our work makes important contributions beyond what has already been investigated in the literature. 2.1

Scope: PII Categories

We focus on 9 types of personally identifiable information (PII) commonly collected by mobile apps (Table 2), selected on the basis of established practices [12], [35], and further refined for practical measurability. Our scope includes device identifiers like IMEI and Device Serial Number despite their restriction to system apps in Android 9+, allowing for investigations into potential side-channel collection attempts. On the other hand, we exclude PII categories that depend on carrier-specific configurations (e.g., SIM-based identifiers) or complex user interactions (e.g., account creation, automated logins), as these cannot be measured with static analysis or reproducible runtime monitoring, and would require advanced UI fuzzing beyond the scope of this work. Having established which PII categories we examine, we now define the types of privacy threats that can arise at the point of mHealth app installation and permission acquisition—the critical juncture where users make trustbased decisions. Prior measurement studies of Android apps have documented common privacy failures including permission overreach [24]–[26], missing consent mechanisms [11], [14], and undisclosed data collection [39]. These studies, however, typically examine individual failure modes in isolation rather than within a comprehensive privacy threat framework. In the next section, we discuss our approach to systematize the analysis based on the LINDDUN framework.

3

2.2

The LINDDUN Privacy Threat Framework

To ground our analysis in a systematic framework, we adopt LINDDUN, a widely regarded privacy threat modeling framework introduced by Deng et al. in 2011 [18], and continually refined to address the evolving privacy landscape (e.g., the introduction of GDPR in 2018). LINDDUN, with its privacy-by-design framework, is geared to identify and mitigate privacy risks in software systems through the delineation of seven privacy threat categories: • Linking: Associating data items or user actions to learn more about an individual or group. • Identifying: Learning the identity of an individual, through leaks, deduction, or inference. • Non-Repudiation: Being able to attribute a claim to an individual. • Detecting: Deducing the involvement of an individual through observation. • Data Disclosure: Excessively collecting, storing, processing or sharing personal data. • Unawareness: Improperly informing, involving or empowering individuals in the processing of their personal data. • Non-Compliance: Deviating from security and data management best practices, standards, and legislation. While LINDDUN offers comprehensive coverage of privacy threats, not all categories are relevant or measurable at scale for mHealth apps. Following the domain filtering approach [19], we focus on threats that emerge at the critical juncture of app installation and permission granting, which is also the point where users often decide on the basis of trust and limited information. We identify three privacy threats (PT1–PT3) that map to LINDDUN’s categories. We describe these next with motivating examples, align them to prior work, and provide a succinct description of our approach. For further details of our methodology and improvements vis-à-vis each threat type, we direct the reader to § 4. 2.3

PT1 (Permission Overreach)

PT1 is present when an app requests permissions that its stated functionality does not justify. Example: The app com.transsion.healthlife, with over 163M downloads at the time of collection, requested permissions to access the device’s camera, audio, storage, phone, call logs, and contacts—despite describing itself as a fitness tracking app that offers step counting, activity monitoring, and health tips. However, none of these features justify access to call logs or contacts, demonstrating clear permission overreach far beyond its purported functions. PT1 aligns with three specific LINDDUN threat types: Threats arising from limited comprehension of permission jargon and over-requesting of permissions align with these LINDDUN threat types: (1) unawareness, as the user may not understand the extent of permission usage and thus the data collection practices of the app; (2) disclosure, as over-requesting permissions leads to data collection beyond stated purposes; and (3) non-compliance, as over-requesting permissions leads to collection of data for which the user did not provide consent, thus constituting a lack of compliance. Alignment to existing research: Android permission system serves as an (attempt to) implement the Principle of

Least Privilege (PoLP) [42], providing a mechanism to protect sensitive system resources. But it cannot verify whether the requested permissions align with app functionality. This alignment remains at the discretion of the developer. Prior work has investigated the misalignment between app descriptions and requested permissions using a variety of text mining and natural language processing (NLP) techniques, including keyword matching algorithms, semantic classifiers, and deep neural networks [24]–[26]. Our approach: To measure if an app’s requested permissions align with its claimed functionality, our approach is based on modern NLP: we fine-tune a large language model (LLM) as a multi-label classifier to predict which permissions are justified by an app’s functionality, based solely on that app’s Play Store description. We then compare these predictions against that app’s actual requested permissions to identify overreach. Our best model achieves a 99% ROCAUC on our test set (details in § 4.1). 2.4

PT2 (Absence of Consent Mechanism)

PT2 is present if the app does not have a consent mechanism. Example: The app sixpack.sixpackabs.absworkout, with 177M+ downloads, collected the user’s AAID (Google Advertising ID), without user consent, as the app lacked an action to present a consent dialog to the user. PT2 aligns with two specific LINDDUN threat types: From a threat modeling perspective, PT2 aligns with LINDDUN’s threat types of (1) unawareness, and (2) non-compliance. The absence of a consent mechanism leaves users unaware of the data collection practices of these mHealth apps, leading to non-compliance within privacy regulations. Alignment to existing research: Previous large-scale measurement studies have documented numerous failures to obtain consent in Android apps [11]–[14]. Large-scale analysis of generic Android apps showed that only a minority of them displayed a consent screen to users [11]. Smaller exploratory works have found that third-party trackers commonly did not implement consent mechanisms [14], and consent dialogs often manipulated users into granting consent [13]. PT2’s focus on consent is grounded by data protection law, which recognizes multiple lawful bases for data processing, including legitimate interest (e.g., GDPR Article 6(1)(f) [43]). However, regulatory decisions consistently indicate that, in the context of behavioral advertising and tracking, consent is the only acceptable legal basis [44], [45]. From this perspective, the quality and content of consent mechanisms are the decisive legal factor. Accordingly, PT2 concentrates on the presence of consent mechanisms rather than legitimate interest, aligning with previous research [11], [13], [14]. Our approach: We launch each app in an automated testing environment. After an empirically determined waiting period to ensure proper app initialization and loading, we capture its initial UI screenshot. We then extend a pre-existing privacy language dictionary—developed by Nguyen et al. [11]—to identify consent-related language, resulting in 254 distinct consent forms. Our manual inspection found only a single false positive—an accuracy of 99.6% (details in § 4.2).

4

2.5

PT3 (Abuse of Consent)

PT3 is present if some PII is being collected by an app without obtaining prior consent. Example: The com.oraimo.joywear2 app, with 1M+ downloads, collected users’ AAID. However, their consent dialog did not include any statement about collecting it. Thus, the data collection was unauthorized and outside the scope of obtained consent. PT3 aligns with three specific LINDDUN threat types: Abuse of consent corresponds to three LINDDUNS threat types of (1) unawareness, as users are misled about actual collection practices; (2) non-compliance, violating consent agreements and regulations like GDPR; and (3) data disclosure, through excessive collection beyond disclosed scope. Alignment to existing research: Recent work has documented significant gaps between (a) data collection claims within consent dialogs and privacy policies, and (b) the actual data collection practices of mobile apps. Notable findings include: the majority of apps have at least one data collection claim, but their privacy policies fail GDPR completeness [36], third-party SDKs used by apps rarely provide privacy policies and often over-collect user data [39], and mobile health apps consistently leak data to third parties [15]. Our approach: As PT3 pertains to the collection of PIIs beyond the scope of obtained consent, we examine only the subset of apps that provide a mechanism to obtain consent from their users. We capture network traffic and logs during automated interactions to detect which PII types are collected by the app. Separately, we train a classifier that, given a consent dialog, identifies PII collection claims. Based on this classifier, we identify PT3 violations when the collected PII includes types not disclosed in the consent screen (implementation details in § 4.3). 2.6

Summary

Prior work has described privacy failures: permission overreach [24]–[26], [42], absence of consent [11]–[14], and consent violations [15], [36], [39]. However, these studies examine threats in isolation, and rarely have a specific focus on mHealth apps. In Table 1, we summarized the key gaps in the most closely related research: existing large-scale studies lack mHealth-specific focus, while mHealth-specific studies examine only small samples or a subset of threats. Our work addresses these gaps by defining and grounding PT1–PT3 in the LINDDUN framework, and systematically measuring them “in the wild”, across 10,000+ mHealth apps.

3

M OBILE H EALTH ( M H EALTH ) A PP DATASET

In this section, we discuss the process we followed to build our mHealth app dataset. As we need to specifically analyze mHealth apps, automated data collection poses significant challenges: (i) define what constitutes an mHealth app (a question of scope), and (ii) developing methods that offer coverage along with precision, for identification and collection of such apps at scale (a matter of design and implementation).

TABLE 3 The 5 best models for mHealth app curation (§ 3.2), showing their (Acc)uracy and F1 , and the experiment settings: learning rate (η ), number of epochs, and batch sizes. Model

Acc.

F1

η

DeBERTa (base) RoBERTa (base) DeBERTa (base) DeBERTa (base) DeBERTa (base)

0.946 0.941 0.939 0.939 0.939

0.916 0.909 0.906 0.905 0.905

0.0002 0.0002 0.0002 0.0003 0.0002

3.1

Epochs Batch Size 3 3 3 5 5

16 32 32 32 32

An Operational Definition of mHealth Apps

Since there is no single universal definition of mHealth app, we devise an operational definition based on criteria provided by the World Health Organization (WHO) for digital technologies for public health: viz., as software used in health-related services on mobile devices [38]. These apps are meant to improve various aspects of health and healthcare and empower users to manage their health, with features such as health tracking, care support, secure data sharing with providers, privacy safeguards, and behavioral improvement strategies. Based on this, we propose a taxonomy of mHealth apps derived from WHO guidelines, organized by their primary functional roles: • Health Monitoring: Apps designed to track and/or visualize physiological or behavioral data (e.g., heart rate, physical activity, blood pressure, sleep patterns). • Disease Management: Apps supporting chronic condition care (e.g., diabetes) through symptom logging, personalized dietary/exercise plans, or medication adherence tools. • Telemedicine: Apps facilitating remote clinical interactions (e.g., video consultations, secure messaging) for diagnosis, treatment, or follow-up care. • Medication Management: Apps tracking medication schedules, dosages, and interactions, often with adherence and safety alerts. This framework distinguishes mHealth apps from general wellness tools by emphasizing their integration into healthcare workflows, data-driven decision-making, and adherence to clinical or regulatory standards. Despite overlaps (e.g., a telemedicine app may include health monitoring features), our definition prioritizes broad coverage and primary use cases to provide a pragmatic boundary. 3.2

Curation and Description of mHealth Apps

Curating a large-scale dataset of mHealth apps that align with our definition presents significant challenges. Existing approaches—including those relying on app store categories or keyword-based searches [15], [34]—introduce substantial type I and type II errors: predefined categories often misclassify apps (e.g., delivery services identified as health apps because they deliver prescriptions or over-the-counter medicines), and keyword heuristics overlook relevant apps (e.g., the physiotherapy appointment app Mon Rdv Kiné Praticien, also called MyRedKine, is labeled as “productivity”). These limitations underscore the need for a tailored collection framework. Others have leveraged machine learning to glean specific types of apps from a large pool. While some report low accuracy—and thus require manual intervention that

10 1

10−1

10 2 10 3 10 4

400

10−2

10−3

101 103 105 107 109

300 200 100

101 102 103 104 105 106

#Installs

5

500

Frequency

100

Proportion

Proportion

100

0

1

2

3

4

5

Rating score avg

#Ratings

Fig. 1. Dataset characterization: The complementary cumulative distribution functions, or CCDFs, of app installs (left) and reviews (center) show heavy-tailed distributions; and the histogram of average rating scores (right) shows a significant positive skew toward higher ratings. TABLE 4 Summary statistics of mHealth user engagement and popularity indicators, including the number of times an app has been installed, average rating score, number of ratings, and number of reviews. Rows indicate the mean, standard deviation (Std), minimum (Min), 25th percentile (25%), median (50%), 75th percentile (75%), and the maximum (Max) for each metric across our dataset.

Mean Std Min 25% 50% 75% Max

#Installs

Score

#Ratings

#Reviews

1.16M 30.21M 0 111 2,067.50 42,914.25 2.20B

2.56 2.01 0 0 3.42 4.39 5.0

18,651.03 135,727.30 0 0 84.0 1,790.50 3.56M

834.53 8,239.34 0 0 5 61 449,419.0

cannot scale [33], [46]—the use of Bidirectional LSTM and pretrained BERT embeddings [47], [48] for fine-tuning was demonstrably accurate in distinguishing IoT from non-IoT apps [32]. We adopt a similar approach, but in contrast to their ensemble approach using consensus among two models, we find that fine-tuning a single model offers higher accuracy in identifying mHealth apps. The mHealth App Classifier. We constructed an annotated dataset of 5,000 apps to train our mHealth app classifier. To mitigate class imbalance, half the apps were sampled from the Medical and Health & Fitness categories in Google Play Store, and the other half were randomly selected. This sampling strategy balances the likelihood of including mHealth apps (via category filtering) with real-world diversity. Two annotators independently labeled whether each app should be treated as an mHealth app on the basis of our operational definition. After achieving near-perfect inter-annotator agreement (Krippendorff’s α = 0.88-0.96) on two pilot batches of 100 apps each, the remaining 4,800 apps were annotated in parallel. Upon completion of this process, we obtained 1,470 mHealth and 3,530 non-mHealth apps. We fine-tuned transformer-based language models (BERT [48], DeBERTa [49], RoBERTa [50], and DistilBERT [51]) on this collection of 5,000 apps, optimizing hyperparameters for each architecture. DeBERTa achieved the best results (Table 3: acc. = 0.946 and F1 = 0.916), establishing it as our final classifier. We used this classifier on 500,000 app descriptions from AndroZoo [52], identifying 10,688 mHealth apps.2 Between March–May 2024, we downloaded the corresponding APK files directly from the Play Store, restricting our collection to free apps to ensure broad accessibility and reproducibility. 2. We targeted 10,000+ apps to ensure sufficient sample size after validation and exclusion of paid apps, due to impracticality and cost of analyzing those.

Comparison with category-based scraping. We compare our classifier-based app collection pipeline with scraping based on Play Store categories, a simpler approach leveraged in past work [31]. To do so, we select all apps belonging to Play Store Categories Medical and Health & Fitness within our human-labeled dataset, and we test how many of them were labeled as mHealth apps by the annotators. Only 71.5% of apps placed in the mentioned categories were labeled as mHealth apps, suggesting Play Store categories are insufficient for precise collection of mHealth apps. App Dataset Characterization Figure 1 characterizes our dataset through three measures: the left and center plots show complementary cumulative distributions (CCDF) of the number of app installs and the number of reviews on log-log scale, both exhibiting heavy-tailed distributions characteristic of large software ecosystems [53], where a small fraction of apps account for the majority of user reach. Together with the raw counts shown in Table 4, this skew implies that the privacy practices of a few dominant apps disproportionately impact millions of mHealth users. The third plot shows the distribution of average rating scores, which cluster around 4.5, suggesting positive bias in app store ratings. 3.3

Developer Geolocation

Geolocating app developers is critical for assessing regional regulatory impacts on privacy practices. Developer locations are often incomplete or ambiguous, however (e.g., com.wsl.noom lists a New York address but omits the country). To address this, we designed a dedicated threepronged country inference process: 1) Direct Extraction: Match app metadata to a dictionary of common country names and synonyms. 2) CrunchBase Query: If the country is absent from the dictionary, query the CrunchBase company database API [54]. 3) Fallback on top-level domains (TLDs): Derive country names from the app package TLDs (e.g., ca.teluspharmaconnect.mobile → Canada), excluding TLDs that are usually not geographic indicators (e.g., .ai and .io). A manual validation of 100 randomly geolocated apps confirmed 98% accuracy; the two discrepancies stemmed from ambiguous public data. Overall, we geolocated 41% of apps—a substantial coverage given that over 61% did not specify any developer location. While our sample may underrepresent regions with sparse developer location data, it sufficiently covers major markets (e.g., the EU, USA) with stringent privacy regulations. As such, this dataset enables analysis of regional privacy practices, even if partial.

TABLE 5 Comparison of BERT with prior work on permission inference from app descriptions [24]–[26]. Model / Paper BERT (this paper) AC-Net [26] Keyword-based [26] AutoCog [25] WHYPER [24]

4

ROC-AUC

PR-AUC

0.99 0.97 0.78 0.76 0.60

0.81 0.66 0.45 0.42 0.32

M ETHODOLOGY

We now discuss our methods to operationalize and measure the privacy threats (PT1–PT3) defined in § 2. 4.1

PT1: Permission Overreach

When apps request permissions that their stated functionality does not justify, it results in PT1. We operationalize this by comparing permissions implied by Play Store descriptions against permissions declared in app manifests. This difference constitutes the permission gap. Permission Inference from App Descriptions. We follow the approach taken by Tamrakar et. al [55] by fine-tuning a language model to predict which permissions an app description justifies, framing this as multi-label text classification. Based on this approach, we build on the ACNet dataset [26], which contains 24,724 app description sentences, each labeled by human annotators with permissions that could reasonably be inferred from the text. Model Selection. We explored five pretrained models: BERT [48], DistilBERT [51], RoBERTa [50], DistilRoBERTa [56], and XLNet [57]. We focus on BERT-family models, as they achieve strong performance on text classification while being computationally more efficient than larger LLMs for our inference task [58]. We fine-tuned each for 5 epochs using standard hyperparameters (learning rate η = 2 × 10−5 , batch size 16), evaluating with two metrics: area under the receiver operating characteristic curve (ROCAUC), and the precision-recall curve (PR-AUC), averaged over 10 runs. Addressing Class Imbalance. The AC-Net dataset is highly imblanced; classical fine-tuning gave ROC-AUC (0.64)/PRAUC (0.95), indicating the model struggled with minority classes. To address this, we generated synthetic paraphrases of minority-class samples using GPT-4o [59], following the prompting strategy [55]. After re-balancing the training set in this manner, we observed substantially improved performance (Table 6). Notably, the DistilBERT and DistilRoBERTa models matched the accuracy of full-sized models—despite having 35-40% fewer parameters—thus enabling efficient inference. We selected the fine-tuned BERT model for our analysis, based on its slight edge over DistilBERT in PRAUC (Table 6) and its superior performance over prior work in both metrics (Table 5). Measuring PT1 “in the wild”. We sentence-tokenize app descriptions with NLTK and remove markup and emojis, lowercase, and run our BERT model with a 0.5 threshold. We extract the actual permissions by parsing app manifests using regular expressions. Because AC-Net only covers 16 permissions, PT1 is evaulated on that subset. The permission gap for each app is the set difference: (declared permissions) - (predicted permissions). PT1 is exhibited by mHealth apps with non-empty gaps.

TABLE 6 Evaluation metrics for top fine-tuned models.

6

ROC-AUC

PR-AUC

0.990 0.991 0.990 0.990 0.852

0.815 0.808 0.815 0.805 0.717

Model BERT (base-uncased) DistilBERT (base-uncased) RoBERTa (base) DistilRoBERTa (base) Class Distillation (XLNet)

4.2

PT2: Absence of Consent Mechanism

PT2 occurs when an app collects information but lacks any immediate mechanism to acquire user consent. To operationalize the measurement of this privacy threat, we base our approach on [11], which combines UI fuzzing and screenshot analysis to detect consent forms while monitoring for sensitive data transmission. Data Collection Environment Our data collection framework ran on three rooted Google Pixel 7a phones running Android 13. MITMproxy [60] allowed us to capture network traffic, while we bypass SSL pinning using Objection [61]. We automated app interaction by first capturing a screenshot of the apps’ initial screen, and then apply UI-fuzzing using Droidbot to explore different UI paths, trigger potenial data collection events, and grant all permissions. Critical modification We identified several critical issues in the pipeline [11] and consequently engineered non-trivial adaptations to suit our work. Many apps failed to launch due to version incompatibilities or instrumentation, which we detected using OCR and string matching on captured screenshots. We also repaired corrupted screenshots by reencoding the PNG meta data with SIPS [62]. Lastly, we opted to use EasyOCR [63] as our OCR engine as it empirally outperformed pytesseract [64], which [11] used. OCR model selection. We benchmarked Python-tesseract (pytesseract) [64] together with EasyOCR and TrOCR [63], [65] on a 500-sample subset of the 2019 SROIE dataset [66]. The Transformer-based TrOCR model outperformed all other models in terms of accuracy. However, it is limited to single-line text images [65]. We thus opted to use EasyOCR, as it can extract multiline text effectively.3 Screenshot and Network Data Collection. Our automated process installs each app and waits for 12 seconds, which we empirically determined to be enough time for the app to initialize and load its first screen. Then, it collects a screenshot of the screen displayed, and UI–fuzzes the app’s interface for 150 seconds. Concurrently, we collect network packets from the app using MITMProxy. Qualitatively, the UI– fuzzing algorithm used here leverages heuristics to attempt to elicit as many app behaviors as possible; however, it provides no guarantees about coverage. Note that, exhaustive UI path exploration is an open research problem [67]. After filtering out crashed apps, we performed OCR to identify consent-related language within the captured screenshots, via matching against an extended version of the privacy language dictionary used by [11]. We had to extend this to enable the accurate consent screen detection in regions beyond the EU, as [11] was GDPR-centric. We extended this dictionary by (i) identifying all 43 languages used in the descriptions of apps in our dataset (using Python langdetect 3. Performing OCR on screenshots is a relatively easy task, and EasyOCR performance on our consent screenshots is significantly better than on the SROIE dataset.

7

TABLE 7 OCR benchmark on SROIE (Huang et al. [66]). Model EasyOCR Python-tesseract TrOCR Base TrOCR Small

Acc.(%)

Time(s)

GPU Usage (MB)

37.20 22.20 93.80 93.40

0.0674 0.173 0.204 0.12

160.34 (CPU-only) 26.53 19.06

package); (ii) prompting the OpenAI GPT-4o model to extend the original dictionary to missing languages; and (iii) empirically verifying the correctness of a sample of wording for 10 languages using translation services. Once screenshot analysis is complete, instances of PT2 can be identified by observing app screenshots without any consent-related language, while generated network data and/or logs contain PII (we discuss detection of PII in PT3). 4.3

PT3: Abuse of Consent.

PT3 occurs when an app collects data beyond the consent it has obtained. We approximate PII collection by analyzing PII in each app’s network communications and logs, and by creating (another) NLP pipeline over consent forms to determine whether the data collected was disclosed. Collecting and Extracting PII from Network Data and System Logs. Our collection and detection of PII is based on the approaches of [12] and [35]. However, when building upon [12] we found they failed to exclude non-app related traffic, which we rectified as described in the following. We search for a identifiers which include AAID, SSID, BSSID, email, IMEI, Bluetooth MAC, and device serial number in clear text along with encodings (e.g., base64), and transformations (e.g., MD5 and SHA-256) in both network traffic and logcat output. To avoid missattributing PII from apps that originated from Google Mobile Services (GMS) we build two heuristics. For logs, we identify logs that originated from the app through a combination of process identifier (PID) tracing and timestamp analysis. For network traffic, we use feature identification to identify characteristics of system generated traffic that include, request sent to known google domains (e.g., googleapis.com), very large payloads that reference internal android components (e.g., com.android.vending), protobuf or gRPC encoded binary, and no references to the package under testing. Across two manually labaled validation datasets, these hueristrics reduce false postives by 66.2% in logs and 74.6% in network traffic with 100% accuracy. Categorizing and Extracting Consent Screens.When reviewing consent screens, we found three patterns: (i) 152 apps showed an embedded link to their privacy policy, (ii) 68 apps showed a short snippet of text, and (iii) 33 apps had text within a scrollable element. Due to this diversity, and the fact that case (iii) cannot be correctly extracted via screenshot+OCR only, we also attempted to extract consent forms from decompiled apps. To extract thier text, we use a two stage pipeline. First, we decompiled each app using JADX [68], search for URLs and text resources associated with consent-related views, detect WebViews that load policy content, and search for specific phrases in the OCR’d text from the consent form screenshot (we found that using short phrases such as ‘privacy policy’ worked best). At the end of Stage 1, we had a list of URLs and associated files, dynamic calls, and text search results. In Stage 2, we

manually searched the app’s source code using the clues we had gathered in Stage 1. This process resulted in a 98.4% successful consent screen extraction rate. We were unable to extract 4 consent screens due to decompilation errors. As a result, we fell back to OCR results. Overall, we have a total of 253 consent forms from our corpus. Data collection. We construct a consent-form-text dataset by augmenting extracted consent form dialog with synthetic variants via GPT-4o, resulting in a corpus of 546 samples. Each sample is labeled based on whether the consent dialog mentions data collection for any of our PII identifiers. Two expert annotators labeled all samples, yielding a Krippendorff’s α = 0.765. We then trained a sentence transformer to detect mentions of PII in consent form language. We trained the sentence transformer paraphrasemultilingual-mpnet-base-v2 [69], using SetFit [70], a fewshot contrastive learning method. We chose to use this model due to its high performance and because it was pretrained on 50+ languages, making it suitable for non-English consent screens. Our train and validation datasets were generated by selecting 20 types of PII from the majority labels and 30 from the minority PII types, e.g., IMEI, and Device Serial Number. Our validation dataset had 200 samples, and our training set had 219 samples. We selected 127 disjoint samples for the test dataset. We generate 30 contrastive pairs for each training sample using cosine similarity. Our model achieved 91.1% F1 score and 97.5% ROC AUC on our test set. Finally, we measured the set difference between types of PII mentioned in consent form and PII collected within network data/logs, identifying instances of data collection beyond acquired consent.

5

R ESULTS

Our analysis of 10,688 mHealth apps reveals privacy violations across all three threat types: 69.15% of apps exhibit permission overreach (PT1), requesting permissions unjustified by their stated functionality. Furthermore, nearly 93% of apps lack any immediate consent mechanism (PT2), indicating violations of regulatory requirements. Among the apps that do obtain consent, 1 in 14 collect data beyond their disclosed scope (PT3). We also investigate whether popularity metrics are correlated with any threat type, as popularity and user opinion may influence (or be influenced by) good privacy practices. 5.1

PT1: Prevalence of Permission Gaps.

PT1 measures the extent to which an app requests permissions that their stated functionality does not justify. We analyze 10,036 apps (94% of our dataset), as the remaining 652 apps were removed from the Play Store between APK download and metadata collection. Table 8 shows the counts for the 11 permission categories: how often each permission is (i) requested in app manifests, (ii) predicted as necessary based on descriptions, and (iii) found in the permission gap (i.e., requested but not predicted). Among the 10,036 analyzed apps, 69% (6,936 apps) exhibit permission gaps, requesting at least one permission their descriptions do not justify. The median gap size is 2 permissions (inter-quartile range, IQR = 4), with

8

TABLE 8 PT1: Breakdown of permission utilization. No. of times permission is predicted (#Pred.), requested (#Req.), and within the permission gap (#In gap). Permission

#Pred.

#Req.

#In gap

CAMERA MICROPHONE CALENDAR LOCATION CONTACTS STORAGE PHONE SETTINGS TASKS CALL LOG SMS

2,206 2,216 1,701 8,670 9,152 15,412 429 2,145 2,582 88 1,144

6,477 4,434 3,324 10,914 3,718 14,629 838 279 286 209 206

5,062 3,502 2,809 5,303 2,205 3,068 722 184 118 154 35

most excess permissions providing access to sensitive user data such as location, camera, and microphone. The majority of permission gaps had multiple permissions, as depicted in Figure 3 (right). This sets a concerning precedent that could allow these apps to collect far more data than what the user is informed of from multiple data sources. Predicted permissions at times exceeded requested permissions. This may happen if app descriptions imply they have functionality they do not have, e.g., com.terraillon.wellnesscoach description suggest the use of SMS (“...receive call sms notifications on your device ... ”) without requesting such permissions. Also, we leveraged the labeling schema proposed by [26], where one permission label maps to multiple Android permissions (e.g., CONTACTS maps to GET_ACCOUNTS, READ_CONTACTS). Geographic Patterns Using developer location data, we geolocated 41% of apps to analyze geographic patterns. Figure 2 shows the average permission gap sizes by region. Surprisingly, apps from regions with existing privacy regulations—including the EU, South America, and parts of Asia—exhibit large average gaps (3.1-4.5 excess permissions), suggesting that regulatory frameworks alone may not ensure adequate user disclosure. Among these regions, Central and Southeast Asia show the largest average gaps. These findings are, however, limited by incomplete geolocation coverage and potential confounding factors such as developers being based elsewhere than their target markets. Popularity and User Experience Analysis. To investigate how app popularity (measured in terms of the number of app installs) varies with the permission gap, we binned the apps by their number of installs, using the bins illustrated in Figure 3 (center). We find that the most highly downloaded apps have smaller permission gaps: apps with 1M+ installs have an average permission gap of 1.24, while less popular apps—with 100K-1M, 10K-100K, and ¡10K installs—have

Fig. 2. PT1: Average permission gap size by country, excluding countries with less than 10 apps (in gray).

TABLE 9 PT2: Percentage of apps, by region, with consent mechanisms. The rate (%) indicates the proportion of apps in each region that provide users with immediate (i.e., in the first screen of the app) mechanisms to manage their data consent preferences. Region Africa Asia South America Europe Oceania North America

Apps w/ Consent

Total Apps

Rate (%)

1 27 3 53 4 33

57 797 142 1,707 141 1,264

1.75 3.38 2.11 3.10 2.83 2.61

higher permission gaps of 1.39, 1.63, and 2.79, respectively. To test whether these differences are significant, we conduct a Kruskal-Wallis test (since a Shapiro-Wilk test revealed the distribution to be non-Gaussian) to find statistically significant differences across the 4 bins (H(3, N = 10009) = 958.60; p < 0.0001). We then further conduct post-hoc pairwise Dunn’s test with Bonferroni correction, and find that all pairwise differences are statistically significant except the 1M+ and 100K-1M installs. A similar, but weaker, trend exists between permission gap size and average rating score (Figure 3, left). This is indicated by the Spearman correlation (ρ = −0.025, p < 0.01, 95%CI[−0.027, −0.022]). Given the small effect size and numerous confounding factors (app quality, functionality, user expectations), we leave further investigation of this latter result to future work. 5.2

PT2: Absence of Consent Mechanism

We detect immediate consent mechanisms by launching each app, capturing its initial screen, and identifying consent-related language (see § 4.2 for details). Due to app crashes and execution failures, we successfully analyze 3,599 apps (34% of our dataset)—a limitation we further discuss in § 6. Of the 3,599 analyzed apps, only 253 (7%) displayed any consent mechanism to the user. The remaining 93% mHealth apps lack immediate consent acquisition. Among these apps, they collected 356 AAID, 1 BSSID, 25 Email, 1 SSID, 5 Bluetooth MAC, and 2 WiFi MAC. These findings align with prior work showing low consent rates (5.5%) and non-compliant data collection across general Android apps [11] and indicates that these failures extend to the privacy-critical mHealth domain. Geographic Patterns. Among the 253 apps with consent mechanism, we geolocate 121 (48%) to analyze regional patterns. Figure 5 and Table 9 show the distribution of apps that fail to offer consent mechanisms, across countries and (excluding countries with <10 apps) continents, respectively. While this sample is limited, it indicates consistently low consent rates across regions, including those with established privacy regulations. However, strong conclusions about geographic patterns are not warranted, given the small sample size and high failure rate. Popularity and User Experience Analysis. We investigate if app popularity correlates with the presence of immediate consent mechanisms for the user. Figure 4 shows the install count distributions for apps with and without consent mechanisms. We bin the apps by popularity (¡10K, 10K–100K, 100K–1M, 1M+ installs) and calculate consent rates within each bin. Apps with 1M+ installs show the highest consent rate (4.98%), while apps with ¡10K installs show the lowest (1.54%). The bins

Download Range

3000

<2.0 2.0 3.0 3.0 4.0 4.0 5.0

0-10k 10k-100k 100k-1M 1M+

2500 2000 1500 1000

2

4

6

Permission Gap Size

0

8

0.8 0.6 0.4 0.2

500 0

9

1.0

Proportion

App Rating Frequency

Frequency

2000 1750 1500 1250 1000 750 500 250 0

0

2

4

6

Permission Gap Size

8

0.0

0

1

2

3

4

5

6

Permission Gap Size

7

8

Fig. 3. PT1: Permission gap characteristics: the average permission gap by ratings (left) and installs (center), and the empirical cumulative distribution function, or eCDF, of permission gap sizes (right).

corresponding to intermediate levels of popularity show consent rates of 3.87% (10K–100K) and 3.03% (100K–1M). A chi-square test of independence confirms these differences are statistically significant: χ2 = 58.17 with three degrees of freedom, p < 0.0001. Furthermore, post-hoc pairwise comparisons with Bonferroni p-value correction show that the least popular apps differ significantly from others (p < 0.01). We find no significant relationship between the presence of consent mechanisms and user ratings. A MannWhitney U test reveals U = 152K, p < 0.01, rank-biserial correlation = -0.22), indicating that users do not penalize or reward consent mechanisms through ratings. Key finding: Even the most popular mHealth apps exhibit alarmingly low consent rates (<5%). This positive correlation between popularity and the presence of consent mechanisms may reflect greater regulatory scrutiny of high-profile apps, larger development teams with compliance resources, or survivor bias (i.e., non-compliant popular apps may have been removed). However, the universally low rates also suggest systemic failures in consent implementation across the mHealth ecosystem, regardless of popularity. Among the 3,346 apps without consent acquisition mechanisms, PII collection is dominated by Google Advertising ID (AAID, n =249), with minimal collection of other identifiers: email addresses (n=8), nearby Bluetooth MAC addresses (n =4), BSSID (n =3), and SSID (n =1). No apps collected restricted identifiers (WiFi MAC, IMEI, and Device Serial Number).

Downloads

105 104 103 102 101 100

0

Consent Detected

1

Fig. 4. PT2: Distribution of downloads across presence/absence of immediate mechanisms to obtain user consent (excluding outliers).

Fig. 5. PT2: Absence of consent percentage by country, excluding countries with less than 10 apps (in gray)

TABLE 10 PT3: Breakdown of PII consent and collection for apps that have a consent mechanism (#Acquired: 1 for each claim an app makes to collect PII; #Collected: 1 for each PII category found in an app’s logs or network traffic; #In gap: 1 for each PII found in an app’s consent gap) PII Category AAID BSSID Device Serial Number Email IMEI SSID Bluetooth Mac

5.3

#Acquired

#Collected

#In gap

31 9 46 98 21 6 22

21 0 0 1 0 0 0

17 0 0 1 0 0 0

PT3: PII Collection Beyond Consent.

PT3 measures whether apps with consent mechanisms collect PII beyond their disclosed scope. We compare PII mentioned in consent forms against actual collection detected through network traffic and log analysis (see § 4.3). Of the 253 apps displaying consent forms to the user, we find that 18 apps (7.1%) collect PII not disclosed in their consent agreements, with violations limited to one undisclosed PII category per app. Table 10 displays the mentions of a specific PII in an app’s consent mechanism, and compares it against the actual collection of that PII by the app. The low violation rate (7.1%) among mHealth apps with consent mechanisms contrasts sharply with the extraordinarily high rate of complete absence of initial consent acquisition (93%, found in our analysis of PT2). This demonstrates that when developers implement consent, they generally align data collection with disclosure. The small sample size (n = 18) limits stronger conclusions, however. Notably, we find no evidence of apps collecting restricted identifiers (e.g., IMEI) through side channels, despite our methodology being capable of detecting such collection through network traffic and system logs, suggesting Android’s security effectively restricts identifier access. Geographic Patterns For PT3, our geolocation analysis found no significant patterns, likely due to the insufficient statistical power in the sample of 18 violations. Thus, robust conclusions about regional compliance cannot be drawn. Popularity and User Experience Analysis The distributions of #installs and average rating scores indicate no clear trend relating consent gaps and popularity metrics. This is confirmed by computing the Spearman correlation between consent gap size and these metrics: we find no statistically significant correlation (at p = 0.01) between gap size, #installs, and the average rating scores.

10

6

D ISCUSSION

Systemic Privacy Failures in mHealth. Our findings reveal that mHealth apps systematically fail to protect user privacy. While similar privacy failures have been documented [11], [12], [35], our large-scale comprehensive analysis reveals their pervasiveness in this sensitive domain. The implications may be severe: exposed PII may be linked to health status and diagnostic data, carrying the risk of discrimination and stigma. Concerningly, even apps from well-resourced developers (e.g, ANT+, Samsung, Google) exhibit privacy violations. This suggests that the problem is not simply one of under-resourced developers failing to implement best practices, but rather systemic inattention across the entire mHealth app ecosystem. Moreover, as the top 5% of apps account for 92% of total downloads, privacy issues in popular apps have a disproportionate effect. Developer Knowledge Gap. The patterns we observe align with persistent findings across the literature, including developers’ confusion, and lack of awareness and/or misunderstanding of privacy norms [11], [12], [71]–[73]. Our results illuminate how these knowledge gaps have disparate impacts. The issues are more prevalent for smaller developers (often relying on app store approval as stamp of correctness [74]); however larger developers still exhibit concerning lapses. Without structural changes like clearer platform requirements and meaningful enforcement, these patterns are likely to persist regardless of developer intent. Limitations and Scope. While our methodology uncovers strong evidence of privacy violations, it only captures initial app execution before initial account creation. This enables scale: unlike prior work which performs deeper analysis [33], [34], we analyze 3,500+ to 10,000+ mHealth apps across the three threat types. While we experimented with automated LLM-based testing including account creation steps, we found that this loop to be inefficient in terms of time and computational resources, and prone to high failure rates. Our dynamic analysis approach introduces selection bias due to some apps failing to execute in PT2 and PT3. As we only report privacy failures observed in testing, these crashes causes us to conservatively underestimate the prevalence of privacy threats. We focus exclusively on Google Play Store apps. While this overlooks other platforms, the Play Store dominant market position ensure meaningful coverage of the current mHealth app ecosystem. Implications for Regulation and Research. Our findings suggests that voluntary compliance and app store review processes are insufficient to protect users. The current ecosystem fails users at scale, and closing this gap demands coordinated action from multiple stakeholders. For regulators, requiring automated privacy auditing as a condition of market access may be desirable. For researchers, our work opens several directions, including measurements of user privacy awareness; and scalable automated analysis techniques.

7

R ELATED W ORK NOT D ISCUSSED E LSEWHERE

We discussed the most closely related publications organically through the paper. Here, we provide a brief discussion of research complementary to ours. App Analysis Beyond Privacy: Mobile app research often prioritizes risk over privacy, employing methods like risk

scoring based on sets of permissions [75], [76], user expectations vis-à-vis runtime behavior [77], and static taint analysis (e.g., FlowDroid [78]). Others focus on human factors, e.g., user security behaviors [79] or permission comprehension [80]. However, these work lacks the precision for privacy-centric measurement of mHealth apps, a domain that requires tailored analysis, and affects millions of users. Our approach enables automated scalable privacy assessment. Privacy Beyond Mobile Apps: GDPR compliance frameworks dominate privacy research, spanning cloud services [81], website consent management [82], web development frameworks [83], and identity management [84]. These studies typically identify overt violations or dark patterns but neglect mobile ecosystems. mHealth apps pose unique challenges due to handling sensitive data, yet operating in a fragmented regulatory landscape (for challenges in assessing mHealth app privacy, see [85]). Our work adapts core privacy principles to mobile-specific privacy threats (PT1–PT3), while avoiding reliance on user perceptions. NLP for Privacy Analysis: NLP has emerged as a critical tool for auditing mobile app privacy practices. Recent work addresses regulatory alignment (e.g., mapping GDPR requirements [86]) and risks of sensitive data leaks (e.g., detecting PII mishandling [87]). Beyond compliance, researchers have identified systemic gaps between app behaviors and permission declarations (e.g., [88]).Subsequently, privacy-related text comprehension was improved with the use of retrieval-augmented language models [89] and recent generative language models [90]–[93]. Our use of NLP, however, is orthogonal to these advances, as we leverage language models to perform multi-label multiclass classification on app descriptions, where the language is more accessible to the average user, but the permission gap is harder to perceive.

8

C ONCLUSION

Our work brings to the forefront privacy-related concerns for mHealth apps. We define three privacy threats at the point of data collection, grounded in LINDDUN framework. Our analysis of these threats reveals that 69% of apps request permissions that are not substantiated by their stated purpose, only 7% of apps present consent acquisition mechanisms to users, and 1 out of 14 apps that present a consent form collects data not authorized by the user. This picture is problematic for users and regulatory bodies, as privacy best practices, even when coded in laws in many jurisdictions, are regularly and consistently ignored by app developers. One possible avenue for future work is that of automating regulatory compliance, i.e., building dedicated, privacy-focused tools—possibly based on what is used in ours and other measurement efforts—to automatically identify privacy threats in app behavior.

R EFERENCES [1] [2] [3] [4]

FTC Cerebral App: https://tinyurl.com/mtdrsr43. Frasco v. Flo Health: https://tinyurl.com/2vuyk494. mHealth Apps Market Size, https://tinyurl.com/rjn2rpcy. M. La Polla et al., “A survey on security for mobile devices,” IEEE Commun. Surv. Tutor., vol. 15, no. 1, pp. 446–471, 2013.

11

[5]

Y. Javed and A. Sajid, “A Systematic Review of Privacy Policy Literature,” ACM Comput. Surv., vol. 57, no. 2, 2024. [6] Z. R. Alkindi et al., “User Privacy and Data Flow Control for Android Apps: Systematic Literature Review,” JCSM, vol. 10, 2021. [7] M. Alloghani et al., “A Systematic Review on Security and Privacy Issues in Mobile Devices and Systems,” in Handbook of Computer Networks and Cyber Security: Principles and Paradigms, 2020. [8] J. M. Del Alamo et al., “Privacy assessment in Android apps: a systematic mapping study,” Electronics, vol. 10, 2021. [9] H. Mitchell, “Why Hackers Want Your Health Information,” The Wall Street Journal, 2024. [Online]. Available: https: //tinyurl.com/bp7k6hcj [10] P. Ruotsalainen and B. Blobel, “Health Information Systems in the Digital Health Ecosystem—Problems and Solutions for Ethics, Trust and Privacy,” International Journal of Environmental Research and Public Health, vol. 17, no. 9, 2020. [11] T. T. Nguyen et al., “Freely Given Consent?: Studying Consent Notice of Third-Party Tracking and Its Violations of GDPR in Android Apps,” in CCS, 2022. [12] ——, “Share First, Ask Later (or Never?) Studying Violations of GDPR’s Explicit Consent in Android Apps,” in USENIX Security, 2021. [13] S. Koch et al., “The OK Is Not Enough: A Large Scale Study of Consent Dialogs in Smartphone Applications,” in USENIX Security, 2023. [14] K. Kollnig et al., “A fait accompli? an empirical study into the absence of consent to Third-Party tracking in android apps,” in SOUPS, 2021. [15] A. Ardalani et al., “Towards precise detection of personal information leaks in mobile health apps,” in BigDaCI, CSC, and EH, 2024. [16] S. Kaufman et al., “Leakage in data mining: formulation, detection, and avoidance,” in KDD, 2011, p. 556–563. [17] I. Herrera Montano et al., “Survey of Techniques on Data Leakage Protection and Methods to address the Insider threat,” Cluster Computing, vol. 25, 2022. [18] M. Deng et al., “A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements,” Requirements Eng, vol. 16, no. 1, pp. 3–32, 2011. [19] K. Wuyts et al., “Effective and efficient privacy threat modeling through domain refinements,” in SAC, 2018. [20] C. Spensky et al., “SoK: Privacy on mobile devices – it’s complicated,” in POPETs, vol. 2016, no. 3, 2016, pp. 96–116. [21] K. Martin and K. Shilton, “Putting mobile application privacy in context: An empirical study of user privacy expectations for mobile devices,” The Information Society, vol. 32, no. 3, pp. 200– 216, 2016. [22] F. Ebrahimi et al., “Mobile app privacy in software engineering research: A systematic mapping study,” IST, vol. 133, p. 106466, 2021. [23] J. Dev et al., “Models of Applied Privacy (MAP): A Persona Based Approach to Threat Modeling,” in CHI, 2023. [24] R. Pandita et al., “WHYPER: Towards Automating Risk Assessment of Mobile Applications,” in USENIX Security, 2013. [25] Z. Qu et al., “AutoCog: Measuring the Description-to-permission Fidelity in Android Applications,” in CCS, 2014. [26] Y. Feng et al., “AC-Net: Assessing the Consistency of Description and Permission in Android Apps,” IEEE Access, vol. 7, 2019. [27] J. Feichtner and S. Gruber, “Understanding Privacy Awareness in Android App Descriptions Using Deep Learning,” in CODASPY, 2020. [28] M. Fan et al., “An Empirical Evaluation of GDPR Compliance Violations in Android mHealth Apps,” in IEEE ISSRE, 2020. [29] H. Alecakir et al., “Attention: There is an inconsistency between android permissions and application metadata!” IJIS, vol. 20, 2021. [30] A. Mohanty and M. Sridhar, “HybriDiagnostics: Evaluating Security Issues in Hybrid SmartHome Companion Apps,” in IEEE SPW, 2021. [31] G. Tangari et al., “Mobile health and privacy: cross sectional study,” BMJ, vol. 373, 2021. [32] X. Jin et al., “Understanding IoT Security from a Market-Scale Perspective,” in ACM CCS, 2022. [33] S. Neupane et al., “On the Data Privacy, Security, and Risk Postures of IoT Mobile Companion Apps,” in IFIP DBSec, 2022. [34] M. Hassan et al., “What is in your app? uncovering privacy risks of female health applications,” arXiv, 2023.

[35] A. Lyons et al., “Log: It’s Big, It’s Heavy, It’s Filled with Personal Data! Measuring the Logging of Sensitive Information in the Android Ecosystem,” in USENIX Security, 2023. [36] A. Xiang et al., “PolicyChecker: Analyzing the GDPR Completeness of Mobile Apps’ Privacy Policies,” in CCS, 2023. [37] S. Li et al., “Are We Getting Well-informed? An In-depth Study of Runtime Privacy Notice Practice in Mobile Apps,” in CCS, 2024. [38] WHO Director-General, “mHealth - Use of appropriate digital technologies for public health,” WHO, Tech. Rep., 2018. [39] M. H. Meng et al., “Assessing privacy disclosure compliance of android third-party sdks,” IEEE TSE, pp. 1–19, 2026. [40] K. Wuyts et al., “LINDDUN GO: A Lightweight Approach to Privacy Threat Modeling,” in EuroS&PW, 2020, pp. 302–309. [41] Advertising ID - Play Console Help https://tinyurl.com/2x6s2f mx. [42] J. Saltzer et al., “The protection of information in computer systems,” Proceedings of the IEEE, vol. 63, no. 9, pp. 1278–1308, 1975. [43] European Parliament and Council of the European Union, “Regulation (eu) 2016/679 (general data protection regulation),” 2016. [Online]. Available: https://data.europa.eu/eli/reg/2016/ 679/oj [44] Judgment of the Court (Grand Chamber) of 4 July 2023. Meta Platforms Inc and Others v Bundeskartellamt: https://eur- lex .europa.eu/legal-content/EN/TXT/?uri=celex%3A62021CJ0252. [45] Opinion 2/2010 on online behavioural advertising: https://tinyur l.com/mvn9725h. [46] X. Wang et al., “Looking from the Mirror: Evaluating IoT Device Security through Mobile Companion Apps,” in USENIX Security, 2019. [47] A. Graves and J. Schmidhuber, “Framewise phoneme classification with bidirectional LSTM networks,” in IJCNN, vol. 4, 2005. [48] J. Devlin et al., “BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding,” in NAACL, 2019, pp. 4171– 4186. [49] P. He et al., “DeBERTa: Decoding-enhanced BERT with Disentangled Attention,” arXiv, 2021. [50] Y. Liu et al., “RoBERTa: A Robustly Optimized BERT Pretraining Approach,” arXiv, 2019. [51] V. Sanh et al., “DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter,” arXiv, 2020. [52] K. Allix et al., “AndroZoo: Collecting millions of Android apps for the research community,” in MSR, 2016. [53] R. K. Vaidya et al., “Security Issues in Language-based Software Ecosystems,” arXiv, 2021. [54] “Using the API,” https://tinyurl.com/5n8asfa6, 2025. [55] Y. Tamrakar et al., “Harnessing Language Models to Analyze Android App Permission Fidelity,” in PST, 2025. [56] Distilbert/Distilroberta-Base: https://tinyurl.com/bdhncyaw. [57] Z. Yang et al., “XLnet: Generalized Autoregressive Pretraining for Language Understanding,” in NeurIPS, 2019. [58] J. Zhang et al., “Do BERT-Like Bidirectional Models Still Perform Better on Text Classification in the Era of LLMs?” arXiv, May 2025. [59] Hello GPT-4o https://openai.com/index/hello-gpt-4o/. [60] Open source interactive HTTPS proxy: https://mitmproxy.org/. [61] sensepost/objection https://github.com/sensepost/objection. [62] S. Willison, “sips Man Page - macOS - SS64.com.” [Online]. Available: https://ss64.com/mac/sips.html [63] Easyocr https://tinyurl.com/bdhs5sxk. [64] S. Hoffstaetter, Pytessaract: https://pypi.org/project/pytesseract. [65] M. Li et al., “Trocr: Transformer-based optical character recognition with pre-trained models,” in AAAI, 2023. [66] Z. Huang et al., “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction,” in ICDAR, 2019, pp. 1516–1520. [67] L. Li et al., “Static analysis of android apps: A systematic literature review,” Information and Software Technology, vol. 88, 2017. [68] jadx: https://github.com/skylot/jadx. [69] N. Reimers and I. Gurevych, “Making monolingual sentence embeddings multilingual using knowledge distillation,” in EMNLP, 2020. [70] L. Tunstall et al., “Efficient few-shot learning without prompts.” arXiv, 2022. [71] A. P. Felt et al., “Android permissions demystified,” in CCS, 2011, pp. 627–638. [72] G. Xu et al., “Perhelper: Helping developers make better decisions on permission uses in android apps,” Applied Sciences, vol. 9, 2019. [73] P. Liu et al., “Identifying and characterizing silently-evolved methods in the android api,” in ICSE-SEIP, 2021, pp. 308–317.

12

[74] N. Alomar and S. Egelman, “Developers Say the Darnedest Things: Privacy Compliance Processes Followed by Developers of Child-Directed Apps,” POPETS, 2022. [75] H. Peng et al., “Using probabilistic generative models for ranking risks of android apps,” in CCS, 2012. [76] A. Merlo and G. C. Georgiu, “RiskInDroid: Machine LearningBased Risk Analysis on Android,” in IFIP SEC, 2017. [77] Y. Jing et al., “RiskMon: Continuous and automated risk assessment of mobile applications,” in CODASPY, 2014. [78] S. Arzt et al., “FlowDroid: Precise context, flow, field, objectsensitive and lifecycle-aware taint analysis for Android apps,” in PLDI, 2014. [79] H.-Y. Huang et al., “Evaluating User Behavior in Smartphone Security: A Psychometric Perspective,” in SOUPS, 2023. [80] A. P. Felt et al., “Android permissions: user attention, comprehension, and behavior,” in SOUPS, 2012. [81] J. Mohan et al., “Analyzing GDPR Compliance Through the Lens of Privacy Policy,” in Heterogeneous Data Management, Polystores, and Analytics for Healthcare. Springer-Verlag, 2022, pp. 82–95. [82] Z. Liu et al., “Opted Out, Yet Tracked: Are Regulations Enough to Protect Your Privacy?” POPETs, pp. 280–299, 2024. [83] M. Ferreira et al., “RuleKeeper: GDPR-Aware Personal Data Compliance for Web Frameworks,” in IEEE S&P, 2023. [84] G. Sassetti et al., “Assurance, Consent and Access Control for Privacy-Aware OIDC Deployments,” in DBsec, 2023, pp. 203– 222. [85] J. Benjumea et al., “Privacy Assessment in Mobile Health Apps: Scoping Review,” JMIR Mhealth Uhealth, vol. 8, no. 7, 2020. [86] G. B. Herwanto et al., “Leveraging NLP Techniques for Privacy Requirements Engineering in User Stories,” IEEE Access, 2024. [87] P. Silva et al., “Using NLP and Machine Learning to Detect Data Privacy Violations,” in INFOCOM WKSHPS, 2020, pp. 972–977. [88] R. Maji et al., “A Novel Proposal of Using NLP to Analyze IoT Apps Towards Securing User Data,” in CISIM, Cham, 2021, pp. 156–168. [89] X. Zhang et al., “Enhanced Privacy Policy Comprehension via Pre-trained and Retrieval-Augmented Models,” in IEEE TrustCom, 2024. [90] T. B. Duc et al., “Advancing GDPR Adherence: Leveraging Generative AI for In-Depth Privacy Policy Analysis in Android Apps,” in ICAISC, 2025, pp. 50–61. [91] T. H. T. Phan et al., “Evaluating Third-Party Involvement in Android Apps: Norms andAnomalies in Usage Patterns,” in MobiWIS, 2024. [92] R. C. Salvi et al., “PrivacyChat: Utilizing Large Language Model for Fine-Grained Information Extraction over Privacy Policies,” in Wisdom, Well-Being, Win-Win, 2024, pp. 223–231. [93] M. Zoubi et al., “Privat5: A generative language model for privacy policies,” in Workshop on Privacy in Natural Language Processing, 2024.

Related documents

• Privacy Assessment in Mobile Health Apps: Scoping Review#400444
• The Not So Innocent Nudge: Why the Hooked Nudges for Smartphone Apps Undermine Autonomy#699202
• Addressing Mental Health of Cancer Patients and Caregivers Using a Mobile App Suite#868811
• Consumer Involvement in the Co-Design of Diabetes Self-Management Smartphone Apps: A Scoping Review.#396195
• SIGNAL:Identifying Behavioral Anomalies Using Smartphones to Improve Cancer Care#893970