H4.07.1one-time permission grantdesignresearch

A one-time grant lowers the person's risk

Aliases: Allow Once · ephemeral authorization · one-shot permission

What it is

A one-time grant (Allow Once) makes the capability available for the current task and expires when the task ends or the person leaves the app; the next time asks again. It cuts the risk that "allowed this time" becomes the future default. It fits looking up a route once, taking one photo, dropping one pin. This entry is about how long a grant lasts. It is not about whether location should be precise or approximate, and not about whether camera or photos should use a system picker.

Why it happens

An ongoing grant writes consent given in one situation as a lease across sessions. What was agreed to was "let navigation start," not "read location from now on." One-time shrinks the lease to the current session, so regret costs "don't tap Allow next time" rather than "find the toggle in Settings." The app pays another ask; the person does not have to remember what they once turned on. When the task is naturally single-shot, an ongoing grant creates residual risk, not residual convenience—convenience appears only when the same act will clearly be repeated.

Studying it

On a one-shot task (drop a pin, photograph an ID), compare Allow Once with While Using / Always as the default option.

Independent variables: default grade on the system dialog, whether Once is offered, whether the task repeats in the same session. Dependent variables: share choosing Once, later memory of whether the grant is still live, re-grant rate on the next task, how many people go to Settings to turn it off.

A second lab task usually follows immediately, which understates Once friction. Separate "reuse in this session" from "reuse the next day." A low Once rate is not evidence that people prefer ongoing—defaults and button order swallow preference.

Where it stops holding

An in-progress call, navigation, or live stream must keep the capability for the session; that is session-scoped authorization, not asking every few seconds. Accessibility toggles and long-lived health connections become harassment if every use is Once; that is where ongoing is legitimate. When the platform has no Once option, the app should stop reading at task end and say "we are no longer accessing this"—it must not pretend the system will reclaim the grant.

Applying it

  • For one-shot tasks (drop a pin, take one photo, verify an address once), treat Once as the recommended option; do not highlight ongoing as the default.
  • After Once expires, entering the same feature again must explain and request; do not silently reuse a cached coordinate or silently open the camera.
  • Keep the capability for a continuous task that has not ended (navigation in progress); stop collection in the ended state.
  • Verify by finishing a Once task, killing the process, and entering the same feature: the system should ask again. Check that no sensor or location API runs outside that grant window. Remove Once from the dialog as a contrast to see how many people are forced into ongoing—that share is the risk captured by the default.

Related

  • Within the group: H4.07.2 Ongoing grants need periodic review · H4.07.3 Grant duration needs a visible indicator
  • Adjacent: H4.06 Location Precision · H4.08 Camera and Microphone Permission · O1.10 Consent Granularity and Withdrawal
  • Search terms: Allow Once · one-time permission · ephemeral authorization

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H4.07.1