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

• The study analyzes permission overreach, absent consent mechanisms, and collection beyond consent at the point of installation and initial use.The authors identify this as a critical juncture because users decide what data to provide and which permissions to enable.Source: §1 · p. 1
• Prior work either lacked an mHealth focus, examined small samples or limited threat types, or failed to measure consent gaps against actual collection at scale.Source: §1 · pp. 1–2
• Table 1 compares prior privacy measurement studies by mHealth focus, scale, and coverage of PT1–PT3.Source: Table 1 · p. 2
• Over 69% of apps requested permissions unrelated to their stated purpose, and nearly 93% lacked a consent acquisition mechanism.Source: §1 · p. 2

2.1 Scope: PII Categories

• The scope covers nine measurable PII categories, excluding categories requiring carrier-specific configurations or complex interactions beyond static analysis and reproducible runtime monitoring.Source: §2.1 · p. 2, Table 2 · p. 2

2.2 The LINDDUN Privacy Threat Framework

• The authors use LINDDUN and domain filtering to focus on privacy threats measurable at installation and permission granting, defining PT1–PT3 for that juncture.Source: §2.2 · p. 3

2.3 PT1 (Permission Overreach)

• PT1 is permission overreach: a fine-tuned language model predicts permissions justified by an app description, then compares predictions with requested permissions.The method’s best model achieved 99% ROC-AUC on its test set.Source: §2.3 · p. 3

2.4 PT2 (Absence of Consent Mechanism)

• PT2 is absence of a consent mechanism; automated app launches and initial-screen consent-language detection identified 254 distinct forms, with 99.6% accuracy after manual inspection.Source: §2.4 · p. 3

2.5 PT3 (Abuse of Consent)

• PT3 concerns PII collected beyond consent: among apps offering consent, the authors compare PII detected in network traffic and logs with claims identified in consent dialogs.Source: §2.5 · p. 4

2 BACKGROUND

• Prior studies often treated permission overreach, missing consent, and consent violations separately; none of the closest studies combined mHealth focus, 10,000+ app scale, and all three threats.Source: §2 · p. 2, §2.6 · p. 4

2.6 Summary

• The paper’s contribution is a LINDDUN-grounded, systematic measurement of PT1–PT3 across more than 10,000 mHealth apps.Source: §2.6 · p. 4

3.1 An Operational Definition of mHealth Apps

• The operational definition treats mHealth apps as mobile software used in health-related services, with primary roles spanning monitoring, disease management, telemedicine, and medication management.It prioritizes primary use cases and integration with healthcare workflows, data-driven decisions, or clinical and regulatory standards over general wellness features.Source: §3.1 · p. 4

3.2 Curation and Description of mHealth Apps

• A tailored collection framework addresses category and keyword errors, while a fine-tuned single model was found more accurate for mHealth identification than an ensemble approach.The classifier was trained on 5,000 annotated apps; DeBERTa achieved 0.946 accuracy and 0.916 F1, and the classifier identified 10,688 mHealth apps from 500,000 descriptions.Source: §3.2 · pp. 4–5
• 71.5% of apps in the Medical and Health & Fitness categories were labeled mHealth, indicating that Play Store categories alone are insufficiently precise for dataset collection.Source: §3.2 · p. 5
• App installs and reviews have heavy-tailed distributions, while ratings skew positively and cluster around 4.5.The authors note that a small fraction of apps accounts for most user reach, so their privacy practices affect many users.Source: §3.2 · p. 5, Figure 1 · p. 5

3.3 Developer Geolocation

• The developer-geolocation process achieved 98% accuracy in a 100-app manual validation and located 41% of apps, while over 61% lacked a developer location.The dataset covers major regulated markets but may underrepresent regions with sparse location data, making regional analysis partial.Source: §3.3 · p. 5

4.1 PT1: Permission Overreach

• Permission overreach (PT1) is measured as the difference between permissions declared in an app manifest and those predicted as justified by its description.A BERT multi-label classifier predicts justified permissions; PT1 is present when that gap is non-empty, within the 16 permissions covered by AC-Net.Source: §4.1 · p. 6

4.2 PT2: Absence of Consent Mechanism

• PT2 is identified when screenshots show no consent-related language while network data or logs contain personally identifiable information.Apps are installed, screens are captured, and UI fuzzing explores paths while network packets are monitored; the authors note that fuzzing provides no guarantee of coverage.Source: §4.2 · pp. 6–7

4.3 PT3: Abuse of Consent.

• PII detection searches network traffic and logs for identifiers and their encodings or transformations, using heuristics to distinguish app activity from Google Mobile Services traffic.On two manually labeled validation datasets, the heuristics reduced false positives by 66.2% in logs and 74.6% in network traffic, with 100% accuracy.Source: §4.3 · p. 7
• PT3 compares PII types disclosed in consent forms with those found in network data and logs to identify collection beyond acquired consent.Consent text is extracted using screenshots and app decompilation; a sentence-transformer model detects PII mentions in consent language.Source: §4.3 · p. 7

5 RESULTS

• 69.15% of apps exhibit permission overreach, nearly 93% lack an immediate consent mechanism, and 1 in 14 apps with consent collect beyond its disclosed scope.The three findings correspond to PT1, PT2, and PT3, respectively.Source: §5 · p. 7

5.1 PT1: Prevalence of Permission Gaps.

• 69% (6,936 of 10,036 apps) have at least one permission their descriptions do not justify; the median permission gap is 2.The median gap has an inter-quartile range of 4 permissions.Source: §5.1 · p. 7, Table 8 · p. 8
• The most highly downloaded apps have smaller average permission gaps: 1.24 for apps with 1M+ installs versus 2.79 for those with fewer than 10K installs.The differences across install bins were significant overall, but the 1M+ and 100K–1M pair did not differ significantly; only 41% of apps could be geolocated, and geographic comparisons have potential confounds.Source: §5.1 · p. 8, Figure 2 · p. 8

5.2 PT2: Absence of Consent Mechanism

• Only 253 of 3,599 analyzed apps (7%) displayed an immediate consent mechanism; the other 93% did not.The analysis was limited by app crashes and execution failures, and the authors caution against strong conclusions about geographic patterns.Source: §5.2 · p. 8, Table 9 · p. 8, Figure 5 · p. 9
• Consent rates were low across install bins, ranging from 1.54% for apps with fewer than 10K installs to 4.98% for apps with 1M+ installs.Differences across bins were statistically significant; the authors found no significant relationship between consent presence and user ratings.Source: §5.2 · pp. 8–9, Figure 4 · p. 9

5.3 PT3: PII Collection Beyond Consent.

• Of 253 apps with consent forms, 18 (7.1%) collected PII beyond what they disclosed, with each violating app exceeding disclosure in one PII category.The small sample limits stronger conclusions; the analysis found no significant correlation between consent-gap size and installs or average ratings.Source: §5.3 · p. 9, Table 10 · p. 9

Systemic Privacy Failures in mHealth

• Privacy violations appear even in apps from well-resourced developers, while the top 5% of apps account for 92% of downloads.The authors argue the problem is not simply a failure by under-resourced developers to implement best practices.Source: §6 · p. 10

Limitations and Scope

• The analysis captures only initial app execution before account creation, enabling coverage of 3,500+ to 10,000+ apps across the three threat types.Automated testing that included account creation was inefficient in time and computational resources and had high failure rates.Source: §6 · p. 10
• Dynamic-analysis failures can create selection bias and conservatively underestimate observed privacy threats; the study also covers Google Play Store apps only.The authors identify automated privacy auditing as a possible market-access condition and point to user-awareness measurement and scalable analysis as research directions.Source: §6 · p. 10

App Analysis Beyond Privacy

• Mobile-app studies measure risks such as missing consent, permission overreach, and deficient privacy policies, while threat-modeling work develops frameworks for understanding privacy threats.Other mobile research addresses risk scoring, runtime behavior, static taint analysis, and human factors, but the authors say these approaches lack precision for privacy-centric mHealth measurement.Source: §7 · p. 10

Privacy Beyond Mobile Apps; NLP for Privacy Analysis

• Privacy-compliance research commonly addresses cloud services, websites, and identity management, while this work adapts privacy principles to mobile-specific threats without relying on user perceptions.The paper uses language models for multiclass classification of app descriptions, which are more accessible to users but make permission gaps harder to perceive.Source: §7 · p. 10

8 CONCLUSION

• 69% of apps request permissions not substantiated by their stated purpose, only 7% present consent mechanisms, and 1 in 14 apps with consent collect data the user did not authorize.The authors conclude that privacy best practices encoded in laws are regularly and consistently ignored by app developers.Source: §8 · p. 10
• The authors identify automated regulatory-compliance tools as one possible avenue for future work to identify privacy threats in app behavior.They suggest such tools could draw on this and other measurement efforts.Source: §8 · p. 10