O3.08.1Explicit privilege-elevation confirmationdesignresearch

Privilege elevation requires explicit confirmation

Aliases: elevation confirmation · authority-boundary transition · privilege transition

What it is

Explicit privilege-elevation confirmation requires a recognizable, active decision for the current transition before a subject crosses from existing authority into greater capability. Launching an application, opening a file, or completing an ordinary task cannot implicitly authorize administrator access, background control, or sensitive-data access.

Why it happens

Elevation changes the maximum harm of later actions but is often embedded in a primary task. A default button, stolen focus, or prior ordinary click cannot distinguish intent from accident, automation, or interface steering. Separate confirmation creates an auditable boundary event tied to requester and scope, but it is meaningful only when cancellation works and unrelated work is not held hostage.

Studying it

Have participants complete installation, settings, and maintenance tasks containing necessary, surprising, and maliciously bundled elevations. Measure recognition of the boundary change, safe refusal and continuation, and consistency between confirmation and actual authority. Adversarially test key bounce, focus switching, automation, and clickjacking. An “Allow” click alone does not prove informed intent.

Where it stops holding

Explicit confirmation does not require a dialog for every privileged API. Preauthorized managed policy, system services, and noninteractive environments can use auditable rules; emergency response may use preconfigured authority. Confirmation cannot repair ambiguous scope, excessive frequency, or an untrusted surface, and refusal should not destroy unrelated state.

Applying it

  • Before authority changes, use a protected component to show requester, target account, scope, and duration and require affirmative approval.
  • Keep initial focus off Allow, reject application-synthesized input, and return cancellation to an understandable state without unrelated loss.
  • Bind approval to the current request parameters; mutation or replay requires new confirmation.
  • Record request, display, approval, rejection, execution, and revocation states and fault-test for silent shortcuts.

Related

  • Same group: O3.08.2 Capability explanation · O3.08.3 Elevation lifetime · O3.08.7 Batch and silent requests
  • Adjacent: O3.06.3 System-level sensitive confirmation · O3.05 Warning fatigue
  • Search terms: explicit privilege elevation · authorization boundary · privilege confirmation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O3.08.1