I noticed that there are no hardware switches for the GPS, Speakers, or the Gyroscope. Having a dedicated Hardware Switch for the GPS would be good because that way it cannot be used by a program to keep track of you while you are offline, and then upload the information once you reconnect.
Some people may not be aware, but Speakers and Gyroscopes can be used as microphones. Although the Gyroscope isn’t nearly as good at this, it can still be a privacy/security issue, especially as voice and audio software improves.
A simple fix could be to connect the GPS to the Modem’s Hardware Switch (since they both can be used to track your location) and the Speaker, and Gyroscope, to the Microphone and Camera Hardware Switch. Although, I would recommend another switch for this since it can be a user experience issue for something many people might consider low risk. However, having a dedicated switch would be good for those that don’t want to take the risk.
Clearly the number of hardware kill switches is a difficult design issue, a compromise between flexibility and usability, as well as acknowledging a physical constraint.
Apparently Purism has decided that there is no separate kill switch for the GPS or the sensors. If you kill Cellular + WiFi + mic/cam then you also kill GPS and the sensors. That at least partly addresses your concern.
I don’t believe that anything would be “a simple fix” this late in the development process.
Disabling the GPS is not as important in an open source environment, since you can verify that a hypothetical program is not behaving in the manner that you describe and/or you can change it so that it does not behave that way. Where you choose to run an untrusted application in a sandbox environment, the sandbox itself can manage access to the GPS, whether by outright denial or by allowing only fuzzy values or by rate limiting.
With an open source operating system, the operating system itself can mediate access to most if not all peripherals.
It’s not an easily fixable thing. There are several combos that each have pros and cons. For instance, I’d like to have speaker to be killed with mic and cam, as that would “blind it’s senses”, where as others “prevent data movement”. I’d also not like to kill GPS and gyro if I kill everything else (I may want to use a map/navigate while being private and maybe saving power - It would be pretty safe since nothing can be broadcast [but could be recorded for later - but that’s why you only use safe apps]). But then again, what if I need BT? Or only want to kill GPS and modem, but would like and app to count how many steps I’ve taken?
Adding to what @kieran said, SW switches do work and can be trusted more in Linux - HW just does it more… absolutely.
[edit: Silly question, but I can’t remember where this may have been talked about… Is the HWx3 to kill GPS done with HW or SW switching? It’s a feature done in software, isn’t it? Can it be changed or reprogrammed to other stuff - and if any of the HW switches are used, is there any SW component like a notification?]
Thanks @mladen - I knew I’d something about this but just couldn’t place it.
" When in Lockdown Mode, in addition to powering off the cameras, microphone, WiFi, Bluetooth and cellular baseband we also cut power to GNSS, IMU, and ambient light and proximity sensors."
–> HW
“OS could detect when Lockdown Mode is enabled and automatically lock your screen. Those who are under even greater threats could potentially have Lockdown Mode enable extra defenses inside the OS, disable certain services, or even shut down or wipe the phone (although I’d suggest you set up some kind of PIN prompt for that last one, in case you trigger all the switches by accident). There are a lot of possibilities for this new feature and I’m looking forward to seeing how our customers extend it on their own phones.”
–> and SW
But does beg the question: can these triggers be used, if you are using only one (or combination of two) HW switch(es)? Some GUI setting or terminal command (or may not exist yet)?
HKS for the WiFi will probably make the interface go away, which in turn can probably be hooked into. I guess we won’t know for sure until we get the phone.
It may also depend on whether you want to trigger on “on” (killed → not killed) or “off” (not killed → killed). Maybe you can use a udev rule and/or systemd service.
Add: udev rule commands should be quick executing. If you need something to happen that is going to take a long time then you need to trigger something in turn.
As far as I am aware, only the off+off+off (where off means killed) case has any special meaning. Otherwise the switches operate orthogonally and simply, and there is no need for a truth table.
Since the schematics are published, if your expertise lies in that area, perhaps you can confirm that.
But then if you are going to assign additional meaning to combinations of switches, as @JR-Fi proposes, yes, you might need to publish a personalized truth table for yourself. Sounds overly complicated and potentially inflexible to me.
If a user wants to go down that road then the user is probably going to be asking Purism for a few extra user-definable switches.
We’ve discussed the reasoning behind why we stopped at three HKS in previous threads. Lockdown Mode offers a compromise for folks who want the ability to disable everything. When it comes to disabling the sensors you have two main options: Lockdown Mode which will disable all sensors in hardware, or disabling individual sensors using software (which should be more trustworthy and accessible an option than software disabling in other proprietary OSes). Which option you choose, and which combination of hardware + software switches you choose will depend on your threat and what you are trying to accomplish.
I have said in a previous thread on this issue that I intend on writing up a hardening guide for the Librem 5, hopefully in time for launch, that will document some of these scenarios.
I wasn’t going down the path of engineering, I was gaming it. I thought a small table of cumulative effect, (or decremented effects) would be useful. i.e.
If you turn X off, and leave Y and Z on, this will happen…
If you turn X and Y off, but leave Z on, the other will happen … etc.
It doesn’t have to be defined by engineering, but reported based on user experiences, like the law of unintended consequences, based on discovery.
i know people that try to get through life by mechanically memorizing what consequences some choices lead to but life is much too complex and fluid for that to be an effective strategy so they inevitably reach a point of isolation and despair when the methods that they relied on so heavily before start to lose efficacy or even outright fail them.
i always say this “Chess is great but life is greater …”
Lockdown mode is implemented in hardware (via NAND gates I believe), where triggering all three HKS disables the rest of the sensor hardware in hardware. In my Lockdown Mode post I talk about the fact that an end user could, in addition to what Lockdown Mode already does, potentially detect the phone has entered that mode and do additional things in software, such as lock the screen, unmount disks, etc.
It’s only a matter of repetition and learning - it won’t take long. One use could be to prevent opening screen (login/pin) without switches in certain position - either to make gaining access harder or to prevent accidentally going online or something like that. It would be nice to have a gui (truth table) for assigning (one or more) command / functionality in settings…
As an example of how that could get tricky … let’s suppose that you decide that WiFi must be “off” in order to log in, that’s fine as far as it goes but what happens if I am using some distributed authentication mechanism that requires network access in order to log in? OK, so you hope that you can kill WiFi, enter the login, very quickly unkill the WiFi, in time for the WiFi to come up before the login mechanism times out. (What happens if I have background processes that are using the network?)
A related aspect would be if I wanted to enter my login via a Bluetooth keyboard - but the WiFi must be off, so that kills the BT too, so I can’t enter my login. (What happens if I have background processes that are using BT e.g. playing music on BT speaker?)
(The opposite i.e. that you decide that WiFi must be “on” in order to unlock doesn’t have any of these issues but then I just think that I want to have WiFi “off” basically all of the time when out in public, but will still want to unlock in public without suddenly broadcasting WAP MAC addresses etc.)
I admit that both these examples are a bit sketchy for a classic, standalone, paranoid phone - who would even trust a distributed authentication mechanism? and what happens if you are unavoidably offline?
Don’t get me wrong. It will be your phone and you can do absolutely whatever you want. That’s why many of us are backing the L5 - a phone that you control, rather than it controls you.
In your examples, it’s up to the user to choose which combo to use and adjust accordingly. It’s a choice of using wireless keyboard (in stead of screen for some reason) to log in or having that connection off. Or to be more precise, it’s a limitation of the system that both can’t be used but I’d like to see it as a positive, that you have additional features in using the switch combinations (they just aren’t always usable for every possible combination). Imagine what we could have done with an additional user programmable switch!
@tracy: I thought it’s nowadays “In capitalist America/west, TV watches YOU (and listens, and logs your program habits and copies your addressbook and monitors your network and…)”
