A capture indicator must be visible and unspoofable

What it is

The speaker on a hotel nightstand has a lamp. Off is read as “not capturing,” on as “capturing.” If firmware can hold the lamp off while the mic path is open, or hold it on while the path is dead, the lamp is spoofable. An unspoofable capture indicator must be visible in the room and bound to the real capture path, not painted as the opposite glyph by the same software. Visibility is “can be seen.” Unspoofability is “can be believed.”

Why it happens

An always-on mic has no shutter click. Almost the only signal people use for “is it capturing now” is the indicator. If that indicator is just another UI channel in the app or firmware, it shares no hard coupling with the mic’s power, clock, or data pins, and the two channels can lie: buggy or hostile software keeps an idle face while samples go to recognition. Unspoofable means the indicator grows out of the capture path — the same enable, the same rail: cut it and the lamp must enter the not-capturing state; open the path and idle appearance cannot be held. A hardware lamp is closer to this structure than a status-bar glyph, provided the lamp is not a second, independently PWM-able ornament. A disableable indicator is a different failure. Here the lamp is still on. It is acting.

Studying it

Run an indicator–path decoupling audit. List every software entry that lights the indicator, every entry that opens the mic path, two columns. Two questions: can you light the lamp without opening the mic; can you open the mic without lighting the lamp. Either direction is spoofability. User research in a hotel room or another unfamiliar room asks whether state can be judged from two meters, and whether trust collapses once people are told “the lamp might be fake.” Do not substitute “is this lamp attractive” for the coupling test. A firmware dump or schematic can show whether the lamp shares a rail with codec enable; an appearance walkthrough will miss a decorative LED.

Where it stops holding

An OS recording dot hard-wired to the system capture API cannot be replaced by an app lamp, and the app usually cannot fake the system dot — spoofing at application layer may leave the system layer trustworthy. On-device keyword spotting often uses a weaker always-on or breathing lamp for “listening,” a different strength from “audio is going to recognition”; one lamp for both states will not be saved by unspoofability, because the meaning is still mixed. Radios and cameras have their own physical conventions. An honest indicator is not a promise that content is not uploaded. It only warrants the capturing / not-capturing bit.

Applying it

• Tie the “audio is entering recognition or uplink” indicator to capture enable, not to the theme skin. Settings must not offer “replace the hardware lamp with a software icon” in a way that lets the two disagree.
• Acceptance needs both reverse cases: forcing the mic on must force the capturing state on the indicator; cutting enable must force the not-capturing state. “Lamp lights when we open the mic” is not enough. Also test “lamp off means the mic is not capturing.”
• For hotel and meeting-room devices strangers will meet, the box or the base should say how the lamp is coupled, so a decorative breathing LED is not taken as the capture lamp.
• How to check: on an engineering menu or a fixture, hold enable and the LED drive apart. If you can produce “lamp off, samples still flowing” or “lamp on, path already cut,” treat the indicator as spoofable and move it into hardware or a system-enforced layer.

Related

• Same group: M4.02.1 Always-listening is not always-recording · M4.02.3 Physical disconnect is the mute people can believe
• Nearby: C7.07 Privacy visibility of voice input · C7.16 Visible feedback for voice input · M4.07 Felt privacy of always-on microphones
• Search terms: unspoofable capture indicator · privacy LED · indicator coupling