It's immensely frustrating for us (GrapheneOS) because we desperately want more devices to support but the devices supposedly focused on privacy/security are really massive setbacks for it. We want to convince vendors with the resources available to produce devices on the same security level as Pixels with a couple additional features. It would also be neat to be considered an official OS without the verified boot notice from loading a key from the secure element instead of a hard-wired key in the firmware, but that's not important. We've found one vendor interested in listening us and acting on it. It remains to be seen how that goes.

Our perspective is that this has been made immensely harder by the dozens of 'secure' phone companies providing something far worse than iPhones and Pixels. Most of those aren't presented as being 'open hardware' that's not at all open hardware, but they do share a lot in common. A few of them were so bad that they were actually law enforcement stings from the beginning (https://en.wikipedia.org/wiki/ANOM) or turned into them (https://en.wikipedia.org/wiki/EncroChat) which is amusing.

We'd happily target iPhones but Pixels are the only smartphones providing proper alternate OS support. On Pixels we get to have full verified boot covering all the OS images with downgrade protection, very nicely designed hardware attestation, all the hardware keystore capabilities, the disk encryption key derivation throttling feature with insider attack resistance, A/B updates for the firmware/OS, etc. This is the stuff we expect other vendors to provide us with in order to support their phones. Vendors using a flagship Qualcomm SoC, including the alternate OS verified boot / attestation support and doing a good job with security work themselves come close, but we need more than that. There's a fair bit missing without vendors caring enough to go above and beyond with security and alternate OS support.

When we look at the Librem 5, what we see is rolling back privacy/security massively on the hardware, firmware and software levels with no possible way we could support it. We were actually in contact with them at one point but it became clear that they had zero interest in anything more than an empty partnership where out name would be used for marketing without us being able to use the device at all. That was back before lots of the security improvements in the Android smartphone world where Pixels caught up and even surpassed iPhone security in most areas.

Our expectations used to be far lower, and they get higher as devices like iPhones/Pixels get better. For example, Weaver showed up with the Pixel 2, as did the related secure element insider attack resistance where the main owner user has to authenticate for firmware updates to be applied. Before then, the SEP was way ahead in this area, and continued to be ahead in a lot of others until the Titan M. Weaver provides always enabled aggressive throttling for disk encryption key derivation attempts, with full support for the separate per-user encryption keys. It quickly throttles up to 1 day per attempt after 140 failed attempts. We take it for granted that we get all this stuff including the hardware keystore with physical confirmation support, etc. We expect these features from other vendors. It's not a lot to ask that they implement a feature like Weaver which was introduced with the Pixel 2 via open source AOSP code for the OS integration and open source secure element applets for an off-the-shelf Java smartcard secure element. That got obsoleted by the Titan M, which is actually well on the way to becoming open source with OpenTitan and the Pixel 6 shipping a RISC-V implementation of it based on that. It would be great for that to be fully open sourced and usable by other vendors. That's the kind of thing which is exciting in this area. Pixel 6 using Trusty OS for TrustZone isn't that compelling since TrustZone is terrible and largely obsolete beyond being the component responsible for talking to the actual secure element via authenticated encryption. They're also on the path to getting rid of it now that there's proper virtualization support, which is where the nonsense like Widevine is moving to be properly unprivileged/isolated unlike the mess of TrustZone.

It would be great if other vendors actually cared more and tried to actually compete with iPhone and Pixel security. We found a vendor that's willing to put in the effort, and we're optimistic about that. We're more than happy to work with others. The main thing we need to do is point them at what they need to implemented and the existing open source AOSP code for the OS side of it, etc. We have a lot of experience with this including reporting a bunch of firmware vulnerabilities / bugs in Pixels. There are so many things which could be done better but it starts with any other vendor catching up to where iPhones / Pixels where years ago.