A permission prompt should explain purpose and scope
Aliases: permission rationale · permission scope · purpose string
What it is
Permission-purpose disclosure explains what an application will access, which observable function needs it, how long access continues, and whether data leave the device. A capability label such as “location” or “photos” does not reveal selection of one image, continual library scanning, or background upload. Scope includes object, precision, frequency, duration, and recipient so the consequence is predictable.
Why it happens
Operating systems authorize capabilities while people judge tasks and consequences. One broad permission can support several flows, leaving a semantic gap between the platform label and product use. A concrete rationale maps the active task to requested scope and supports a necessity judgment. “Improve your experience” distinguishes neither core from optional processing nor later function creep from the original authorization.
Studying it
Scenario comprehension tests can ask participants to predict objects collected, background behavior, upload, and refusal outcomes, with answers checked against implementation. Experiments can vary purpose specificity and scope dimensions, measuring prediction, choice stability, and later surprise rather than allowance alone. Technical audits should reconcile permission APIs, traffic, and background jobs; understood copy does not excuse implementation beyond scope.
Where it stops holding
A short prompt cannot contain every implementation detail. Its first layer should preserve decision-changing scope and link to navigable detail. Security detection may not disclose every rule but can still state data class, processing location, and retention boundary. Permission scope is not purpose: authorization for while-in-use location does not itself authorize advertising use of the trace.
Applying it
- Lead with the user action served and the data needed, then state precision, duration, background state, and upload.
- Explain one-time, while-in-use, and persistent access as outcomes rather than assuming platform vocabulary is understood.
- State the real refusal consequence without generalized failure or fear unsupported by dependency.
- Ask testers to draw the expected flow after reading, then inspect traffic and background behavior; revise copy or implementation for every unpredicted destination or excess use.