State the specific purpose, not a generic reason

What it is

A just-in-time permission purpose disclosure says which data or device capability a product will access, which task that access serves now, and the relevant scope or mode of access. When material to the decision, it also names who receives or processes the data, whether access follows a user action or continues in the background, and whether it recurs. “Use the microphone to record this message and upload it to participants in this call” is inspectable in a way that “improve your experience” is not.

Product explanation and an operating-system or browser prompt have separate jobs. Product copy reconnects the ask to the current task and supplies the use known to the product; the platform prompt presents platform-defined scope, choices, and controls. Product copy cannot override the resulting authorization state or hide the real choices behind a simulated system dialog.

Why it happens

Permission labels name technical capabilities, not product behavior. Photos, location, and notifications can support different tasks, recipients, and access frequencies. Without a purpose account, people must infer what this particular invocation will do. A just-in-time explanation connects capability or data, current function, and processing mode as a testable promise, letting people judge whether the requested scope is proportionate. Timing adds evidence—a camera request after someone invokes scanning is more intelligible than an ask at launch—but timing does not replace the account.

The copy must be constrained by the real data flow and permission call. If it says “for this upload only” while the product continues access in the background or sends data elsewhere, specificity makes the broken promise more legible. Recipient, frequency, and background behavior belong when they can change this decision and can be stated accurately. Anti-abuse details may be bounded where disclosure would enable evasion, but safely disclosable purpose cannot be replaced with a vague benefit.

Studying it

Trigger permission in a realistic task and, before the choice, ask participants what will be accessed, for what task, by whom, when or how often, and which scopes the platform offers. Record purpose and scope comprehension, decision time, help seeking, refusal rationale, task completion, and later revocation. Grant rate alone is not a quality measure. In comparisons among no product explanation, concise inline rationale, and layered detail, hold permission scope, task value, platform prompt, and timing constant.

Include first request, already-decided state, selected-content access, one-time or while-in-use scope, and background access where supported. Test copy against the actual platform prompt on each target device. Keyboard, screen-reader, zoom, and large-text checks should confirm that the rationale is available before commitment. If a pre-prompt adds a step without improving understanding, let clear task context and the platform dialog do the work instead of assuming another screen is always beneficial.

Where it stops holding

A custom pre-prompt is not universally required. When purpose follows uniquely from the action and the platform dialog is sufficient, repetition may add interruption without information. Platform rules may prohibit a pattern, constrain wording, or impose an order. Conversely, background access, outside recipients, cross-feature reuse, and easily misunderstood scope usually need more than a single purpose phrase, delivered through layered detail.

Just-in-time copy does not replace a privacy notice, data-minimization analysis, lawful-processing decision, or legally required consent mechanism; specificity does not make access legitimate by itself. Point-of-entry field explanation covers why a field is collected, its necessity, audience, and consequences. A device or account permission explanation covers the capability grant and platform control. They must agree when both occur, but neither substitutes for the other.

Applying it

• Maintain permission or data, task or purpose, scope, recipient, trigger or frequency, background behavior, owner, and copy version for every request surface. Reconcile them with API calls, data flow, and platform configuration before release.
• Place the shortest decision-sufficient account immediately before the platform ask while return remains possible: what is accessed, for which current task, and the key scope. Expand recipient, frequency, and background behavior only when they affect choice. Buttons may continue to the request or defer it; they must not masquerade as platform authorization controls.
• Read the scope the platform actually supports and tailor the account for selected content, precise or approximate location, while-in-use, or one-time access. Do not promise controls the platform does not offer, and do not replay first-request framing after a decision already exists.
• Audit permission calls and versioned copy snapshots for implementation alignment. Validate with comprehension, task completion, revocation, and mismatch complaints rather than grant conversion alone.

Related

• Same group: T2.07.2 Never overstate necessity to win the grant · T2.07.3 Explain what refusing will cost
• Adjacent: T2.03.3 Fields of unclear purpose need explanation · O2.01.3 Timing determines whether necessity is intelligible
• Search terms: just-in-time permission · permission rationale · purpose disclosure