A potential issue regarding the WiFi LED indicator was pointed out over Matrix.
The Librem 14 has status LEDs that indicate the state of WiFi/BlueTooth connectivity as well as the Camera/Microphone. The default behavior of the WiFi LED is to be on when the WiFi card is receiving power, same can be said for the Camera/Microphone switch. Normally this is sane behaviour, the LEDs give a clear and obvious indication of the status of the wireless, camera and microphone in all conditions (including the dark) and our eyes are drawn to them very quickly. Importantly, customers will tend to ignore the position of the kill switch or other contextual information and will assume that the LED is a reliable indicator of state, particularly due to our focus being drawn towards lights. Even informed users will subconsciously behave this way.
In Nicole’s last post about the Librem 14, she confirms that while the LEDs are reliable indicators of whether the power is cut and the killswitch is off (due to the nature of how the Librem 14 is wired), it is fully possible for the operating system to disable the indicator LED while the WiFi killswitch is in the ON position. In fact, the post explains that it is the default behavior of the EC to turn off the LED indicator when Linux sends the RFKILL signal. Nicole even goes so far as to demonstrate how to turn off the LED light ourselves.
It is possible for a customer to be very easily tricked into thinking that the WiFi and BlueTooth are safely disabled and not receiving power when this is not the case. This is extremely dangerous behavior. Although the position of the killswitch gives it away, customers will still make the mistake of trusting the LED, thus the assumption that WiFi is fully disabled when the LED is off must be solid. Unfortunately, this is not the case.
Hardware kill switches are meant to be useful in situations when we can not assume the OS and software to not be compromised, allowing the LED WiFi status indicator to be disabled by the OS or EC undermines a key purpose of the killswitch.
My Preferred Solution: Mandatory Minimum LED Brightness. LED brightness can not be set to zero when the WiFi card is receiving power. The brightness can move between or alternate between a minimum “dim” level and maximum brighthtness, but not turned off. The light should only be entirely off when there is the WiFi card is not receiving power.
Feel free to correct me if I’ve fundamentally misunderstood how the Librem 14’s LEDs behave.
hm never thought of it that way.
probably the easiest option in this case, if you are afraid to be fooled by the LED, would be the disable the LED completely so it is never on no matter the state of the WiFi card.
Then the HKS becomes your main information regarding the state of the WiFi Module again.
That’s true. Nonetheless, not using a feature because it puts you at risk is not what I call a full solution. Someone needs to enforce minimum brightness.
Someone needs to enforce not coddling the customer. At some point, the customer’s mistake is the customer’s fault. That includes not being cognisant of the position of the killswitch.
Plus, some customers hate LEDs. “Minimum brightness” isn’t the solution to this, “educated customer” is.
I think only the RGB LED is controlled via a PWM interface the other two LEDs are only on/off from how I read the blog post. So you’d need to toggle them all the time or change the code in the EC controller for it to do that for you, which you also can with all the risks involved playing with that controller.
I’ve gone to great lengths to stress that expecting customers to be educated on this is neither a solution nor reasonable. Frankly, I expected this response but am still highly disappointed.
Of course it’s reasonable. Why shouldn’t one expect a functioning member of society to know what the hardware they own is doing? Further, why should a company who’s mantra is “freedom” and “you own your hardware” start thinking for the customer? Why should anyone else decide for me or for any user how one’s hardware should behave? Why should I have so little control that I cannot turn off a LED?
Disappointed is correct, sir, but yours is clearly misguided.
The most vulnerable element is always the human one, it is good design to build a computing system with this understanding.
Tools made for usage by humans must be built around the quirks and oddities of human behaviour. Every facet of engineering and design, whether technical (electrical) or otherwise, is approached with this understanding. Computer design is no different.
Simply addressing the issue directly by enforcing a mandatory dim or otherwise is better design. It does not “baby” or reduce users freedom.
I don’t understand why you refuse to accept the issue, especially considering I have laid out a reasonable proposal for improvement. Even if you do not agree with the extent of my concern, you have no reason to not back potential improvements that would circumvent this issue.
I personally will. However, this is especially a problem for people who are simply not aware of this issue. The default is to assume the LEDs are trustworthy.
Besides, what’s the point of having LEDs if I need to disable them for my system to be more secure?
Let’s just patch the issue via the EC and then implement a hardware-based minimum mandatory dim brightness in the next revision, OK?
I agree with the sentiment of @MrSenshi if not the methods.
While I agree that users should be educated, I also think that reasonable and responsible defaults while they are getting educated is a good thing. (Not to say the current default isn’t reasonable/responsible at all, just that I think it could be improved)
I think the default behaviour should be for the LED’s to only switch off with the hardware switch and that a software/firmware change should be required to allow the LED to turn off when the software turns the radio/camera/etc off. This way the default mode is LED represents switch state. (Default secure).
I understand how the current default makes sense though which is the LED represents the useful state, LED is only on if the radio/camera/etc is usable. (Default convenient)
The idea of a minimum brightness for when the switch is on but software has the functionality disabled then full bright when enabled is interesting, but I expect this to be the most complicated for users. If it could be amber then green I’d be more behind it. The issue I have with the dimming option is that dimmed LED’s tend to result in support calls because something seems “broken”. Also I would expect the people that don’t bother to educate themselves (the ones trying to be protected by this option) would be the ones most likely to think something is wrong or that “it’s not turning off when I tell it to and I have to use the switch when I just want to use the software”.
Maybe another option of always off for those that don’t want to trust a light at all since it is possible for an LED to fail and thus have the LED off when the switch is on in any other configuration.
Neither one is more correct than the other, just different focus’s.
The best option would be a prompt during configuration to select which of the modes you would prefer thus allowing the user to choose which mode is most relevant to them. It may very well be that more would choose the current default for one reason or another.
@Gavaudan shouldn’t the user be expected to be educated enough to change the default to whatever behaviour they want? In turn, do defaults even matter when the expectation is the user should be educated enough to change them? (This is somewhat rhetorical, and could lead off topic so if anyone wants to explore the philosophical side of this it may make sense to fork here; I just wanted to throw it out there as you seem to feel fairly strongly on this, and FWIW I generally agree with the goal and desire).
I’m good, just surprised me that anyone in a community that stands against Apple’s walled garden approach tries to declare what’s best for users of a given platform.
Also there’s this growing trend of people on the forum telling someone else how their logical reasoning process works. I’m sick and tired of being told what I do or don’t or should or shouldn’t think. The arrogance turns my stomach.
I agree with the sentiment of what you are saying here but it’s totally unwarranted in this context. This place is safe from people who want to dictate how you should live your life to you, no one is trying to assert anything or infringe on your freedoms. If I were interested in that, I wouldn’t be here. This is all in the spirit of progress. We’re all on the same side, you don’t have to accuse me of being a walled-garden Apple fanboy.
Enforcing any protections on an EC-level would not restrict you from doing what you want in any real way, you can always reflash the EC, it’s just good default behavior.
Further, I am not trying to be arrogant, I simply have opinions just as you do and am fully entitled to thinking that you’ve got this wrong. There is no pressure for you to agree, please do not assume that there is. From my perspective, I am yet to recieve a satisfying answer as to why you are so firmly opposed to changing this behavior.
Honestly, I think you probably just feel insulted by the suggestion that you need safeguards to prevent you from being tricked. I’ll make this absolutely clear: I am not insinuating that anyone is ignorant or can not be trusted. I’m not in the business of installing training wheels, either.
The protections I’m proposing are simply a means of bringing our intuitive perception of what the LED state means in line with what is actually happening. This is just tailoring the way information is delivered around how our minds tend to behave. This is just good design.
Unfortunately, there are no perfect solutions. Yes, there will always be people who will be frustrated and confused as to why the LED is not behaving as expected by default (until they read the docs and realise why the minimum brightness is mandated by default). I would argue that it is still preferable to any other options.
Giving the option for users to configure the behavior on first install likely implies that the OS has the ability to arbitrarily change the behavior of the LED. If that is the case, then you return to the exact same situation. This has the consequence of creating even more false confidence that the LED is reporting information accurately. Ultimately, I do not think this is a better option.
I’m obviously open to other suggestions, but I still think mandatory minimum brightness enforced by the EC (requiring EC reflash to change this behavior) is absolutely the best option.
I mean if it can be reflashed it can be reflashed from the OS. If you don’t trust the OS to not reflash it arbitrarily then that is a different problem and the realistic solution is to choose not to use the LED’s at all and select the option of always off, this way you never get used to the LED’s and if you see them on you’ll know the setting was changed.
At some point you either have some amount of trust or write and compiled all of the code yourself.
You’re right, however I’m operating under the assumption that the EC write switch is set to off (read-only mode) by default. If this is the case, then you actually can’t arbitrarily reflash.
Anyway, I’m hoping this is done on the hardware level on the next revision.
So yes, I can see the point here, though I am not totally convinced that this is really super critical. But yes, I can see that some solution making sure that the visual feedback can not be defeated is a good idea. But we have a bit of a problem here. This is the circuit for the WiFi/BT LED from the schematics:
Here you can see there is the WIFI_LED_WHITE signal coming from page 35, this is the pin from the EC. This pin is a regular GPIO and can not be configured for PWM, so no way to implement some dimming there. The power supply +V3.3_WIFI_R is the voltage actually switched on/off by the HKS. So what is happening here is that if WIFI_LED_WHITE gets HIGH then the transistor switches through and the LED’s cathode gets connected to GND, current is flowing from +V3.3_WIFI_R through the LED and the 1k resistor, the LED emits light.
What I think probably could be possible, but would need to check back with the engineers, would be to add an additional resistor between pins 2&3 of the transistor which would then determine the “low minimum brightness” - say, maybe 500 Ohms. That should result in a lower brightness but if the transistor switches through it would still go to full brightness.
It could be a quite simple change on the PCB - but still a PCB change which means it will not get implemented any time soon. And we would need to play a bit with the additional resistor value to tune the brightness level so that both levels are easily distinguishable.
Please don’t do that if you’ve got another pin free on the EC Controller you could use that so this feature could be activated or deactivated via a EC Firmware change but don’t activate it by default.
I’d really like to be able to switch off all the LEDs on the Laptop.
For example to leave it plugged in over night in a Hotel room.
Or use it in other low light conditions where a minimum brightness level visible in daylight, might be way to bright.
