[jstanley]

1. No, it was very easy. I used a normal USB cable and adb on the Linux command line, but 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.

2. No, it is very convenient. It has a sandbox for Google Play Services, which IMO is the best of both worlds as it means you can install all the proprietary crapware apps that make modern life tolerable, but Google Play doesn't have unfettered access to everything on your phone. If you want even more isolation you can set up a separate user and run all the Google Play stuff in a separate user account, which I did briefly try but personally I can't be bothered switching user all the time.

The phone has never crashed. My bank apps work.

I have a Pixel 6a.

[Pfhortune]

FWIW, I've used the Web USB installer probably a dozen times without issue, so I would definitely recommend that route if adb is intimidating. I've done it both ways, but the web installer is so easy it feels magical.

As for it not working, were you running a Flatpak/Snap version of the browser? Apparently those are problematic with Web USB. I personally haven't tried on Linux yet (just Mac O's) but now that I've switched to Fedora I might encounter the same issue you did.

[neilv]

Tip: The GrapheneOS Web installer doesn't work for me with the Chromium in Debian Stable.

I always try the Web installer, to see whether it works now, but then end up doing the command line method (which is also pretty easy, compared to historically how Android phone flashing used to work).

[jstanley]

Yes I think it might have been a snap.

[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.

[talhah]

Do things such as Gcam and Google Pay work?

The two major things I need from my phone is good camera quality and being able to use Google Pay which is useful where I'm at.

[asdp9iujaspid]

Google Camera works fine, but is not included out-the-box

Google Pay will not work as GrapheneOS makes no attempt to masquerade as a Google-Certified device [0]

[0] https://grapheneos.org/usage#banking-apps

[Suffocate5100]

It does not work on the phone, but I was able to use NFC payments with Google Wallet through my Pixel Watch.

[strcat]

Pixel Camera works fine. It doesn't require Google Play, but the functionality dependent on Google Play and AR Services does work fine on GrapheneOS via sandboxed Google Play.

You can install it via the sandboxed Play Store. Trying to install it via Aurora Store won't work properly unless you set the proper device model.

Google Pay doesn't allow NFC payments on an OS that's not certified by Google. It checks via Play Integrity. You can use a Pixel Watch with GrapheneOS to work around this since the Pixel Watch with the stock OS can make NFC payments itself without the OS on the phone needing to be Google certified. This is not a technical issue but rather a regulation issue. Play Integrity is absolutely not a real security feature but rather part of enforcing Google's licensing system which is presented as a way to defend against tampering with apps. In reality, it's very easy to bypass the device integrity mode via spoofing but not in a way that's suitable for a production quality OS which needs to keep working. It serves the purpose of stopping people using Google Pay and a subset of banking apps with a more secure OS but doesn't stop people using it with a much less secure OS where they're using one of the implementations of spoofing the checks. It's unfortunate. We support for Android's more meaningful hardware-based attestation but app developers need to whitelist GrapheneOS. It's covered at https://grapheneos.org/articles/attestation-compatibility-gu... for app developers, but we haven't yet made a big push to get some of them to do this. It's highly unlikely that Google Pay would do it without the EU saying they must.

[nani8ot]

Some banks have their own contactless payment app, which can be set as default in GrapheneOS (or any Android). Most banking apps work, as long as they use AOSP's hardware attestation feature instead of Google's SafetyNet, which requires the same Google device certification as GPay.

[1] https://grapheneos.org/usage#banking-apps

[jstanley]

I don't know what Gcam is, but it comes with a camera app.

I've never used Google Pay so I don't know.

[luke-stanley]

The Google Camera app can be made to work fairly easily. Google Pay's NFC payment will not work in a useful way because the environment signature differs.

[codethief]

> The Google Camera app can be made to work fairly easily.

In fact, it's as easy as installing it through Play Store.

[moose44]

Second this.