Designing Permission Around Origin and Purpose
The evidence points to a design repair rather than a demand to abandon Health Connect's interoperability. The USENIX paper proposes a context-aware access decision that includes the requesting app, record type, originating app, purpose, and timeframe. This chapter turns that proposal into a practical model: readers will see what each field contributes, why metadata must be covered by the same boundary, and how runtime enforcement and Play review can work together without pretending that stronger privacy controls are free or already implemented.
A request should name a relationship
A type-only request answers one question: what category of record does the app want? A context-aware request answers a relationship: who is asking, for which records, for what reason, and within what period. That difference can be made concrete with a hypothetical but ordinary use case. A coaching app wants to calculate a recovery score from exercise-session records created by a particular wearable over the last month. The access decision would not simply say “allow exercise data.” It would describe the requesting app, the record type, the source of the records, the recovery feature that needs them, and the period for which the feature should use them.
The paper expresses this model as the tuple ⟨requesting_app, record_type, originating_app, purpose, timeframe⟩. The tuple is a proposed mitigation, not a current Android feature documented in the supplied sources. Its value is that it makes the hidden questions in a type-level grant explicit.
Requesting app. The first field identifies which application is asking. This sounds obvious, but it prevents authorization from being treated as an abstract permission detached from the receiver. The user is not granting “the health ecosystem” a capability; they are granting a particular app access for a particular feature. The field also gives the platform a stable subject for policy checks: the app that requested access should be the app whose declared purpose, privacy policy, and runtime behavior are evaluated.
Record type. Type still matters. A purpose-bound request for exercise sessions is not automatically a request for blood pressure, reproductive-health information, or nutrition. Type-level minimization remains valuable because it limits the category of information that can be returned. The proposed model does not replace fine-grained types; it places them inside a larger context so that “which kind” is not mistaken for the whole answer.
Originating app. This field distinguishes the app that created the record from the app that wants to read it. The paper proposes that an app should, by default, access its own records, while records created by another app require explicit user authorization for a specific purpose and timeframe. That default changes the starting point from inherited category-wide visibility to a narrower relationship. Cross-app sharing remains possible, but it becomes a deliberate exception that can be explained to the user and checked by the platform.
Origin binding solves a problem that purpose alone cannot. Suppose two apps both say they provide “fitness insights.” One may want a user's own workout records; the other may want to combine data from a wearable. The purpose descriptions can sound similar while the provenance relationship is different. If the originating app is absent, the platform cannot express which source the user intended to include. Conversely, knowing the origin does not explain why the requesting app needs the records. Both dimensions are necessary.
Purpose. Purpose states the user-facing reason for access.