This never happened.
But I can accept everything else.you’ve said. I’m sorry if I come across as harsh, but “saving the customer” is a slippery sloap paved with good intentions, and your proposition (mandating a “minimum brightness”), while arguably silly example, is exactly taking control away from the customer. I’m just trying to nip something in the bud.
(Sorry, misinterpreted your comment about support for the Apple walled-garden mentality as being in reference to me.)
Thanks for taking the time to respond! I personally would support such a change on a hardware level, however I accept that many people here want to be able to disable the lights. Between the potential for being duped and not being able to completely turn off a small LED (which you tape over) I’d pick the latter, although I sense disagreement. Perhaps a flash poll a little later down the line (maybe in anticipation of the L14v2) would be useful for deciding a course of action?
I would say: physically move the LEDs well away from the HKSs and don’t even pretend that the LEDs are a visual indication of the HKS state.
A customer would be free to configure an LED to reflect whatever is of interest to that customer i.e. fully user-customisable LEDs, including HKS state - but an LED should not out-of-the-box reflect HKS state. The “power of defaults” means that Purism is attempting to “save the customer”.
The whole point of a HKS is that you can rely on it even if your operating system is significantly compromised. Any LED that can be controlled in software by the operating system is therefore potentially able to be compromised and might in theory be used to socially-engineer the customer.
This might work as an alternative to the above i.e. EC config change is required to allow the operating system full control over the LEDs. So by default the LEDs reflect HKS state and the operating system has no control over that (attempts to do so are harmlessly and silently ignored) - but with an EC config change, the EC can hand over full control to the operating system. That way the documentation for doing that can warn the customer about the potential implications.
This discussion is a good example of why threat models are critical when you discuss security measures, and why it’s a rare security measure that is “one size fits all” (regardless of how security companies market things). It’s tempting to design for edge cases only, and many security professionals only live in a fantasy world of spy threats, and as a result design features that partially address the spy threat (sometimes) but don’t address the most common threats (because their solutions are often so convoluted or inconvenient that users simply disable them entirely).
The HKS is a convenient security feature that happens to be closer to “one size fits all” while the LED is more strictly aimed at convenience than security, and not necessarily designed for all threats. As has been pointed out, if the LED is on, you definitely know the camera is on (there is a strong security and convenience benefit here for most use cases). If the LED is off you don’t necessarily know that the camera is off (which may not address all threats).
The way we tend to approach security here is to attempt to address the security needs of the majority of people first, and if possible, to also add features to address the much higher threats (spy plots, etc. that people love to fantasize about) when possible. Sometimes that requires we add advanced features that aren’t default (this is why PureBoot isn’t yet our default boot firmware).
This is why, for instance, we ship our laptops with PureOS but also offer Qubes as an option. I would not advocate the average user switch to Qubes even though I’ve been using it for years. The steeper learning curve and lack of convenience it presents, and the requirement that you make the effort to divide workflows into compartments to get the security benefits, means that an average user very well could sabotage those extra security features by accident through how they use Qubes and therefore be no more secure than on PureOS.
For customers facing more extreme threats and who have the background/expertise or because of the threats are willing to put in the extra effort? Sure, use Qubes.
Back to HKS. The most likely threat an average user will face that this addresses is a generic Remote Access Trojan (RAT) that compromises the system and attempts to capture compromising pictures/video/files and extort the user. With the HKS they can know their webcam and mic are off, and the LED simply provides another convenient visual cue in addition to the state of the switch right beside it. While it will be useful for the user to notice the LED is on when they intend it to be off, I suspect the more useful use case will be seeing at a glance that it’s off when they want it to be on (ie. when they are about to make a video call).
On our end, like we stress in PureBoot to look at the Librem Key not the screen (even though we put feedback on the screen to warn the user of tampering), we will also stress to rely on the state of the physical switch not the LED to confirm state. I should underscore that moving the HKS back above the keyboard makes it much simpler to visually inspect it at a glance, compared to when it was on the side of the laptop.
The more advanced threat that we are discussing here in this thread, is an attacker that moves beyond the run of the mill RAT, and adds custom code that targets the Librem 14 specifically, potentially modifies the firmware, and turns off that LED. I would argue someone who is facing that more advanced adversary is someone who should certainly only trust the physical state of the HKS.
More importantly, an attacker who would attempt tampering with the LED in that way would also risk revealing themselves, as someone facing that more extreme threat should routinely compare the state of the LED and HKS, and if they noticed a discrepancy between the two, that would reveal a compromise.
Beyond that, someone facing that more extreme threat from an attacker who might modify firmware or install a persistent rootkit should also be using PureBoot to help detect that level of tampering.
anyone remember that scene from Mr.Robot when the guy from the street approaches the young couple and succeeds in selling his ‘new Album’ to the male and then later when he inserts it into his PC’s CD-drive it installs a hidden web-cam monitoring program that allows the ‘Rapper’ to spy on the young couple ??
i’ve seen an external usb powered web-cam from Serioux that has a plastic sliding cover for the lens … perhaps that could be an idea for the L14v2 for the extra pedantic out there.