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
Since some sort of firmware is required, this seems like a "turing tarpit" security exploit from my laymans perspective.

There's no standard that I know, that, like "Secure EFI / Boot" (or whatever exact name it is), locks the API of periphery firmware and that would be able to statically verify that said API doesn't allow for unintended exploits.

That being said: imagination vs reality: the Turing tarpit has to be higher in the chain than the webcam firmware when flashing new firmware via internal USB was the exploit method.

>>moritz+6e
No firmware is required. Macbooks manufactured since 2014 turn on the LED whenever any power is supplied to the camera sensor, and force the LED to remain on for at least 3 seconds.

(Source: I architected the feature)

>>axoltl+ij
Thanks for your reply — yourself as the Source can only make me feel flattered then for you responding to me.

> Macbooks manufactured since 2014 turn on the LED whenever any power is supplied to the camera sensor, and force the LED to remain on for at least 3 seconds.

That convinced me originally I think, good old days! I'd almost forgotten about it. The way you phrased it, it sounded like 50% OS concern to me.

But if cam & LED rly share a power supply, and the LED is always on without any external switch, Good then!

>>moritz+2l
I was not very popular with the camera firmware folks for a while. They had to re-architect a bunch of things as they used to occasionally power on the camera logic without powering the sensor array to get information out of the built-in OTP. Because the LED now came on whenever the camera was powered they had to defer all that logic.

>>axoltl+nn
What does OTP stand for in this case? The camera PROM??