Client-Focused Security Assessment of mHealth Apps and Recommended Practices to Prevent or Mitigate Transport Security Issues
Bibliographic record
Abstract
BACKGROUND: Mobile health (mHealth) apps show a growing importance for patients and health care professionals. Apps in this category are diverse. Some display important information (ie, drug interactions), whereas others help patients to keep track of their health. However, insufficient transport security can lead to confidentiality issues for patients and medical professionals, as well as safety issues regarding data integrity. mHealth apps should therefore deploy intensified vigilance to protect their data and integrity. This paper analyzes the state of security in mHealth apps. OBJECTIVE: The objectives of this study were as follows: (1) identification of relevant transport issues in mHealth apps, (2) development of a platform for test purposes, and (3) recommendation of practices to mitigate them. METHODS: Security characteristics relevant to the transport security of mHealth apps were assessed, presented, and discussed. These characteristics were used in the development of a prototypical platform facilitating streamlined tests of apps. For the tests, six lists of the 10 most downloaded free apps from three countries and two stores were selected. As some apps were part of these top 10 lists in more than one country, 53 unique apps were tested. RESULTS: Out of the 53 apps tested from three European App Stores for Android and iOS, 21/53 (40%) showed critical results. All 21 apps failed to guarantee the integrity of data displayed. A total of 18 apps leaked private data or were observable in a way that compromised confidentiality between apps and their servers; 17 apps used unprotected connections; and two apps failed to validate certificates correctly. None of the apps tested utilized certificate pinning. Many apps employed analytics or ad providers, undermining user privacy. CONCLUSIONS: The tests show that many mHealth apps do not apply sufficient transport security measures. The most common security issue was the use of any kind of unprotected connection. Some apps used secure connections only for selected tasks, leaving all other traffic vulnerable.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.005 | 0.001 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.002 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.005 | 0.000 |
| Scholarly communication | 0.000 | 0.001 |
| Open science | 0.001 | 0.000 |
| Research integrity | 0.001 | 0.002 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one teacher head, not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".