Overview
Android Health Connect offers a shared on-device layer for standardized health and fitness records, with type- and operation-based permissions that support interoperability. This series shows why that boundary can remain semantically broad: a type grant may reach records from multiple apps and expose provenance, device context, or flexible-field content, while purpose, timeframe, background use, export, and revocation remain only partly connected to the user’s choice. It then tests the concern against a defined study sample of 351 analyzed apps, separating observed behavior from universal claims and distinguishing cross-app capability from confirmed policy violations. The proposed repair binds requester, type, origin, purpose, and timeframe, extends controls to metadata, and combines runtime enforcement with disclosure and review. It strengthens meaningful control without treating all sharing as improper or the proposal as current Android functionality.
Learning outcomes
- Health Connect permissions are fine-grained by record type, but type alone does not bind origin, purpose, or timeframe.
- The study observed network transmission in 69 of 351 analyzed apps under its strict leak definition.
- Cross-app sharing can be legitimate, yet type-level access cannot itself distinguish intended sharing from incidental category-wide reach.
- A proposed model binds requester, type, origin, purpose, and timeframe, but it is not documented current Android functionality.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
Why can Android Health Connect's fine-grained permissions still be too broad?
Because a record-type grant can reach all records of that type, including records created by other apps, without binding access to origin, purpose, or timeframe.
What did the USENIX study find about Android Health Connect apps?
In a defined sample of 351 apps, it observed disclosure failures, cross-app reads, and network transmissions; 69 apps transmitted Health Connect data under its strict definition. The results are not a census.
How would origin- and purpose-bound Health Connect access work?
It would tie a request to the requesting app, record type, originating app, user-facing purpose, and timeframe, then enforce that scope at access time. This is a proposed mitigation, not a current documented Android feature.
Does revoking Health Connect access erase data already shared?
No. Revocation or a synchronization toggle can limit future platform activity, but it cannot by itself restore visibility or control over data already exported, retained, or derived downstream.