Name a concrete feature, not a generic purpose
Aliases: purpose specification · generic rationale · function-level disclosure
What it is
Permission copy has to land on an observable feature: "use location to show the walk to the store," "use the camera to photograph this policy"—not "to provide a better experience," "for operations and security." A generic purpose cannot be checked for necessity, and cannot stop the same grant from being reused later. This entry is about granularity of the explanation. It is not about whether a pre-prompt should precede the system dialog, and not about writing optional capabilities as if they were mandatory.
Why it happens
A system permission name only marks a class of capability. The same Photos switch can pick one image or scan the whole library and upload it. People judge reasonableness by feature-level consequences, not by the capability noun. A specific sentence attaches the current task to the capability, so a mismatch is visible: why contacts, if all I am doing is changing an avatar. Generic copy leaves the grant unbounded, so later uses still look covered by the old sentence, and purpose limitation fails in the interaction. Short and specific predicts behavior better than long and empty.
Studying it
Write a feature-level sentence and a generic experience sentence for the same permission; test understanding before or after the choice.
Independent variables: whether the purpose names a feature, whether it says if data leaves the device, whether it says one-shot versus ongoing. Dependent variables: accuracy predicting which step will use it, whether it uploads, whether the app still works on refusal; post-grant surprise; stability of the choice a day later.
Allow rate alone mixes "specific copy raised trust" with "specific copy scared off people who did not need the feature." The second drop is often healthy. Comprehension tests have to run without a product demo, or people infer purpose from the UI rather than from the copy.
Where it stops holding
System purpose strings have a character cap; feature-specific does not mean dumping implementation detail or legal exceptions into the dialog. When several features share one permission, the dialog should name this use, and the settings page should list the others—not a catalogue inside the alert. Regulator-required full notice can live in expandable detail; the dialog and pre-prompt still lead with the feature sentence.
Applying it
- For each permission, prepare "capability + current feature + optional scope" (background or not, upload or not). Ban standalone phrases that name no feature: "improve experience," "personalize," "protect your security."
- When one permission serves several features, the dialog and pre-prompt name only the use that triggered this ask; list the rest on the permission settings screen.
- Match copy to the API actually called: if the sentence says "pick one photo," use the system picker, not full library access.
- Verify by showing uninvolved people the copy only, with no later UI, and asking them to list what the app will and will not do next. Guesses that collapse into "a better experience," or that miss the feature about to run, mean the explanation failed.