For what it's worth, you could just power on the camera, take a pic, then turn it back off instead. Provided you can do this fast enough, an indicator LED is rendered worthless. So you'd need to make the indicator LED staggered, to stay lit for a minimum amount of time.
There's also the scenario where the LED or the connections to it simply fail. If the circuit doesn't account for that, then boom, now your camera can function without the light being on.
Can't think of any other pitfalls, but I'm sure they exist. Personally, I'll just continue using the privacy shutter, as annoying as that is. Too bad it doesn't do anything about the mic input.
I worked on this feature for Apple Macbooks around 2014 as the security architect. All Macbooks since then have a camera indicator LED that is (barring the physical removal of the LED) always on at least 3 seconds. This feature is implemented in gates in the power management controller on the camera sub-board.
There's a LOT of pitfalls still (what if you manage to pull power from the entire camera sub-assembly?), this was a fun one to threat-model.
A minimum light duration seems pretty trivial to physically engineer.
For one the energy to take a picture is probably enough to power a light for a noticeable amount of time.
And if it isn't, a capacitor that absorbs energy and only allows energy through once it's full would allow the light to remain on for a couple of seconds after power subsides.
Wasn't arguing that it's difficult, just that it's needed (and that I'm not expecting it to be done in practice. Because the indicator LED on my laptop doesn't do it either, despite being enterprise grade).
JIRA is "enterprise grade", I wouldn't place too much faith into that term.
Trust me, I was using it semi-sarcastically too. This thing is slower than my old Pentium 4 would be, yet has a fast enough 30% to 3% battery discharge rate that it would make the speed of light itself blush.
The main culprit is that anyone estimating battery life in percentages. It's about voltage and current draw. The battery voltage can be read directly.
About being slow, I suppose it does run windows and its infamous 'defender'
No, I think it's fairly easy to see that a third of the charge disappearing is a fairly uncommon behavior.
Same for your Windows idea...
> The main culprit is that anyone estimating battery life in percentages.
I thought this was a solved problem, like, decades ago? At least I remember even the first gen MacBooks having accurate battery percentages, and it’s a more vague memory but my PowerBook G4 did too I think.
LEDs are diodes. So you can run power _through_ them. Power Supply -> LED -> Camera.
While true, the amount of power would be too low, LEDs also have quite high forward voltage (~3V for blue ones) and they are current driven devices. That suggestion would require pass all the current through the LEDs. LEDs don't like to be reverse biased either. Overall, it's a rather appalling idea. On top of the fact that LEDs can fail short.
More also you'd want a hold up time for the light (few seconds at least), as taking pictures would flash them for 1/60 of a second or so.
They have high forward voltage /drop/ which is a useful property. You drive them with constant current for constant brightness and improved lifespan which is most pertinent for LED light bulb replacements than it is for a simple signal status light. Fixed delay before standby isn't hard to enforce either.
Even so this whole attack vector isn't solved with this. How long should the light stay on for after the camera is put in standby before a user considers it a nuisance? 5 seconds? So if I turn my back for longer than that I'm out of luck anyways.
The anti-TSO means would be a hardware serial counter with a display on the camera. Each time the camera is activated the number is incremented effectively forming a camera odometer. Then if my previous value does not match the current value I know it's been activated outside of my control.