Reading the latest news:
all 3 will turn off GPS
Assuming this means that the GPS shuts down only when all three switches are off, it seems I can’t use the GPS for navigation with downloaded maps - unless I enable the mic and cameras. This is probably a reasonably small privacy/security issue.
Still I do find it a bit silly, as I think mic/cam have very little to do with the GPS. isn’t their use sort of orthogonal?
This seemed weird to me as well. What if I want to turn off GPS, wifi and cellular but still be able to take pictures?
I think it means any 1 turned off also kills GPS, but I don’t think that solves your issue, maybe only compounds it
Please keep in mind that you will always be able to turn off devices via software as well.
If you are NOT Ed Snowden, but paranoid enough to mistrust your software microphone switch, you could still remove the modem and then use the cellular kill switch to toggle GPS.
I would see a problem if the statement was meant to say “each of them also turns off GPS”
Like in avoiding location being tagged in certain photos? Didn’t think of that, but it also makes sense to want to do.
It could be, but that would mean you have to keep both Wifi and cellular on to use GPS. That doesn’t make sense to me.
Also, in another thread someone had been following Matrix discussions:
Hardware-wise, I would guess those are two-pole switches. One pole cuts power to either of Wifi, cellular and mic/camera. The other pole of all switches feeds the GPS, connected in paralell, so as long as any of them remains on, there is power.
You’re right, of course, and that’s what I will do. It’s normally good enough for my needs.
I assume the reason behind this design is limited space and a wish to avoid an array of controls. It is a tough problem when there are so many independent things one might want to turn off and be sure they’re off: two cameras, mic, accelerometer/gyro (can be used as a mic), GPS, wifi, cellular modem, bluetooth, USB.
There are several threads discussing kill switches, e.g. this one with actual design suggestions:
I wonder if the 3.5 mm mic/phones jack is still present. If it is, then the mic could also be killed using a plug with no cable leading out of it…
And a lens cover would be enough to kill the camera in my case, but maybe that would add too much thickness to the phone if made as a sliding part of the shell.
If you need off line navigation, buy a cheap GNSS terminal without wireless connexion. Mic is the main componant of a phone for more than a century…
I think Purism design is the best trade-off.
Have only GNSS chips disconnected whereas modem have GNSS capability and that WIFI can locate someone even more precisely makes no sense.
As mentioned above, the camera can easily be blocked by a sticker.
Have a 4th kill swith may turn the design into a nightmare (I think 3 is already a lot).
This combination of the 3 switches is an elegant design in my opinion.
I think this post by @patch was the most elegant switch solution. To summarize, it would be a single button to temporarily allow the software to change the state of the switches. I had the same idea after watching the video linked in that post but I didn’t have an account at the time so I didn’t end up joining that discussion. The only thing I would do differently is that I would prefer any additional overriding hardware switches to be under the back cover. With that solution they are less likely to be accidently enabled and it would allow control over every part individually. I know it’s far too late for v1 now but maybe they could implement something like that for v2.
As for the 3 switch GPS kill, I guess it’s probably the best solution they can have with the current design. I wonder if it will kill the accelerometer and gyroscope also? I think that might be a good idea.
Could a malware program wait for the user to press the button to change the state of another switch without his knowledge?
That’s the first flaw I can think of. Hardware or bust IMO.
I only gave a (vague) one line summary. Don’t judge the idea based on my post. The linked post describes LEDs to indicate whether a switch is active. It wasn’t instead of the main lower level kill switches but in addition to, I just said I’d prefer them under the back cover.
self destruct activate function key combo - turn wifi/micandcam/cellular off then press and hold the power button for 3 seconds - mission impossible cutscene next … nsa alerted
:TrollOn: If you want a smartphone that actually self destruct you can use a Note 7 :TrollOff: 
You beat me to it. It’s a way to have more granularity without adding lots of extra switches.
However, it has a flaw that seems not to have occured to me when I wrote that post. Although you can observe that malware has changed the switch state, you can’t actually stop it from changing it. You can turn off the main switch a split second later, but by that point the damage might already be done. (You can only control when the state changes to limit the potential damage, and even then only if you are alert to the possibility.)
To avoid that flaw, there would need to be a way to accept or decline the proposed change of state (in hardware). But, worse, it’s not inconceivable that malicious software could perform a timing attack to try to change its output right at the moment the user accepts it, potentially preventing the user from even seeing the malicious state if it happens quickly enough. There might even be a way to use another sensor that’s currently enabled to sense that the user is about to accept the state. This obviously makes the entire software-controlled-hardware-kill-switches feature useless.
So, acceptance of the new state into the hardware needs to be a two-step process: freeze the proposed state in its current form (in hardware), accepting no more changes to the proposal from the software, review the proposal on the LEDs (in hardware), and only then accept it.
Which is probably feasible (if somewhat costly) but leads me to wonder what else I’ve overlooked. Fixing the flaw would introduce more complexity and potentially more flaws. Maybe it’s not the magic best-of-both-worlds solution I thought it was. Certainly it shouldn’t be used in a way that effectively replaces the main kill switch by leaving it in the on position all the time. Both need to be used.
Heh, my description could have used that sentence.
I had thought of that flaw at the time but I don’t think it is that much of an issue considering the lower level switches available. It beats having nothing but software to disable the individual components as long as you can see whether a switch has had a state change from the LED indicators.
I actually like that two step idea. My ideal setup would be a push hold to allow a temporary pre state change, let go to disallow changes to the temporary state and press again within a second to confirm changes to the switches. I guess something like this would be kind of crazy to implement and perhaps a one button approach is not wise, but if it was designed carefully, I think it could be great. Well I can dream.
And honestly if you have malware and aren’t aware, you’re pretty much in trouble regardless of switch type.
To address the main topic of the thread: I didn’t notice the GPS kill-switching in the specs. It seems ambiguous.
Do they mean all three switches can individually be used to disable the GPS – logical OR, as in “All of the shops sell chocolate.”. Or do they mean that all three switches, used together, will disable the GPS – logical AND, as in “I bought chocolate from all of the shops.”? Either way it’s a bit limiting, but better than nothing, I suppose.
I wonder if anything better could be achieved by inverting one or two of the inputs to the AND or the OR.