But you just moved the goal-posts from a discussion about whether the implementation was faulty (and Apple was misleading their product owners) to one about whether the design compromises are right.
Apple claims that the LED comes on when the camera is active, which it claims helps protect your privacy. That seems to be true, and certainly no-one seems to have any contradictory examples that are not 12+ years old.
I can argue that when one uses a sliding cover, one can easily forget to reset it after a video chat. The design is bad. The right solution is simply not to have a camera. It's just a different design compromise.
The question is whether this is a firmware implementation that's just waiting for a 0-day or if the +V for the CMOS sensor is literally wired to the LED. If the latter I'd like to see a picture of it.
I was the security architect for this feature on recent Macs. The LED is wired to the camera PMIC and is powered by the voltage rail that powers the camera. The PMIC will always remain on if the system has power. Macs newer than 4 or so years also have a feature that forces the LED to stay lit for at least 3 seconds after it has been turned on to prevent the single-frame-grab attack.
Ah, good. Is the microphone similarly protected? Sometimes I feel I must be the only person on earth who doesn't use their laptop while naked and couldn't care less if the imager was watching me. The microphone, however, could be an actual security threat. Phone calls, muttered passwords, etc.
There is a little LED that lights up when they open. The door latch is controlled via software and so is the light, though I would assume in the case of power failure they'd unlock for fire safety reasons.
I know where you were going with that, but the situation is different than what you’re trying to show. On Macs the light is on the path of the camera: if it is on the camera is, if it is not then the camera is not. Whereas with the door you might think that if it was latchless someone could just push it open when the light was off. The camera light is really a door alarm, not a door latch. (And as I just mentioned, doors with an alarm but no lock often do exist, usually for fire safety reasons).
A door without a latch does not prevent
an unauthorized person from trespassing.
A camera without a cover does not prevent
an unauthorized person from trespassing.
So you have to perpetually watch out for the LED indicator to see if it ever randomly turns on for 3 seconds? And what if it does come up unexpectedly? At this point it's too late and you've already been captured. A mechanical cover that can slide on and off the camera seems like much better security.
The point is that the hardware has been designed properly. Combined with the OS-level permissions, it should be assurance enough for the majority of use cases.
If you need further assurances, then by all means, use a physical cover.
The claim was that single-frame grab attempts are prevented by an indicator that stays on for 3 seconds. First, you do have to be alert for all of these potential 3 seconds windows, and second, it doesn't prevent anything but only tell you that it has already happened.
No, it wasn't. The claim was whether it was implemented correctly, as the entire conversation started with examples where it was not implemented correctly.
Properly designed hardware would add one small - and in every way possible, since we've already identified the circuit that drives the single power source - addition. A physical switch that prevents camera from being turned on. Same for the microphone. Unfortunately, this is never done. So people put covers on.
According to an anonymous Gruber source, Apple fixed the issue by tying the led to the Vsync on the camera board. I have not found a teardown or anything other than this confirming it https://daringfireball.net/2019/02/on_covering_webcams
I had a laptop with a physical switch for WiFi/Bluetooth in 2006 or so (with a matching orange/blue light that would turn up when you toggled it). The problem was that this was actually all done by a software driver - when I booted into Linux with the laptop I was surprised to find that the bluetooth/wifi modules were on regardless of the switch's position.
At the end of the day, unless you have a really nice microscope, solid understanding of electrical engineering, and a few tens of thousands of hours ahead of you, you have to trust whoever you're buying the hardware from that it will do what they say it will. No amount of hardware efforts can solve the fundamental human trust problem.
I have a Lenovo Thinkpad T480. Its webcam switch is a slider that covers the webcam lens. You don't need a fancy microscope, or a solid understanding of EE, or tens of thousands of hours. You need the ability to see the slider cover the lens. Takes all of half a second and at least 1 eye.
And the hackers still win, cause no one remembers to slide it shut after a call, and they can hack the led so there is no physical indicator when they are watching.
I prefer aluminum foil under the tape that's over the lens so it can be flipped up out of the way easily but still block the view. But the cover does the same thing and doesn't take the effort of putting in a piece of tape.
It would be mildly impressive if a manufacturer made a fake cover with a switch to detect when it's "closed" and make the main camera stream filtered to look like the cover is real, while having a 2nd back-door unfiltered stream. Of course this could be detected by someone who took the unit apart.
On Thinkpads, the cover has a prominent red dot painted on it, that ends up in the location where camera lens would normally be. And, of course, you can visibly see the edge of the cover move as you slide it. So I don't know how you'd fake that.
It's like the halting problem. It's hard to decide whether a given switch works in the general case. But it's possible to design an obviously correct breaker.
Edit: the gnarly thing might be ensuring it doesn't harvest power through data wires or store power in covert capacitors or batteries.
I had another laptop with a hardware switch and a corresponding LED, and it worked exactly as it should - the hardware was completely inaccessible under Linux. So yes, it can be done and it's not rocket science.
Yes, what you describe is trivial - and it would be similarly trivial to design a module that appears to respect the switch (regardless of Linux/Windows) and yet records things surreptitiously, only to offload it at a later date.
Remember the amount of effort VW was willing to expand to cheat emissions testing.
The question isn't whether you can add a cover to the product after the fact, it's whether you can trust a switch on a product to do what the manufacturer says it does.
I don't see how that fixes the problem; if you don't trust Apple to build in hardware safeguards around the camera indicator light, why would you trust them with a hardware switch?
A hardware switch should in theory be more easily verifiable than a software one through physical testing. Running tests on PCB traces to verify that a switch indeed works is probably a whole lot easier in general practice than decapping chips or decompiling and analyzing low level firmware or low level OS components.
But are you going to run those tests on PCB traces on your own hardware? If not, then you have to trust that your hardware is identical to whatever hardware was torn-down and tested. I suppose this is good enough unless your threat model includes someone swapping your computer enroute to you with a modified one.
But even then, are you sure the computer whose PCB you tested hasn't been swapped or modified since then? That Chinese operatives didn't splinter cell it while you were out grocery shopping?
Just so you know, switches in something as complicated as a laptop have a good chance at being connected to a processor , with firmware being the thing that determines what the switch does. So you still need trust, even with a physical switch.
Source: write firmware for a living, and write drivers for physical switches.
It should be implemented with the same robustness as if the user's life depended on it.
As an analogy, you wouldn't implement a car brake by running it through some firmware. Instead, you'd preferably make a direct physical connection between the pedal and the actual brake.
There's another angle, which is that even if the wiring works and forms an iron clad promise the camera is not working, not having camera covers trains the population to be okay with having cameras pointed at them all the time, even in their most personal and private spaces.
