O3.06.3System-mediated sensitive-action confirmationdesignresearch

Sensitive actions require system-level confirmation

Aliases: system-level confirmation · trusted transaction confirmation · trusted confirmation

What it is

System-mediated sensitive-action confirmation has the operating system or protected execution environment generate final confirmation from parameters that will actually execute, then binds approval cryptographically or statefully to that object. An in-app “continue?” represents only the application's claim; if the app can later replace recipient, privilege, or data scope, confirmation constrains nothing.

Why it happens

A malicious or compromised application can display a benign summary but submit different parameters below, or reuse approval after the click. A system component at the authorization–execution boundary can read normalized parameters, protect confirmation input, and issue one-use authority. Binding what is shown to what is authorized prevents interface deception and post-confirmation substitution.

Studying it

Use test applications to request normal and maliciously altered transfers, key export, privilege grant, or account change. Replace parameters before confirmation, after display, and after approval; replay old approvals; reconcile execution with the shown summary. User research measures whether critical objects can be checked and the cost to legitimate work. Technical consistency and human comprehension are both necessary.

Where it stops holding

System confirmation does not guarantee that the user knows the recipient or understands every business consequence, and it cannot repair a compromised system. Too many parameters become an unreadable list, so prioritize decision-relevant fields with expansion. Escalating every low-risk, frequent, reversible action recreates warning fatigue; batches need trustworthy aggregation and exception display.

Applying it

  • Have the protected component read destination, amount, privilege, data scope, and reversibility from the execution request rather than accept an application-rendered screenshot.
  • Bind the approval token to normalized parameters, requesting application, account, expiry, and one-time use; any change requires reconfirmation.
  • Put decision-changing fields first, emphasize new or anomalous values, and provide safe cancellation and independent review.
  • Test substitution, replay, overlay, race, and hidden batch items, reconciling execution logs with the confirmation displayed.

Related

  • Same group: O3.06.1 System–application distinction · O3.06.2 System UI anti-spoofing
  • Adjacent: O3.08 Privilege-elevation confirmation · O3.14 Trusted-path spoofing
  • Search terms: trusted transaction confirmation · what you see is what you sign · system-mediated authorization

Cards in the same group

Quick Actions

Share

Share this page

ios_share

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