Fantastic, another nothingburger proof of concept for people to point to when arguing in favor of more manufacturer-lockdown-based "security". It's not a coincidence that this demonstration is on one of the last generations of laptops that can actually be secured against Intel themselves.
In reality, remote code execution should be considered game over, end of story. Trying to obfuscate to hide that fact just ends up creating more unknown places for malware to persistently hide. The same knowledge that allows one to write new camera firmware also allows one to verify it on every boot. Meanwhile the camera model that hasn't been publicly documented is an ever-present black box.
> for people to point to when arguing in favor of more manufacturer-lockdown-based "security"
I don't see why this is the first thing you think of, when the infinitely more obvious thing to point out is that the indicator LED should be impossible to address and be connected in series with the power pin of the camera instead. Case in point, most other comments in this very discussion thread.
Conversely, your comment (to me) reads like you're trying to derail conversation and argue in favor of weakening device security in whatever flavor you find compelling. Very intellectually honest of you to present those ideas this way.
Sure, you can solve this one particular thing with fixed hardware [0]. The problem is that just slightly more complex, any designer isn't going to opt for hardcoded logic but rather going to go "we have a microcontroller sitting right here, of course we're going to use it". This path ends with firmware "security" that prevents straightforwardly reading/writing these devices, which is exactly what my comment is about.
> you're trying to derail conversation and argue in favor of weakening device security
No, I'm arguing in favor of analyzing security in terms of device owners rather than manufacturers. "Security" isn't simply some singular property, but is rather in the context of a specific party [1]. It's certainly possible to build hardware that verifies running software and also doesn't privilege the manufacturer with an all-access pass. Just no manufacturers have done it, because centralizing control in their favor is easier.
[0] even this case is borderline. Your series LED suggestion isn't likely to be work because it will drop at least 1.6v, and constrain the current draw of the camera. Also if the firmware can be reprogrammed such that it can take pictures using very low average current draw, you haven't actually solved the problem. Alternatively, an LED in parallel with the power supply will require at least an additional resistor (if not a diode and a capacitor), which costs real money in the eyes of a design engineer working at consumer volumes.
[1] eg how the TSA that drones on about "security", while they're actually making individual travelers less secure from having to unpack and splay their belongings out, making them easy targets for immediate or later theft. They're not talking about your security, they're talking about their operation's security.
In reality, remote code execution should be considered game over, end of story. Trying to obfuscate to hide that fact just ends up creating more unknown places for malware to persistently hide. The same knowledge that allows one to write new camera firmware also allows one to verify it on every boot. Meanwhile the camera model that hasn't been publicly documented is an ever-present black box.