[strcat]

> the recommended method involves using Web USB in Chromium which is meant to be easier for non-technical people but I couldn't get it to work.

There's a bug on many Linux distributions which was fixed in fwupd but is still present because they haven't updated it to a recent version. It interferes with reconnecting to the device when it reboots into fastbootd mode as part of the install. We cover it in our install guides now. fwupd usually loses the race to connect to the device to the CLI install tool but wins the race against Chromium's implementation, which is why it impacts web install more. This is likely what you experienced before we documented this fwupd bug and got them to fix it upstream. The problem is that even though fwupd fixed it a while ago, Debian and even the latest Ubuntu still have the bug.

[trompetenaccoun]

Since you seem to be on the Graphene team, may I piggyback on this: I've been wanting to make the switch over from iOS for some time but it bothers me a bit that I have to buy a Google phone. Are there any plans to support non-Google devices? I know this has been discussed and the answer I've seen is that Google devices are the best fit, but at least one more option would be nice.

[strcat]

The hardware requirements are listed here:

https://grapheneos.org/faq#future-devices

Pixels are the only Android devices meeting these requirements at the moment. Other devices do not currently come close to meeting these standards. This post is about MTE which is essentially a Pixel exclusive feature.

Simply receiving monthly and quarterly updates is essentially a Pixel exclusive feature and using an alternate OS providing them still leaves major parts of the firmware/OS without those improvements.

2 of the features on the requirements list are proposals we made to them which were accepted / implemented. There's another one of these pending for protection against data extraction via physical access through exploiting firmware boot modes on After First Unlock devices. Supposed to ship in April, and then we can add it to the list. The non-truncated key fingerprint display (we reported truncating it as a vulnerability) and the fantastic pinning-based hardware attestation support used by our Auditor app are the existing 2.

We've tried working with other OEMs but it hasn't panned out yet. We're often quite frustrated by Google but you'd probably be surprised at how much they have done based on our requests.

[ysnp]

(not on the team) I believe the project are open to supporting other devices that meet the criteria, or collaborating with hardware partners to that effect.

As I understand, the way it works is that the project first has to scope out a hardware target that meets their security requirements before support can be considered and funded for. Just that right now there are no other phones that meet the requirements specified in https://grapheneos.org/faq#future-devices

If a phone met those requirements and was not made by Google, GrapheneOS would consider supporting it. In the case that Google didn't meet the requirements but a different phone did, GrapheneOS would support that phone and not the Pixels.

[strcat]

> (not on the team) I believe the project are open to supporting other devices that meet the criteria, or collaborating with hardware partners to that effect.

Yes, we want GrapheneOS devices meeting the same security standards we've set based on the baseline provided by Pixels while also including additional features we want to have. Pixels are not the best possible hardware but rather the best available hardware by far. There are no other devices even coming close to the current requirements. iPhones come close but are missing major things like MTE which we expect and of course don't have any alternate OS support and their security APIs are the ones needed by iOS which wouldn't work for what we need.

> meets their security requirements

Worth noting that there are privacy requirements listed there too including this one:

> Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers

We could list a lot of other privacy, security and performance requirements which we take for granted. We're trying not to be overly strict with the requirements and are trying to keep it simple.

> If a phone met those requirements and was not made by Google, GrapheneOS would consider supporting it. In the case that Google didn't meet the requirements but a different phone did, GrapheneOS would support that phone and not the Pixels.

This is a factor in us advocating for MTE and other features even if they exist in a form we can use today. We do not take it for granted that future Pixels will continue providing what we expect. We push them to continue doing it and to keep important features we need. We know they're moving away from ARM Cortex cores to their own cores and we want them to provide an equally good MTE implementation. This means we need to advocate for MTE and get other people to advocate for MTE. If people eventually want to have CHERI and other more aggressive memory safety features, please advocate for what they've already shipped. Google enabling asynchronous MTE in production for their own code would be a huge security boost for Pixels and would also help assure that it has a future instead of being treated as a debugging feature they don't need to support on all their devices.

[thisislife2]

> Just that right now there are no other phones that meet the requirements specified

And that highlights the main goal of GrapheneOS - a security hardened mobile OS. (Note that better 'security' doesn't necessarily also mean better privacy protection).

[strcat]

Our work on security is entirely in service of privacy. Security is not the main goal of GrapheneOS. Highly usable privacy is the main goal of GrapheneOS and security is part of providing it.

The goal of GrapheneOS is providing a highly private, secure and usable mobile OS. It's not specifically focused on security above all else and we work on security in order to protect privacy. A huge portion of our work is on privacy features. We add many significant privacy features including Contact Scopes, Storage Scopes, per-connection MAC randomization, per-connection DHCP state, per-app Sensors toggle, per-app Network toggle doing more than blocking direct network traffic and much more. We have in-progress work on many privacy features including App Communication Scopes, improved state partitioning for Vanadium (privacy/security hardened Chromium) and a lot of other things.

We do a massive amount of work on usability including the whole sandboxed Google Play compatibility layer. We recently made an entirely new setup wizard and plan to replace all the legacy AOSP sample apps with better implementations. Our priority is the OS itself so replacing apps with multiple existing alternatives available simply isn't as high of a priority as improving the privacy, security and compatibility of the base OS. People can simply use another Contacts app so we don't heavily prioritize replacing the AOSP Contacts with our minor changes over focusing on important privacy and security features such as App Communication Scopes, 2-factor biometric unlock and a proper duress PIN/password without bypasses like existing implementations which are 3 current high priorities.

[rhizoma]

I felt the same, so bought a then 6-month old preowned Pixel 6 in as-new condition.