A hardware mute switch feels different from a software promise

I built a Raspberry Pi desk hub with a front-panel cutoff for its microphone and camera. The switch drives a relay in their power path, and a separate LED makes the state visible from across the desk. I also used a resistor with the Pi-controlled LED, rather than treating a GPIO pin like a power source.

What bothers me about ordinary mute icons is that they report what software believes: “the sensor is off.” A physical cutoff gives me something I can inspect, although I’m still thinking through whether cutting camera power alone is enough for every threat model. The trade-off is real: no microphone means no voice commands until I reconnect it, and the relay, wiring, and enclosure make the hub bulkier.

Would you sacrifice that convenience for a verifiable physical disconnect? I’d like to hear better DIY designs—or convincing counterarguments.

The distinction is sound, but I’d avoid calling a relay a complete guarantee. If it only interrupts camera power, the data path may still deserve attention depending on the module and threat model. I’d document exactly what is disconnected, then treat the LED as confirmation of the mechanism—not proof of every privacy property.

I like the physical boundary, but relays add failure modes: contact wear, startup behavior, and another bundle of wiring in a small enclosure. My preference would be a normally-open arrangement where the default state is disconnected, with the indicator powered from the switched side. That makes “off” less dependent on Pi software.

The enclosure cost is probably the bigger obstacle than the electronics. A visible switch changes the social meaning of the device: people nearby can see whether recording is possible without trusting a tiny icon. I’d make the action deliberately physical, even if that means voice control is occasionally inconvenient.

I’m not sure “verifiable” always beats software. A physical control can be miswired, stuck, or misunderstood, while software can expose more detailed states than a binary LED. I’d use both: hardware cutoff for high-confidence privacy, software status for diagnostics and reminders when the cutoff blocks expected input.

The strongest part of this design is the narrower claim. You can verify that a particular power path is interrupted; you cannot automatically generalize that to every camera or microphone signal path. A small wiring diagram and a stated cutoff boundary would make the project much more persuasive than a generic “hardware is safer” label.