O3.06.2Unspoofable system interface boundarydesignresearch

Applications should not be able to imitate system interfaces

Aliases: system UI anti-spoofing · overlay defense · unspoofable UI

What it is

An unspoofable system interface boundary uses system-exclusive capabilities and composition constraints so an ordinary application cannot create an equivalent security prompt, permission sheet, or credential surface. The aim is not a visual copyright ban; it prevents an application from copying appearance, position, input behavior, and system promise together.

Why it happens

Design specifications are public and screenshots are easy, so purely visual branding is copyable. An application can construct a coherent deception if it hides system regions in full screen, overlays prompts, shows a fake sheet first, or observes click locations. The system needs application-inaccessible regions, gestures, and input channels plus restrictions on overlays near secure state.

Studying it

Give a red team every ordinary application capability for windows, notifications, accessibility, and media, and ask it to imitate enrollment, authorization, and confirmation. Have unprimed participants distinguish and complete tasks while instrumentation verifies overlay, focus, and input isolation. Record the imitated property and deception route. Pixel comparison alone misses timing, animation, and input hijacking.

Where it stops holding

No general interface stays trustworthy on a fully compromised operating system. Overlay and capture restrictions can impair assistive tools, password managers, test automation, and remote support, which need controlled APIs rather than blanket disablement. Applications can explain why they request access but must not impersonate final system authorization. The boundary still has to be recognizable and usable.

Applying it

  • Reserve an application-inaccessible secure region or hardware-triggered state, blocking overlay, recording, and focus theft during protected input.
  • Generate prompts through one system API; let the requester supply only constrained name and purpose fields, not the whole surface.
  • Give legitimate assistive and management tools auditable authorization, visible indication, and revocation instead of arbitrary overlay power.
  • Regression-test anticipatory fake sheets, delayed overlays, clickjacking, notification imitation, and picture-in-picture after system UI changes.

Related

  • Same group: O3.06.1 System–application distinction · O3.06.3 System-level sensitive confirmation
  • Adjacent: O3.14 Trusted-path spoofing · O3.04.4 Visual lookalike deception
  • Search terms: unspoofable system UI · overlay attack · trusted interface boundary

Cards in the same group

Quick Actions

Share

Share this page

ios_share

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