Having the LED control exposed through the firmware completely defeats this.
> All cameras after [2008] were different: The hardware team tied the LED to a hardware signal from the sensor: If the (I believe) vertical sync was active, the LED would light up. There is NO firmware control to disable/enable the LED. The actual firmware is indeed flashable, but the part is not a generic part and there are mechanisms in place to verify the image being flashed. […]
> So, no, I don’t believe that malware could be installed to enable the camera without lighting the LED. My concern would be a situation where a frame is captured so the LED is lit only for a very brief period of time.
The LED should be connected to camera's power, or maybe camera's "enable" signal. It should not be operable via any firmware in any way.
The led also has to be connected through a one-shot trigger (a transistor + a capacitor) so that it would light up, say, for at least 500 ms no matter how short the input pulse is. This would prevent making single shots hard to notice.
Doing that, of course, would incur a few cents more in BOM, and quite a bit more in being paranoid, well, I mean, customer-centric.
Wiring it in like this is suboptimal because this way you might never see the LED light up if a still photo is surreptitiously captured. This has been a problem before: illicit captures that happen so quickly the LED never has time to warm up.
Controlling the LED programmatically from isolated hardware like this is better, because then you can light up the LED for long enough to make it clear to the user something actually happened. Which is what Apple does -- three seconds.
I don't see why they should be mutually exclusive