I thought the whole point of these camera LEDs was to have them wired to/through the power to the camera, so they are always on when the camera is getting power, no matter what.
Having the LED control exposed through the firmware completely defeats this.
They are hardwired on Macbooks. From Daring Fireball, quoting an email from an Apple engineer.
> All cameras after [2008] were different: The hardware team tied the LED to a hardware signal from the sensor: If the (I believe) vertical sync was active, the LED would light up. There is NO firmware control to disable/enable the LED. The actual firmware is indeed flashable, but the part is not a generic part and there are mechanisms in place to verify the image being flashed. […]
> So, no, I don’t believe that malware could be installed to enable the camera without lighting the LED. My concern would be a situation where a frame is captured so the LED is lit only for a very brief period of time.
That's backwards.
The LED should be connected to camera's power, or maybe camera's "enable" signal. It should not be operable via any firmware in any way.
The led also has to be connected through a one-shot trigger (a transistor + a capacitor) so that it would light up, say, for at least 500 ms no matter how short the input pulse is. This would prevent making single shots hard to notice.
Doing that, of course, would incur a few cents more in BOM, and quite a bit more in being paranoid, well, I mean, customer-centric.
> The LED should be connected to camera's power, or maybe camera's "enable" signal.
Wiring it in like this is suboptimal because this way you might never see the LED light up if a still photo is surreptitiously captured. This has been a problem before: illicit captures that happen so quickly the LED never has time to warm up.
Controlling the LED programmatically from isolated hardware like this is better, because then you can light up the LED for long enough to make it clear to the user something actually happened. Which is what Apple does -- three seconds.
You can design a simple circuit such that both long and short pulses light up the led for 500ms. There is no tradeoff needed to be made at all.
Pray read the third paragraph of my reply :) It specifically mentions a way to make the LED be lit for long enough.
I mean can't you just have the input signal to the light be a disjunction of signals? So it's on if the camera is on OR if some programmatic signal says turn it on?
I don't see why they should be mutually exclusive
or, you can have a physical switch, like the Framework. that also hits your BOM but its not complex!
You can buy/print and stick a physical «webcam cover»[1] manually on your notebook or phone.
My current notebook, manufactured in 2023, has very thin bar on top of screen with camera, so I need a thin, U-like attachment for the switch, which is hard to find.
[1]: https://www.printables.com/model/2479-webcam-cover-slider
Am I the only one that is not worried at all about the camera and super concerned about microphones ? The camera may see me staring into the screen, woo hoo. The microphones will hear everything I discuss, incl. confidential information.
There is no physical microphone cover there, is it ?
Would a bit of Post-It Note (for minimal adhesion) damage the screen coating if left on most of the time? Would even that much thickness stress the screen when opened and closed thousands of times? Is there a better (self-service) material?
replying to the sibling: this is a very common solution; I used to use a piece of masking tape (aka, painter's tape) on my macbook.
>The actual firmware is indeed flashable, but the part is not a generic part and there are mechanisms in place to verify the image being flashed.
That might make it harder to develop a hack, but one would hope that if the hardware team tied the LED to a hardware signal, it would not matter if the firmware were reflashed.
I believe that it’s not literally hardwired in the sense that powering up the camera also powers up the camera LED, and instead this relies on logic in the hopefully un-flashable camera+LED firmware. Someone correct me if I’m wrong.
You need some logic to enforce things like a minimum LED duration that keeps the LED on for a couple seconds even if the camera is only used to capture one brief frame.
I have a script that takes periodic screenshots of my face for fun and I can confirm the LED stays on even if the camera only captures one quick frame.
A capacitor can hold enough charge to power led for noticable amount of time even if powered for a brief moment, no logic needed
I don't think they would waste a high value capacitor just to keep a led lit for longer, also a led directly lit by a capacitor would be noticeable by slowly dimming when the capacitor discharges. It's more likely that the signal driving the led comes out of a monostable implemented in code: pin_on() drives the led on; pin_off() waits n secs then drives the led off.
This is Apple, so that assertion isn’t guaranteed valid like it would be for non-enterprise HP or Lenovo. They absolutely would invest in a capacitor if that’s what it takes, as they are maximally focused on camera privacy concerns and have made a point of that in their security marketing over time; or else they wouldn’t be allowing hardware security engineers to brag about it, much less talk publicly about it, at all.
EDIT: It’s not just a capacitor, it’s a full custom chip, that can’t be software-modified, that keeps the light on for 3 seconds. https://news.ycombinator.com/item?id=42260379
Logic on an already existing ASIC is going to be cheaper than a capacitor.
The trick is to keep using the camera until that capacitor is discharged. I'm pretty sure most cameras can run at voltages below a LED's forward voltage nowadays.
I happen to have some first-hand knowledge around the subject! In 2014 someone did a talk[0] on disabling the camera on some older Macbooks. It was fairly trivial, basically just reflashing the firmware that controlled the LED. I worked on the security team at Apple at the time and in response to this I attempted to do the same for more modern Macbooks. I won't go into the results but the decision was made to re-architect how the LED is turned on. I was the security architect for the feature.
A custom PMIC for what's known as the forehead board was designed that has a voltage source that is ALWAYS on as long as the camera sensor has power at all. It also incorporates a hard (as in, tie-cells) lower limit for PWM duty cycle for the camera LED so you can't PWM an LED down to make it hard to see. (PWM is required because LED brightness is somewhat variable between runs, so they're calibrated to always have uniform brightness.)
On top of this the PMIC has a counter that enforces a minimum on-time for the LED voltage regulator. I believe it was configured to force the LED to stay on for 3 seconds.
This PMIC is powered from the system rail, and no system rail means no power to the main SoC/processor so it's impossible to cut the 3 seconds short by yoinking the power to the entire forehead board.
tl;dr On Macbooks made after 2014, no firmware is involved whatsoever to enforce that the LED comes on when frames could be captured, and no firmware is involved in enforcing the LED stay on for 3 seconds after a single frame is captured.
0: https://www.usenix.org/system/files/conference/usenixsecurit...
There seems to be widespread anxiety regarding cameras, but hardly anyone ever talks about microphones. Are conversations not much more privileged information than potentially seeing someone in their underwear?
"All Apple silicon-based Mac notebooks and Intel-based Mac notebooks with the Apple T2 Security Chip feature a hardware disconnect that disables the microphone whenever the lid is closed. On all 13-inch MacBook Pro and MacBook Air notebooks with the T2 chip, all MacBook notebooks with a T2 chip from 2019 or later, and Mac notebooks with Apple silicon, this disconnect is implemented in hardware alone." [1]
[1] https://support.apple.com/guide/security/hardware-microphone...
That's what they said about the first gen Facetime cameras. "oooh don't worry, it's controlled in hardware!"
We have no way of verifying that anything they said in that document is true.
It's clear Apple define "Hardware" as "Not using the main CPU". They've pretty much admitted it's firmware based, otherwise the T2 chip simply wouldn't be involved to be mentioned.
The T2 chip is mentioned in the quoted passage as an indicator of the architecture version, not necessarily an indicator that the T2 chip is directly involved
Obviously the camera is also 'disabled' when the lid is closed regardless of the controlling circuitry. So while that's a good feature, it's not relevant.
They are, but people aren’t scared of those because they can’t see them staring at them.
Yes, photos of naked people are used to extort them (usually into just paying the holder to delete them).
This raises a different but related question. In what world should a victim of a crime be extorted for doing innocent things in their home. If a peeping tom took a photo though a window, could that be used to extort someone?
When people are extorted for these kinds of things it's usually catfishing that leads to sexual acts being recorded. That's not related to cybersecurity.
Fear of harrasment. You don't want your coworkers see you naked, do you?
edit: s/baked/naked/ :D
Depends what your threat model is?
Nobody but Abby and Ben care if Ben is caught admitting he cheated on Abby. But naked images of Abby can head off into the ether and be propagated more or less forever, turn up on hate sites, be detrimental to careers etc.
If your threat model is leaking company secrets then sure, microphone bad, as is anything having access to any hardware on your machine.
So sure, maybe people ought to be more concerned about microphones as well, rather than instead.
My point is that the threat model is backwards. The threat associated with a camera is the least severe compared to anything else a malicious person could do with access to your computer. Recored conversations, chats and email, browsing history, etc are all much more likely to result in harm if leaked than a recording of you innocently in your home.
> Nobody but Abby and Ben care if Ben is caught admitting he cheated on Abby.
That destroys families, standing within a community, and very often careers.
I don't think it is backwards, personally. The threat of public humiliation, and the capability for someone to spy on what you do in your own home, is worse with the camera.
> chats and email, browsing history, etc are all much more likely to result in harm if leaked than a recording of you innocently in your home.
This is far less of an intrusion for most people than recording what they are actually doing in their own home IRL. People know that information can be hacked, they don't expect and react quite differently to someone actually watching them.
> That destroys families, standing within a community, and very often careers.
Yes, but it doesn't stay on the internet forever in quite the same way.
Now I get to some extent what you're saying - aren't the consequences potentially worse from other forms of information leak?
Maybe. It depends on how you weight those consequences. I'd put (for example) financial loss due to fraud enabled by hacking my accounts as far less important than someone spying on me in my own home. Even if they didn't use that to then extort me, and were using the footage for ... uh ... personal enjoyment. I think a lot of people will feel the same way. The material consequences might be lesser, but the psychological ones not so much. Not everything is valued in dollars.
I think we may just be bumping into cultural differences here. I grew up in a household were being naked around family members was common. I spend time in clothing-optional spaces. I rarely draw the blinds on my windows, etc. I'm not concerned with what other people think in this way and such images could never be used to extort me. Consider the case of Germany - people there are extremely concerned about their privacy and data protection. At the same time public nudity is an entrenched cultural norm.
It's also known that people are not very good at assessing risk. People are more word about dying at the hands of a serial killer than they are of dying in a car crash or slipping in the shower. I feel you're underplaying the psychological harm of having all of your data crawled through by a creep (that would include all of your photos, sites visited, messages sent, everything).
All I can really say is that if someone gained access to my machine, the camera would be the least of my concerns. That's true in nearly every context (psychological, financial, physical, etc).
Empirically, most low level extortion does seem to be about leaking video. I would see a threat model based on 'criminal wants to extort me for money'. As more reasonable than 'creep wants to look through my computer for creeping'. And it seems like extortion focusses on video, so that is the bigger threat. Even if it is less invasive.
I presume the reason behind this is that video is much more likely to be re-shared. Sending bob a zip of someone's inbox is unlikely to be opened, and even less likely to be shared with strangers. But send bob a video of Alice, and he might open it. Heck, he might not know what the video is until he opens it. So even if he is decent, he might still see it. And if he is less decent and shares it, strangers are much more likely to actually view it.
I think, though am prepared to be wrong, that you'll probably find yourself in the minority there.
It's not just about nudity and extortion, but someone having access to watch you, whenever they feel like, in your safe space. That sense of violation that people also feel when (for instance) they have been the victim of burglary - the missing stuff is often secondary to the ruined sense of security. There's a vast difference between leaving your curtains open and having someone spying on you from inside your own home.
Is it rational to put this above other concerns? That's a whole different debate and not one I'm particularly interested in. But it explains why people are concerned about cameras over 'mere' data intrusion.
I'm not arguing a point here, but I'm curious what the actual number of instances exist where someone is naked or in some other extortionate way (accidently of course) potentially exposed from the position of their webcam. I too would be much more concerned about my microphone, where I know one had conversations that in front of or next to my machine that I wouldn't want "out there". In terms of where my camera is, I woukd imagine they would catch me picking my nose every so often but that's about it.
People watch porn on their laptops. Even just your orgasm face would be embarrassing for most people.
> Nobody but Abby and Ben care if Ben is caught admitting he cheated on Abby.
This isn't true at all, even for private citizens. Your friends, parents, children, and colleagues are all likely to care.
It's very limited, it's certainly not going to be passed around like naked pictures could be.
> and no firmware is involved in enforcing the LED stay on for 3 seconds after a single frame is captured.
I may be the oddball here, but that 3 second duration does not comfort me. The only time I would notice it is if I am sitting in front of the computer. While someone snapping a photo of me while working is disconcerting, it is not the end of the world. Someone snapping photos while I am away from the screen is more troublesome. (Or it would be if my computer was facing an open space, which it doesn't.)
Right, so this is all defense in depth. That LED is sort of the last line of defense if all others have failed, like:
The exploit mitigations to prevent you from getting an initial foothold.
The sandboxing preventing you from going from a low-privileged to a privileged process.
The permissions model preventing unauthorized camera access in the first place.
The kernel hardening to stop you from poking at the co-processor registers.
etc. etc.
If all those things have failed, the last thing to at least give you a chance of noticing the compromise, that's that LED. And that's why it stays on for 3 seconds, all to increase the chances of you noticing something is off. But things had to have gone pretty sideways before that particular hail-mary kicks in.
OK, but then what? Leave the LED on for 24 hours after you've captured a single frame? At that point the LED isn't really indicating camera usage because you'll just get used to seeing it on all the time whether the camera is in use or not.
It's strange that none of these companies will include a closable cover for the camera. I got one aftermarket. It is very reassuring since no hacking or accidental misclicks on my part can move the cover.
I've seen HP desktops that have a closeable camera cover, and Lenovo does on some ThinkPads [1], so probably others do too. Laptops usually have very little depth available in the screen part though, which is why most laptop cameras are crappy (exceptions include Surface Pro and Surface Book, which have more depth available and so much better cameras than most, but no cover - at least their camera light is not software controlled).
[1] https://www.businessinsider.com/lenovo-thinkshutter-laptops-...
I also purchased a cover for mine, although in a pinch, the removable stickers on fruit work well.
I had a closable cover and someone shut my laptop with enough force that the cover caused the screen to break. Be careful when closing.
I have a sticky piece of post it note more or less permanently affixed over my camera.
I can remember when someone spotted tape over Zuckerberg's laptop camera. Ref: https://www.theverge.com/2016/6/21/11995032/mark-zuckerberg-...
Thanks for posting this interesting tidbit! I find this kind of knowledge absolutely fascinating!
Thank you for your work on this! I wish some other large companies took privacy that seriously.
I've seen a million people parroting "oh now apple fixed it!" and not a single person who has actually verified/proved it. Go on, show my any third party security researcher who has verified this claim via examining the actual hardware.
You'll pardon us all if we don't really believe you, because a)there's no way for any of us to verify this and b)Apple lied about it before, claiming the LED was hard-wired in blah blah same thing, except it turned out it was software controlled by the camera module's firmware.
I'd love for a third party to verify the claim! I'm just giving you an overview of the work that went into making this a thing, knowing full well you have absolutely no reason to trust me.
The LED being "hard-wired" is a tricky statement to make, and I actually wasn't aware Apple has publicly ever made a statement to that effect. What I can say is that relying on the dedicated LED or "sensor array active" signal some camera sensors provide, while technically hard-wired in the sense there is no firmware driving it, is not foolproof.
> Apple lied about it before, claiming the LED was hard-wired in blah blah same thing, except it turned out it was software controlled by the camera module's firmware.
Source?
I assume you're not longer working on it, but why not just wire it so that:
- The LED is in parallel, but with the sensor voltage supply, not the chip
- Camera sensor idle voltage = low voltage for the LED (be it with stepping if needed)
- Camera sensor active voltage = high voltage for the LED (again, stepping if needed)
- little capacitor that holds enough charge to run the LED for ~3 seconds after camera goes back to idle voltage.
Good luck hacking that :)
That's basically how this works, but manufacturing electronics at a massive scale requires some more flexibility. For example, capacitors have a pretty large tolerance (sometimes +/- 20%) and LEDs have quite a bit of variety in what voltages they'll work at. So for some people the LEDs might last 3 seconds, for some they might last 5s. Using a capacitor also means the LEDs will fade slowly instead of just turning off sharply.
If the LEDs come from a different supplier one day, who is going to make sure they're still within the spec for staying on for 3 seconds?
(And yes, I have long since parted ways with Apple)
Edit:
And to add on: That capacitor needs time to charge so now the LED doesn't actually come on when the sensor comes on, it's slightly delayed!
You can't drive an LED that way in production electronics: you need to use an LED driver circuit of some kind to ensure the LED has constant current, and also to protect against failure modes. Also, a capacitor large enough to power a daylight-visible LED for 3 seconds is not as "little" as you're thinking; there's likely not enough space in a laptop lid for one of those. A driver circuit would be smaller and thinner.
Agreed, however, that the LED should be controlled by the camera sensor idle vs. active voltage.
See then it's not hardwired at all. It is equally vulnerable to a reflash. Apple just did hardware security (i.e. signed firmware) better and also are relying on security through obscurity (its not a publicly available part).
The context from the article the parent comment linked is that Mac webcams made prior to 2008 both had the camera LED controlled in firmware and didn't verify the camera firmware blob when it was downloaded into the camera's RAM. The quote you're replying to simply says that Apple solved these security issues by tying the LED to a hardware signal AND verifying the camera firmware blob. The result is still that there's no way to turn on the webcam without making the LED light up.
AFAIK iOS devices use a tiny firmware on the camera and a larger one on the secure enclave chip.
If you successfully compromise the host OS and also the secure enclave firmware, that might be enough to let you turn on the camera (without vsync) and reconstruct the correct image via later analysis... but at that point you have committed tens of millions to the hack (so you'd better not overuse it or it'll get noticed & patched).
Many complex chips have GPIO signals rather than hardwired outputs. That way you can select any [5-10] of [20-100] functions for each pin. As a result, things that you think should be hardwired are controlled by firmware.
I wonder how quickly it turns on/off as per Gruber’s worry - if you just record a single frame would it even be visible if looking right at it?
Below, axoltl writes:
> no firmware is involved in enforcing the LED stay on for 3 seconds after a single frame is captured.
While Apple made a laudable effort in this design, sadly it requires thoughtful care and design at every iteration. Typically the iPhone team couldn't pull it off and the only official claim is for macbooks.
I think it's simpler to assume that most devices can be hacked and the LED indicator isn't infailable than to always keep in mind which device lines are supposed to be safe and which ones aren't.
Apparently it was purely in software on iPhone/iPad. However, starting with the iPhone 16 and M4 iPad Pro, the LED indicator is rendered by a separate secure exclave:
https://www.tomsguide.com/phones/iphones/iphone-16s-a18-chip...
Do you know if the same occurs in iPhones? That was always my assumption, but seeing a Mac-only response makes me wonder if it is addressing a Mac/only question or if it’s applicable only to Macs.
> My concern would be a situation where a frame is captured so the LED is lit only for a very brief period of time.
Maybe enable a pre-charged capacitor to the LED whenever the circuit is activated? A "minimum duty cycle" for the LED might help solve this.
An indicator light hardwired is nice but I apparently can't trust hardware manufacturers to design it properly. My work laptop (HP Dragonfly) has a physical blocker that closes over the camera when I haven't explicitly pressed the button that enables the camera. The blocker is black and white stripes so it's very obvious when it's covering the sensor. This should absolutely be the security standard we all strive for with camera privacy.
> The blocker is black and white stripes
On my ThinkPad it’s instead painted with a red dot. Because, obviously, the conventional meaning of a red dot appearing on a camera is “not recording”.
Not just the weird meaning, but on my last Thinkpad the red dot and the slightly red glean of the camera lens look surprisingly like each other. Even worse I managed to get the cover in a position where it looked like it was closed, but the camera could still see.
The Dell Latitude business laptops now have a wired led and wired switch. Besides the white led, there’s no indication which is on or off, and I don’t trust any of the software or firmware chain to be reliable. (score one for macs being transparent and prescient)
Dell should go back to the basic design of the Latitude E6400, but with modern electronics and screen of course, and drop the optical drive. The keyboard on that laptop was fantastic, and the single captive screw on the back panel was great for serviceability.
For some inexplicable reason Dell has chosen to mark the button as "mute mic" (mic icon + X). So if the LED on the keyboard is lit up, the microphone is off, or rather, the microphone muting is on on. Brilliant design.
Probably the camera “power” is always on as any other microcontroller on the same board, but is only active when called through the control bus or an interrupt, having an LED tied to the power rail would keep it on all the time whenever the lapop is on.
Then tie it to some signal or power rail that only gets enabled when the camera is in use, and that must be enabled for the camera to work, e.g. when there's power to the sensor itself.
Interesting, my work HP Probook does not have that functionality. I wonder why HP chooses to do this only for some laptop lines.
I suspect most people don't want it. I can imagine lots of people calling customer service "Q: why doesn't my camera work?", "A: Did you open the cover?"
There's just a valid an argument to do the same for phones. How many phones ship with camera covers and how many users want them?
You can get a stick on camera cover for $5 or less if you want one. I have them on my laptops but not on my phone. They came in packs of 6 so I have several left.
> I can imagine lots of people calling customer service "Q: why doesn't my camera work?", "A: Did you open the cover?"
In some over-engineered world, when the camera cover is engaged the webcam video feed would be replaced by an image of the text "Slide camera cover open" (in the user's language) and an animation showing the user how to do so.
We have that on the most recent generation of Framework Laptop. When the hardware privacy switch is engaged, the image sensor is electrically powered off and the camera controller feeds a dummy frame with an illustration of the switch.
Is there a video or some images of this somewhere? I would love to see a demonstration.
This doesn’t seem that wild to me. Zoom already prompts me to unmute my microphone when I cough.
It's also a moving part. Worse, a part the customer moves. Which means more opportunity for crap getting crammed in or breaking.
The cover on my laptop's camera is behind the glass. I suppose there is a chance that the slider itself could get damaged, but at least they minimized the exposed surface that could be damaged.
That said, I really can't comment on how durable it is. I only remove the cover about a half dozen times a year.
I had that exact discussion with somebody recently, and it took me a few minutes to realize that their laptop had a physical camera cover that somehow disables camera permissions in windows too. So yeah, happens a ton I would imagine.
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 suddenly 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.
I might be out of the loop, but I thought that was only for some machines - I remember the LED being wired that way being a selling point for MacBooks at some point, as a privacy feature. It definitely should be the standard, though!
I can't find it now, but recently I read how one company's design team added this feature to their laptops. A subsequent review by the team responsible for manufacturing found that they could change the circuit to cut down on the part count to save money. The light was still there, but it was no longer hardwired. The company continued to advertise the camera light as being hardwired even though it wasn't.
There was a school district that took pictures of the kids at home.
They briefly saw the LED flash.
But it was not on for any length of time and you could miss it.
This stuff should be completely in hardware, and sensible - stay on for a minimum time, and have a hardware cutoff switch.
Since some sort of firmware is required, this seems like a "turing tarpit" security exploit from my laymans perspective.
There's no standard that I know, that, like "Secure EFI / Boot" (or whatever exact name it is), locks the API of periphery firmware and that would be able to statically verify that said API doesn't allow for unintended exploits.
That being said: imagination vs reality: the Turing tarpit has to be higher in the chain than the webcam firmware when flashing new firmware via internal USB was the exploit method.
No firmware is required. Macbooks manufactured since 2014 turn on the LED whenever any power is supplied to the camera sensor, and force the LED to remain on for at least 3 seconds.
(Source: I architected the feature)
Thanks for your reply — yourself as the Source can only make me feel flattered then for you responding to me.
> Macbooks manufactured since 2014 turn on the LED whenever any power is supplied to the camera sensor, and force the LED to remain on for at least 3 seconds.
That convinced me originally I think, good old days! I'd almost forgotten about it. The way you phrased it, it sounded like 50% OS concern to me.
But if cam & LED rly share a power supply, and the LED is always on without any external switch, Good then!
I was not very popular with the camera firmware folks for a while. They had to re-architect a bunch of things as they used to occasionally power on the camera logic without powering the sensor array to get information out of the built-in OTP. Because the LED now came on whenever the camera was powered they had to defer all that logic.
What does OTP stand for in this case? The camera PROM??
Apologies. OTP is One-Time-Programmable. The physical implementation of this varies, in this specific case it was efuses (anti-fuse, actually). It's used for things like calibration data. For a camera it contains information about the sensor (dead pixels, color correction curves, etc.).
In the past I've used microsnitch on macos which tells you when the mic or camera are activated, but macos seems to have support for this baked into the os now. In zoom calls the menu bar shows what is active. If this can be sidestepped and avoided in software, and the camera can be activated without any indicator, I do not know. If direct access can be done, and you don't need to go through some apple api to hit the camera, maybe.
edit: looks easily bypassed https://github.com/cormiertyshawn895/RecordingIndicatorUtili...
Using this tool requires disabling SIP, so not "easily bypassed" at least from a malware perspective.
Did it ever snitch on anything interesting?
idk, but maybe you know! it was probably easily bypassed anyway. hardware disconnects are the only thing that can ever be trusted imo
I'd like a law to this effect.
We may already have this law. If the manufactures makes claims about this LED, then that this attack is possible mean a lawyer can force them to recall and fix everything.
We have to be realistic though. We can't even get a law requiring right to replace a battery on our own iPhones...
Go to https://www.ifixit.com/Device/iPhone, then search for your iPhone's battery replacement guide.
I stumbled on a forum once where it was just filled with people trying to modify the software for various laptops to disable the "tally lamp" (as it is called). There were people selling the mods and one guy claiming he was selling his cracks to three-letter agencies. The people on there seemed to be using this to extort people (mostly women) by being able to record videos without the owner knowing. Some really dark shit.
Yeah the first day I read about RATers... jesus. The camera LED seemed to be a major thing for them, because if they could bypass it then the chance their RAT would be discovered was much lower.
Really nasty world they've made for themselves, blackmailing, extorting and generally controlling other people (mostly women and girls, but some men too) with threats of releasing compromising material.
The idea has been around for quite some time. But it is always dropped.
My guess is that, assuming the most basic and absolute physicial design, the light would flash for silly things like booting, upgrading firmware, checking health or stuff like that.
Flashing is easily fixed with a capacitor and also not a bad thing if it turns off when it loses power immediately. The only explanation that makes sense to me is it being separately controlled is a feature not a bug.
I agree on the capacitor fix for flashing, I pointed it out in another post.
In this case I was referring to false positives to the user.
This would mean we can't update the firmware without causing the user some paranoia.
Also. Would an app requesting permission to use camera itself send some power to the camera to verify it is available? In a similar vein, what about checking if the camera is available before even showing the user the button to use the camera?
Maybe there's solutions to this, I'm just pointing out some reasons they may have gone the software route instead of the hardware route.
That's why many ThinkPads have physical covers over their cameras. You don't even need to worry about whether the LEDs are hardwired - relying on any electronic indicator is already a half-baked security measure. If you want real security, just go with a physical solution.
…until it isn’t: my ThinkPad P1 Gen 6 has the camera cover, yes - but it doesn’t have a cover for the depth-sensing camera, only the RGB cam, even though userland applications can get imaging data from that camera just as easily - which is potentially a bigger security issue: I imagine you could reconstruct my facial shape from the data and build a dummy head to get into my iPhone/iPad via FaceID.
(No, I’m not actually worried about this, I’m far too unimportant for anyone to make a targeted attack against)
same... i'm also surprised that having a software controlled led would be cheaper ..
It could be something very simple, such as requiring less USB hub complexity for a camera that can be woken up via a command on the USB bus instead of needing to connect/disconnect the USB power rails (wired in parallel with the LED) to it.
Somebody here has also mentioned Apple using the camera for brightness and maybe color temperature measurement, for which they wouldn't want to enable the LED (or it would effectively always be on).
That doesn't automatically make that a good tradeoff, of course; I'd appreciate such a construction.
> Somebody here has also mentioned Apple using the camera for brightness and maybe color temperature measurement, for which they wouldn't want to enable the LED (or it would effectively always be on).
That is not true. MacBooks have separate light sensors. And the camera physically cannot activate without the LED lighting up and a notification from the OS. People say a lot of stupid things in the comments…
It's probably done to keep it in a low powered state and reduce the initialization delay. Maybe also to prevent the Windows USB plugging sound from playing upon turning the camera on, as it would seem weird to the user ("I don't have any USB devices plugged in...")
Likely UX over security and privacy.
Sure, for a brand headquartered in Cupertino they might design it that way. But this one is a Beijing brand.
Most business class thinkpads have a physical cover in the screen that covers the camera with a piece of plastic.
Led, no led, who cares, plastic is blocking the lens. Move the cover away, say hi on zoom, wave, turn the camera back off, cover on, and stay with audio only, as with most meetings :)
Yeah, on Chromebooks and MacBooks the LED is hardwired to ensure it's always on when the camera is enabled.
Yeah, my understanding is that is how the light on MacBooks works, but I'm not sure about any other makes/models. Obviously, if this is possible that Thinkpad model doesn't do that.
It isn't clear to me that webcam firmware ever powers down a typical camera module. See below for data about how the Sony IMX708 sensor is an I2C device with start and stop streaming commands.
https://github.com/Hermann-SW/imx708_regs_annotated?tab=read...
"Add an LED next to the camera, our customers demand it!"
"Job done boss!"
That's it. That's what happens. Nobody ever reviews anything in the general industry. It's extremely rare for anyone to raise a stink internally about anything like this, and if they do, they get shouted down as "That's more expensive" even if it is in every way cheaper, or "We'll have to repeat this work! Are you saying Bob's work was a waste of time and money!?" [1]
[1] Verbatim, shouted responses I've received for making similar comments about fundamentally Wrong things being done with a capital W.
Lawyers after the fact review this. I expect one to start a class action - they will make millions, and everyone else who has this laptop will get $1. The real point is the millions means every other company is on notice that these mistakes hurt the bottom line and so the industry starts to review these things. So long as it doesn't hurt they won't review.
I feel really dirty calling lawyers the good guy here, but ...
> I thought the whole point of these camera LEDs was to have them wired to/through the power to the camera, so they are always on when the camera is getting power, no matter what.
This definitely happened too on Mac in the past, then they went in damage control mode. Not only had Apple access to turn off the LED while the camera was filming, but there was also a "tiny" company no-one had ever heard off that happened to have the keys allowing to trigger the LED off too. Well "tiny company" / NSA cough cough maybe.
After that they started saying, as someone commented, that it requires a firmware update to turn the LED off.
My laptop has a sticker on its camera since forever and if I'm not mistaken there's a famous picture of the Zuck where he does the same.
I've got bridges to sell to those who believe that the LED has to be on for the camera to be recording.
I believe every paragraph of this besides the personal anecdote is completely made up. Care to change my mind?