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.
>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.
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).
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.
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.
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.
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).
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.
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.
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.
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).
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.
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!
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.
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.
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.
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.
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 to play upon turning the camera on, as it would seem weird to the user ("I don't have any USB devices plugged in...")
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.
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.
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 :)
"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 ...
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.
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.
I can see why some people might be concerned about the camera, but I'm far more concerned by the microphone. There's far more sensitive and actionable information that can be gathered from me that way! I'm glad that macOS started putting a light in the menubar when the microphone is in use, but I'd prefer to have unhackable hardware for that instead.
I believe it is possible to turn a speaker into a microphone. Found a paper which claims to do just that[0]. So, there is no safety anywhere?
SPEAKE(a)R: Turn Speakers to Microphones for Fun and Profit
It is possible to manipulate the headphones (or earphones) connected to a computer, silently turning them into a pair of eavesdropping microphones - with software alone. The same is also true for some types of loudspeakers. This paper focuses on this threat in a cyber-security context. We present SPEAKE(a)R, a software that can covertly turn the headphones connected to a PC into a microphone. We present technical background and explain why most of PCs and laptops are susceptible to this type of attack. We examine an attack scenario in which malware can use a computer as an eavesdropping device, even when a microphone is not present, muted, taped, or turned off. We measure the signal quality and the effective distance, and survey the defensive countermeasures.
I recall in the early or mid 2000s using some cheap earbuds plugged into the microphone port of my family computer as a pair of microphones in lieu of having a real microphone nor the money for one. Then I used Audacity to turn the terrible recording into a passable sound effect for the video games I was making.
Not knowing much about how soundcards work, I imagine it would be feasible to flash some soundcards with custom firmware to use the speaker port for input without the user knowing.
Even where it works, speakers are much worse microphones that dedicated microphones, and so the amount of data that can be gathered is low. Why bother when you probably have a microphone on the same PC that can capture far more sound?
Plus one-ing this - I think the external monitor may be the kicker to keeping the mic active. This drives me up the wall when Google Meet decides to just default to the closed Macbook next to me instead of my already connected Air Pods when joining work meetings.
The microphone also can't be covered with a $1 plastic camera cover off Amazon. It's so easy to solve the camera issue if you care about it, but there's really nothing you can do about the mic.
If you're half-serious about this sort of opsec, you already have bluetooth disabled. Ideally your hardware wouldn't have support for it at all. Same for wifi.
M2 and newer MacBooks have an IMU on-board, which is just a funny way of spelling microphone. Admittedly a very low quality one; I'm not sure if you could pick up understandable speech at the 1.6kHz sample rate Bosch's IMUs seem to support.
Going into full paranoid mode, I wonder if some other sensors / components can be used as a makeshift microphone. For instance, a sufficiently accurate accelerometer can pick up vibrations, right? Maybe even the laser in a CD drive? Anything else?
A condenser microphone is just a capacitor. Your computer is full of them.
They are very low level input and generally need a pre-amp just to get the signal outside the microphone. However conceptually at least they are there and so maybe someone can get it to work.
Well it doesn’t need to be visible to work in contrast to camera. Seriously though, no technological and almost no economic barrier preventing embedding a mic into every wireless communication chip.
macOS is a proprietary binary blob, remotely controlled by Apple. So, the light in the menu bar is not a reliable indicator of anything. There is no privacy on macOS, nor any other proprietary system. You can never be 100% sure what the system is doing right now, as can be anything it is capable of. Apple is putting a lot of money to "teach people" otherwise, but that is marketing, not truth.
The root of all trust is eventually some human, or group of humans. See "Reflections on Trusting Trust." At least so far, Apple has convinced me that they are both willing and competent enough to maintain that trust.
Myself, I stopped trusting Apple. There are now too many dark patterns in their software, especially once one stops using their services. And, DRM was re-instantiated, when iTunes started streaming as Apple Music. On top of that, their lies, such as those about the Butterfly keyboards being fixed, cost me a fortune. They fuck up the keyboard design, and then they buy the computer back for 40% of its original price, due to a microscopic scratch nobody else could see. And that happened twice to me. They put a lot of money into advertising themselves as being ethical, but that is only marketing. These, of course, are my personal opinions.
> There is no privacy on macOS, nor any other proprietary system.
Nor is there on any free system for which you didn't make every hardware component yourself, as well as audit the executable of the compiler with which you compiled every executable. (You did self-compile everything, hopefully?)
> There is no privacy on macOS, nor any other proprietary system.
Which is to say, every system in actual widespread use. All such CPUs, GPUs, storage devices, displays, etc. run closed microcode and firmware. It'd be funny if it wasn't so profoundly sad.
And even if they didn't, the silicon design is again, closed. And even if it wasn't closed, it's some fab out somewhere that manufactures it into a product for you. What are you gonna do, buy an electron microscope, etch/blast it layer by layer, and inspect it all the way through? You'll have nothing by the end. The synchrotron option isn't exactly compelling either.
Yes, ultimately, I want everything to be open. This is not a bag of rice. These are devices packed with sensors, in our homes. As for inspection, I do not have a problem trusting others. I just do not trust big corporations with remotely controlled binary blobs, no matter how much money they put into the safety and security ads. This is a personal opinion, of course.
But this is a pretty extremist take. Just because a company doesn't push source code and you can't deterministically have 100% certainty, doesn't mean you can't make any assertions about the software.
To refuse to make any claims about software without source is as principled as it is lazy.
Imagine an engineer brought to a worksite, and they don't have blueprints, can he do no work at all? Ok, good for you, but there's engineers that can.
Yes, I think all devices packed with sensors that live in our homes should be transparent in what they do, that is their code should be available for everyone to see. And yes, it is extremist take, given where we ended up today.
For something as compressible as voice, I do not know how you would feel confident that data was not slipping through. Edge transcription models (eg Whisper) are continuing to get better, so it would be possible for malware to send a single bit if a user says a trigger word.
On a ThinkPad X1 Carbon Gen 8, it's easily possible record video with the webcam LED off. I did not verify newer generations of the X1 Carbon.
Lenovo put a little physical switch—they call it "ThinkShutter"—that serves to physically obstruct the webcam lens to prevent recording. It's supposed to have only two positions: lens obstructed or not. But if the user accidentally slides it halfway, you can still record video with the lens unobstructed but somehow the webcam LED turns off. It's because the ThinkShutter actually moves 2 pieces of plastic: 1 to cover the lens, 1 to cover the LED. But the piece covering the LED blocks it first, before the other piece of plastic blocks the lens. I discovered this accidentally yesterday while toying with a X1 Carbon... I am reporting it to Lenovo.
I assumed that most if not all of these webcam LEDs are wired in series with the power to the camera itself. Which then makes it impossible to disable them. Who designs this LED to be software addressable?
Assuming Hanlon's razor it's a Chesterton's fence situation you just see a LED that indicates the camera is on. Assuming they ask the question at all they think it's just to remind you your still streaming/in a meeting. Then someone asks any of the following questions:
Can we use it to indicate additional information?
Can we make it standard with the other LEDs?
Can we dim it so it's more pleasant to use at night or make it a customisable colour?
I'm sure plenty of other questions take you down the same path and you've just destroyed one of the LEDs most useful functions.
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.
Arguably a much, much bigger problem are the (many) microphones of modern devices.
These usually get neither an LED nor a switch, and unlike cameras can't easily be covered, nor pointed away from potentially sensitive topics/subjects.
Lots of ThinkPads have «Microphone is muted» LED. Not exactly what's requested (and is bound to a software mute/unmute shortcut), but it's better than nothing regarding state of machine being observable with a quick glance.
That one seems to be software controlled. I'm fairly sure I remember having the mic working with the mute LED lit, which was confusing. That was on a x1 carbon gen9.
At the same time we're at a point where synthesizing your voice is getting more trivial everyday, you need only a few seconds of it and you can be made to say whatever someone wants.
Sure, but that doesn’t mean they learn everything I said: Passwords, personal details etc.
Also, getting a voice sample in the first place gets significantly easier that way: Not everybody publishes video or audio recordings of themselves online.
Which reminds me, to strengthen your point, it doesn't have 100% keystroke recognition, but there are works[1] on keylogging via audio, and 93% via Zoom-quality audio streams is concerning enough for me.
For example, I'd not be happy having my voice auto-transcribed by some malware as I authenticate to my bank providing my SSN etc (which as an authentication method is of course horribly insecure, but that's a different discussion).
Of course, this will vary from person to person, but as mentioned above, just being able to mechanically cover a camera when required makes it less of an issue for me.
I am not a hardware engineer or anything of the sort. My laptop has a slide shutter over the webcam, but this obviously does nothing about the microphone. How difficult/error prone would it be for the power signals to the microphone and camera to be individual wires/traces and have a physical switch that breaks the power or data connection physically? Surely these are very low voltage so the switch could be like the iphone mute switch?
My Framework 13 has this - 2 physical switches next to the camera.
I would assume (but haven't checked), that they physically disconnect the camera/mic.
The Framework laptop does this for both microphone and webcam, and there are privacy focused Android phones which also have a microphone switch which cuts the power to the microphone. It's definitely possible.
For what it's worth, my Lenovo laptop has a manuel shutter slider button on the side that actually physically covers the camera (and it must also does something driver wise because windows considers it unplugged). It's so easy and convenient that I always use to off the camera.
Many of lenovo have that even included their gaming laptop line (it's actually even better and more convient on that one, thanks to the larger size available).
Doesn't solve the problem this article talks about, but if that's something that worries you I would still trust that more than most (and it's a lot less weirdo looking than taping your camera).
This exploit picks up audio, too. The shutter helps make sure you're not accidentally sending nudes to North Korea's hacking teams, but audio can still be hijacked unfortunately.
Taping your camera doesn't necessarily look like anything. I have a small piece of electrical tape over my webcam, and it blends in so perfectly with the background that other people probably wouldn't see it unless they were specifically looking for it.
(I personally just leave the tape there all the time, because if I need to videoconference, I’d rather connect my mirrorless camera with a much better lens and sexy bokeh.)
The Electronic Frontier Foundation sells a set of stickers exactly for this purpose [0]. I have a set and it works reasonably well. And it supports a good cause.
How does the Macbook check the ambient light to determine the screen brightness, does it have a separate ambient light detector buried under the screen somewhere or inside the camera? (if the camera is not used for this I mean which would have been the best thing to do, but would require the camera to grab frames now and then without the LED flashing)
> Cameras and microphones and write enable must have physical switches, not software ones. When will people learn?
Your preferences are not everybody's. Personally, I'd be totally fine with a camera and microphone LED that is guaranteed to activate whenever there is power/signal flowing from either.
> Me, I unplug the camera and mike when not in use.
That's a bit hard to do on a laptop that has both built in.
Some laptops (I've seen it on a lot of Thinkpads) include a physical cover that can be slid over the webcam when you aren't using it. While that doesn't cut power to the camera or mic, I figure would pretty straightforward for manufacturers to add contacts to the camera cover to use it as a power killswitch instead of just a privacy cover.
I think that's pretty standard outside the Apple ecosystem. HP seem to have this on most (if not all) the laptops I've seen at $DAY_JOB which uses HP for all laptops.
> Cameras and microphones and write enable must have physical switches, not software ones. When will people learn?
I feel like people were pleading for this when people were getting ratted and began taping over their cameras, and the tiny number of laptop manufacturers just ignored what would be a cheap easy change. Eventually, people just accepted that it must be impossible to install a switch. I couldn't ever think of any motivation for a lack of a switch other than government pressure, so I've always assumed that the cameras and microphones are backdoored.
I don't get how "some tape" became the standard solution for these thousand dollar devices.
The odds of being targeted don't matter in what we're talking about. The fact its possible is what we're talking about. High value targets like zuck being well aware of that fact, and taking steps to guard against it is just icing on the cake.
Technology connections made a very sarcastic but entertaining explanation of the "stupid" design of being able to control the camera and the led independently.
after it can read my keyboard, .ssh files, browser cookie files... i couldn't care much for the camera. and everything you run can already do all that. occlude stuff you npm/cargo/mvn/go/pip/mix install. not to mention those git hooks or build scripts of that project you just downloaded the source in vscode and it's already running all that for your convenience right away.
I am so disappointed that there are camera LEDs out there that they aren't hardware connected to the sensor. Especially when there are bio-metric sensors out there that can do a crap-ton of calculation all in-device so no privacy concerns arise. I wonder if any of them are vulnerable to a firmware attack.
Don't even understand why laptops have cameras and microphones. If you're serious about video meetings you'll want an external camera anyway.
I keep covering them up with bits of paper (because like most people, I don't trust LEDs or switches) that look ugly and invariably get blown off by a gust of wind and have to be reapplied when moving.
It just seems like at some point around 2010 some cabal decided that every device with a screen needs to have a camera facing the user and a microphone.
> Don't even understand why laptops have cameras and microphones. If you're serious about video meetings you'll want an external camera anyway.
The whole point of a laptop is to be able to move around and travel with it.
FWIW you can still encounter laptops without webcams (MNT reform comes to my mind) and you can also choose to disable/load/unload the kernel modules for them dynamically on linux distros and BSDs
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.
Having the LED control exposed through the firmware completely defeats this.
reply