Meta's capture LED is now enforced in software

Meta is closing the loophole where you start a recording on its smart glasses and then put tape over the little white light. Alex Himel, Meta's VP of wearables, posted the fix on Threads: the capture LED is now enforced in software, and the camera stops if the light gets covered mid-recording. Useful. Also a reminder that the privacy indicator on any device you buy is a firmware behaviour, and firmware behaviours change in both directions.

What actually happened

Before this update, the glasses refused to start a capture if the LED was blocked, but nothing stopped a wearer from starting the recording and then covering the light. Per 9to5Google, Himel's announcement says the camera will now stop working if the light is covered during a recording. Android Authority reports the glasses will disable the camera if they detect the capture LED has been covered, physically tampered with, or destroyed. The rollout is described as starting, without a firm completion date, and Meta says more updates of this kind are coming.

Read the mechanism, not the headline. The LED is not wired to the camera's power. The camera and the LED are both downstream of software that decides, on each capture, whether the indicator is visible enough to proceed. That is a much better design than the previous one. It is still a decision made in code that ships over the air.

Why it matters for your business

If you run a shop, a clinic, a gym, a restaurant — anywhere the public and your staff share a room — this is a recording-policy question you now have to answer, and "the light will be on" is not the answer.

Two practical consequences. First, your signage and your staff handbook should describe conduct, not hardware: no recording in treatment rooms, back office, or at the POS, regardless of device. A rule that depends on spotting an indicator light is unenforceable the moment the device changes, and it puts your front-line staff in the position of adjudicating someone else's firmware version. Second, if you're in a regulated space — health, childcare, financial advice — your consent and confidentiality controls should not have a dependency on a third-party OTA update you don't control and can't audit.

This generalises past glasses. We tell clients the same thing about any device where a vendor's software mediates a safety promise: write the requirement down in your own terms, then check whether the device satisfies it today. The vendor is doing the right thing here, quickly and publicly. You still don't own the update channel.

Sources: 9to5Google, Android Authority.