A physical recording indicator: privacy improvement or comforting theater?

I built a small recording-state box for my home lab: a microcontroller drives an LED and a relay, and the relay cuts power to the microphones or cameras rather than trusting a software icon. It feels more honest, but I’m not sure how much privacy it actually buys.

The useful part is fail-closed behavior: normally closed is not automatically safe, so I’m designing the inactive state and boot state deliberately, with external pulls and a proper relay driver rather than asking a Pi GPIO to do too much. I also cut peripheral power, not Pi power, because sudden shutdowns can corrupt storage. The downside is relay wear, testing, maintenance, and one more switch people may ignore. It should probably be open-source with schematics, firmware, parts, ratings, and failure tests—not just code.

Have you built comparable privacy hardware, or is a physical kill switch worth the inconvenience?

It improves the threat model, but only narrowly. A powered-off microphone cannot provide microphone data; that does not stop host telemetry, network metadata, or another sensor. I’d label the LED “sensor power,” not “private.”

The boot state is where the clever diagram usually goes to die. I’d want an external pull resistor and a watchdog whose failure leaves the sensor supply off. Also test relay behavior after brownouts, not just clean resets.

The usability risk is real. If enabling the camera requires reaching behind a box and waiting through a ritual, someone will bypass it. A clear physical control and an unmistakable state indicator probably matter more than adding another layer of firmware.

“Open source” should mean more than a repository. Schematics, bill of materials, relay ratings, firmware versioning, provenance, and recorded failure-mode tests would make the audit claim much more credible.

I’d skip the relay if the peripheral supply can be switched cleanly with a suitable solid-state design, but that depends on the loads and isolation requirements. The important bit is not choosing a fashionable component; it’s proving the off state electrically.

The LED needs a very explicit convention. “Green means probably available” is weaker than “red means sensor power physically present.” People read status lights socially, and ambiguity becomes permission to stop checking.

A physical switch is inconvenient. That is also why it might work. Software promises are easy to ignore; a deliberate hand movement is harder to misinterpret, provided the box does not quietly fail in the opposite state.

I like the separation between the Pi and the peripheral supply. Cutting Pi power creates a storage problem; cutting only the sensor rail keeps the control system alive long enough to report state and perform orderly recovery.

Don’t forget maintenance. Relays have contacts, connectors loosen, and LEDs can fail. I’d include a periodic self-test plus a manual verification procedure, while treating a successful software test as evidence about the controller—not proof that the camera is powerless.

I’m less convinced for a home lab unless the threat model includes accidental recording or compromised applications. For a hostile device, I’d want independent power-path inspection too. Still, reducing one capability is not false confidence if the claim stays that limited.