Collection needs an indicator the application cannot suppress

What it is

A trusted sensor-use indicator is controlled by a system or hardware layer above an ordinary application and appears compulsorily when a protected camera, microphone, or similar sensor is active. The application may explain purpose but cannot hide, cover, or counterfeit the signal. The indicator means that collection capability is active; it does not establish informed purpose or prove that captured content remains on-device.

Why it happens

If the collecting application also controls its indicator, malicious or defective software can suppress evidence precisely when it matters, making one actor both action and witness. Coupling display to operating-system resource mediation, a driver, or sensor power makes it follow real access rather than self-report. The closer the trusted boundary is to physical acquisition, the greater the privilege needed to bypass it.

Studying it

System tests can access sensors from foreground, background, embedded components, concurrent sessions, and abnormal termination, observing whether the indicator remains present and above application windows. Security assessment should attempt false inactive states, overlay, lower-level access, and brief capture pulses. Misses, false positives, suppressible paths, and indicator–resource agreement matter; ordinary API examples are insufficient.

Where it stops holding

A system indicator still depends on system integrity; an attacker controlling kernel or firmware may bypass it. Headless devices need a trusted companion, physical control, or audit trail. Continuous illumination communicates resource activity but not necessarily application, purpose, or recipient, which require a separate diagnostic layer.

Applying it

• Trigger the indicator from resource grant or sensor power, never an application-supplied visibility parameter.
• Give the system layer top display priority so full-screen content, overlays, and themes cannot conceal it.
• Provide a trusted route to system-owned detail and revocation without letting applications imitate that control surface.
• Exercise public and lower-level paths with an adversarial test app, frame-aligning resource and display traces; treat any unindicated capture as a security defect.

Related

• Same group: O2.03.2 The indicator must appear when collection starts · O2.03.3 Indication is especially important for background collection · O2.03.4 Hardware lights resist spoofing and suppression better than software icons · O2.03.5 An indicator works only where users naturally look · O2.03.6 One light for multiple sensors obscures what is collecting · O2.03.7 Users must learn what the indicator means
• Adjacent: O3.06 Trusted path · O3.14 Trusted path and interface spoofing
• Search terms: trusted sensor indicator · unspoofable indicator · sensor mediation