zlacker

>>xairy+(OP)
I thought the whole point of these camera LEDs was to have them wired to/through the power to the camera, so they are always on when the camera is getting power, no matter what.

Having the LED control exposed through the firmware completely defeats this.

>>sbarre+T1
They are hardwired on Macbooks. From Daring Fireball, quoting an email from an Apple engineer.

> 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.

https://daringfireball.net/2019/02/on_covering_webcams

>>542458+96
That's backwards.

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.

>>nine_k+YR
or, you can have a physical switch, like the Framework. that also hits your BOM but its not complex!

>>jdblai+BY
This is the right solution. And a hardware switch cost is completely negligible in a $1000 laptop.

>>goodpo+pa1
But the margins?

>>xandri+nt1
Customers wouldn't care to pay a dollar more on a thousand plus device. This would likely increase the margin instead of shrinking it.