I'm not an EE by trade, but I personally wouldn't want to put a CCD in series with an LED with god-knows-what Vf tolerances. Then again, I'd bet that nearly all laptop webcams come as off-the-shelf modules with their own internal regulators for the CCD anyway. So maybe it wouldn't matter.

I'll bet it went something like this: As originally specified, the user need was "LED privacy indicator for the webcam." Product management turns that into two requirements:

1) LED next to webcam.

2) LED turns on and off when webcam turns on and off.

Requirement 1 gets handed to the EEs, and requirement 2 gets handed to the firmware engineers. By the time a firmware engineer gets assigned the job of making the LED turn on and off, the hardware designers are already 1 or 2 board spins in. If the firmware engineer suggested that we revise the board to better fit the intention of the user needs, one of two things will happen:

1) They'll get laughed out of the room for suggesting the EEs and manufacturing teams go through another cycle to change something so trivial.

2) They'll get berated by management because it's "not the engineers' place to make decisions about product requirements."

Of course this is all spitballing. I've definitely never been given a requirement that obviously should have been a hardware requirement. I've definitely never brought up concerns about the need to implement certain privacy and security-critical features in hardware, then been criticized for that suggestion. And I've definitely never, ever written code that existed for the sole purpose of papering over bad product-level decision making.

Nope, never. Couldn't be me.