When comparing against something like a Pixel running GrapheneOS, it's honestly a bit more puzzling to me. Granted, I'm definitely not the audience for this, but with G_OS you can do most things that a regular phone can do, without taking several minutes to install Firefox.
As much as I love privacy (going as far as having a semi-random username), this phone is a bit puzzling. I hope someone can throw more light on this.
I'm not familiar with GrapheneOS but I assume it follows the usual model when repurposing Android devices of taking various closed source blobs (i.e. drivers etc) and rebuilding the open source bits around them? If so, this approach usually locks you into a Linux kernel version to remain compatible with the blobs which limits you on kernel features and fixes as well as who knows what exposure the blobs have to offer, which also will likely never get updates.
Sticking to an LTS kernel branch for the lifetime of the device isn't due to anything closed source. GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers. We can support pretty much any mobile device with alternate OS support since any serious one will have AOSP support. Most devices have lackluster security and don't meet our requirements. We're working with a hardware vendor to get a non-Pixel phone actually meeting reasonable security requirements.
Librem 5 has a bunch of components where they are not shipping updates. You have things very much backwards on that front. The Librem 5 does not come close to meeting the security requirements to run GrapheneOS. It has a bunch of poorly secured and insecurely configured legacy hardware often without proper updates available, components that are not properly isolated via IOMMU, no secure element or all the stuff that comes along with that (HSM keystore with a nice API used by apps, Weaver to make disk encryption work for users without a high entropy passphrase like 7 diceware words, insider attack resistance, working attestation not depending on hard-wiring hashes and a lot more) and many other things. The OS they use has a near total lack of any systemic overall privacy/security work or privacy/security model and only falls further and further behind. The most exciting feature for securing devices right now is hardware memory tagging support in ARMv9, but there are years and years of tons of important privacy/security work done in a systemic way across hardware/firmware/software which are missing there before worrying about stuff like that.
Marketing something as private/secure and spreading tons of misinformation and outright lies about the mainstream options doesn't make it secure or more secure than those. It's actually pretty funny that they mislead people about the isolation of hardware components like the cellular baseband in other devices when the vast majority of mainstream phones (iPhone, Pixel, Qualcomm SoC devices, Exynos SoC devices) have it done quite well when they don't. Strange that they get away with these games of misrepresenting things, hiding the fact that they still have entirely proprietary hardware and near entirely proprietary firmware for the SoC and other hardware components, etc. Hiding proprietary stuff doesn't make it go away. Not updating it doesn't make it go away and simply ensures a highly insecure device.
That's true and relevant to Purism.
Now, how about something true and relevant to your post wrt FOSS:
> GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers.
Tell me about the license for the source of "all the firmware." And keep in mind you found it important enough to reiterate the point about "no closed source" for the kernel drivers.
There isn't anything remotely misleading about the correction that kernel drivers are not in the same situation as most firmware in that they're entirely open source. Every ARM SoC is a proprietary SoC with proprietary CPU cores, memory controller, GPU, image processor, radios and all the other massive complexity included in them. There's a ton of firmware involved in that proprietary hardware. It exists whether or not it's updated. Not updating the radio, GPU, etc. firmware doesn't mean it doesn't exist. Whether or not it's open or closed source has little relevance to the need for it to be hardened, properly isolated and updated. Open or closed source does not directly provide any privacy or security properties. Other components outside the SoC are almost always closed source too. We don't think the fact that the Pixel 6 has a TEE OS based on the open source Trusty TEE or a RISC-V secure element based on OpenTitan makes it inherently more secure than Qualcomm's offerings. Pixel 6 having a Samsung cellular radio and Broadcom Wi-Fi/Bluetooth radio as 2 separate chips from the SoC instead of being part of the SoC has not made those more isolated or more open, and if anything we consider moving away from the Qualcomm radios to be a security regression with how well Qualcomm hardens them, although the overall improvements make up for it. If we made a device, it would have a Qualcomm Snapdragon 8 Gen 1, and we'd be quite happy with having the most secure radios, hardware memory tagging support and Qualcomm's great security work elsewhere. Would it be nice if we could have more control and insight? Sure. If a theoretical currently non-existent open source RISC-V smartphone SoC existed and it had comparable privacy/security (which would be very difficult), we'd be very interested. It would take massive work beyond simply having a viable SoC in the performance class with the necessary functionality to make anything remotely competitive on a security level.
GrapheneOS is a non-profit open source project and doesn't produce or sell hardware products. We don't do consulting, exclusive deals with companies or anything like that. There is no intention to ever sell any products, but rather we research hardware, report issues upstream and choose the best available hardware as the officially supported targets. We also intend to work with hardware partners on equal footing with nothing exclusive to help them produce better devices, which will benefit them and will benefit us through having more and better devices to support. We could potentially get more reliable donation revenue through devices with GrapheneOS installed, but that's in no way any kind of requirement for us to work with vendors. We have little to no interest in ever selling devices ourselves. We're fine with the fact that over a dozen companies sell devices with GrapheneOS installed mostly without giving anything back to us. Only a couple give us any form of donations/support. This is not a business.
The claim that there are closed source kernel drivers is untrue for most mainstream Android devices and is a misunderstanding of why devices stick to a specific LTS kernel branch. Those branches receive 6 years of support now because of the model that's used for mainstream embedded / mobile devices. They don't want to port their drivers to newer versions and spend a year getting it working robustly again. It would be entirely possible to do it and it's possible it will happen for Tensor but it can be an overall bad thing for security instead of a good one due to all the added attack surface. A great example is how a bunch of recent vulnerabilities such as 'Dirty Pipe' only impacted the Pixel 6 due to it using the 5.10 LTS branch which was the newest at the time. A Qualcomm device wouldn't have been impacted due to having an older kernel branch.