While refuting posts that make exaggerated claims like this line-by-line isn’t a valuable use of time, it is worth making some more general statements about security as it pertains to our approach because it applies beyond any individual post from a critic.
People who come to us from an Android, Windows or iOS background often have issues with our approach because it’s so radically different than theirs. We have different constraints than Android, Windows, or iOS. We factor user control as opposed to vendor control heavily in our design and that often means rejecting security features that those communities accept. Those OSes make very secure cages, but unfortunately those cages restrict the user even more than the attacker. That’s largely the point of their approach–security against attack is the marketing story, but the prime motivation behind their measures is to prevent the user from changing settings or installing software the vendor doesn’t approve of (and in the case of iOS, the ability to remotely revoke software). This allows the OS, for instance, to enforce carrier restrictions on whether to allow tethering, install 3rd party applications by default that the user can’t remove, etc.
This approach is why we went with PureBoot instead of UEFI Secure Boot on our laptops, for instance. We wanted the ability to detect tampering but rejected an approach where the user would have to get the blessing of a vendor to boot the OS of their choosing. We chose to solve the problem in a way where the user was in control of their own keys and their own computer.
Our approach is to lay the foundation where the user can trust the system and has the tools to secure it, without depending upon Purism or other vendors as the anchor of all trust. We think the strongest foundation we can build trust on top of is free software and that is why we are pushing initiatives like reproducible builds so much. While it’s not impossible to inject malicious code into free software, and there are certainly examples in the past, it’s definitely much more difficult to do so without detection long-term than when dealing strictly with binaries. Will we consider some of the more advanced sandboxing kernel features for application in the future? Perhaps (and we already plan to do so for userspace apps via bubblewrap+flatpak), but we will always balance that with the desire to allow the user to control their own computer.
Beyond that, it’s silly to dismiss hardware kill switches entirely just by thinking of some scenario where they wouldn’t address a particular threat. They are a tool in the toolbox, and as such can be incredibly powerful when used thoughtfully (and properly) against many different threats. When used in concert with software switches within the OS itself you can get even more fine-grained control and protection from a wider array of threats given even the software switches within the OS are more trustworthy than, say, “location services” software switches in Android.
What you see in PureOS on the Librem 5 today is the foundation, the start, not the end, of our hardening plans. We have to start with a solid foundation before we can build more security controls on top of it.
For what it’s worth, I’m planning on writing up a general-purpose Librem 5 hardening guide before Evergreen ships, to guide people through some of the proper use cases for kill switches as well as how to further lock down the OS on top the hardening we have in place by default.