2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?
However, recently my wife and I travelled to Orlando Florida to visit Disney World and Universal Studios. While their apps mostly worked with sandboxed Google Play Services, I did have some annoying issues. The My Disney Experience app gave me a lot of glitches related to Location (it was intermittent but I would occasionally be told I need to be in US or Canada to do something important and we had to use my wife's phone as a workaround) and I found myself unable to log in to my account on the Universal App (again, worked fine on my wife's stock Samsung Galaxy so pretty sure it was GrapheneOS).
Another limitation is that if you use Google Wallet to make credit card payments, this is unsupported since Google will not certify GrapheneOS. Wallet does work otherwise.
Uber works just fine for me. Other than that, I don't use any proprietary apps.
If you intend to stick mostly to FOSS apps you shouldn't have any issues. Most proprietary apps will work with sandboxed Google Play Services, but if any of those are mission critical for you then be warned that you might run into some annoying issues like I did with Universal Studio & My Disney Experience.
Yes that means google will get your location, but it's still better than going back to stock which is also better than any other third party skin in terms of privacy/security.
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.
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.
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).
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.
I've never used Google Pay so I don't know.
In fact, it's as easy as installing it through Play Store.
Google Pay will not work as GrapheneOS makes no attempt to masquerade as a Google-Certified device [0]
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.
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.
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.
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).
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.
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.
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.
It's very easy to install with the web installer.
https://grapheneos.org/install/web
You can buy a device with it, but nearly anyone can use the web installer. It's particularly easy to use from Android, ChromeOS and macOS. Windows is a bit trickier since you need to install a driver. Desktop Linux requires installing udev rules, and some distributions with frozen software versions have a buggy service which interferes.
> Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions?
Non-technical people can do it. You only need a browser with WebUSB. You don't need any special software.
> Is it very inconvenient to use as a daily driver?
Nearly the same as the stock Pixel OS with nearly as broad app compatibility if you use sandboxed Google Play.
> How often phone just crashes and requires a few days of debugging?
You likely won't experience significantly more crashes. It has user-facing crash reporting not existing in the stock OS so you'll notice crashes you wouldn't have known about it. Buggy apps with memory corruption may crash until you enable the per-app compatibility mode, ESPECIALLY if you opt-in to forcing MTE for all user installed apps.
> Will my bank app work on it?
If your bank allows a non-Google-certified OS, which most still do. Banks are gradually disallowing using a non-Google-certified OS and this essentially needs to be addressing as an anti-competition regulation issue. We're working on convincing banks to use https://grapheneos.org/articles/attestation-compatibility-gu... in the meantime.
No but it is not the most convenient thing either. The Security Additions, Sandboxing Setup and a bit of slowness due to the hardened memory allocator are more annoying than just using plain android and clicking ok for whatever data it wants from you. Initial Setup and understanding what makes grapheneos different and how to use it's security features takes a bit though.
> How often phone just crashes and requires a few days of debugging?
Crashes? I haven't had one in my 4 years of usage. At least not a systemwide crash. Crashes that require days of debugging are in my experience not something that happens because hardware and software on pixel devices is well tuned for each other.
> Will my bank app work on it?
Depends on your banking app. Some work without any play services, most work with sandboxed playservices, very few do not work at all. Best you can do is tell us which bank you use and see if another user can confirm it works.
You can opt-out of secure app spawning if you deeply care about the small latency added to initial cold start app spawning time. You can opt-out of hardened_malloc with a per-app toggle if you find an app that's incompatible (memory corruption bugs caught by it) or which has bad performance with it.
There's no noticeable performance impact in regular usage. The only thing that was noticeable is the secure spawning (exec-based spawning) taking longer for initial app spawning time but that's entirely covered up by the animation time on current generation devices. There's a toggle for this for people who absolutely cannot cope with it, but we strongly recommend using secure spawning because many other security features depend on each app getting their own initial memory instead of being clones from the same template process (zygote) with a shared memory layout. It's not only about ASLR. It impacts PAC, MTE and any other partially or fully probabilistic mitigations.
> Crashes? I haven't had one in my 4 years of usage. At least not a systemwide crash. Crashes that require days of debugging are in my experience not something that happens because hardware and software on pixel devices is well tuned for each other.
GrapheneOS has user-facing crash reporting not present in the stock OS so users will definitely notice system process crashes they wouldn't have otherwise noticed. This helps us find issues like the Bluetooth crash the thread we posted was about fixing. We make all MTE detected crashes user facing since they tend to be serious issues and the crash reports tend to be useful for app developers or to us. We don't report all crashes by default but rather have a toggle for enabling that for the base OS in Settings > Security because it's too noisy. For example, sometimes hardware fails to fully wake up in the initial second of boot which automatically restarts the OS. It ends up reported as a kernel crash despite the fact that people wouldn't normally notice it. We got flooded with reports about this and had to reduce the scope of the user-facing reporting by default with opt-in to the rest.
Our features do find memory corruption bugs which were often not causing breakage in the stock OS but we believe this Bluetooth bug DOES often cause breakage in stock OS. It shows the other side of it which is that by finding the bugs, you can fix them, and you have fewer bugs remaining. GrapheneOS has dozens of fixes for upstream bugs. We try to report the security bugs upstream but their handling of non-security bug reports is awful so we don't bother for those.
> Depends on your banking app. Some work without any play services, most work with sandboxed playservices, very few do not work at all. Best you can do is tell us which bank you use and see if another user can confirm it works.
At this point, it's nearly just the apps that are deliberately trying to prevent using an alternate OS which don't work. Apps using Play Integrity API to forbid using an alternate OS is nearly anything that doesn't work. Some apps also have older implementations of manually detecting an alternate OS. For example, a tiny number of apps look at the call stack leading to starting their app and purposely crash it doesn't match the stock OS which happens with exec-based spawning enabled, which we could add a per-app toggle to work around but an alternative without more complexity would be making it show the same call stack. It's quite silly that this is a problem. Play Integrity API is replacing most of these custom hacks to detect tampering with apps, hooking apps, etc. Play Integrity API COULD allow using GrapheneOS by verifying it using hardware attestation but of course doesn't. Apps can use hardware attestation themselves to do this, but they don't currently do it. We're working on convincing at a few major apps to do that. It's covered at https://grapheneos.org/articles/attestation-compatibility-gu....
As for how it works, it's been my daily driver OS on my Google pixel 6 nearly since the pixel 6 came out, and I've never once had it crash on me. Ever. It's never bugged out or needed me to debug or fix or maintain it in any way either. Every app I've ever tried just works on it too, as if I was using stock android, I literally don't even notice the difference honestly. Like sometimes I even forget this isn't what my phone came with. Personally my banking app, discover, works, but I don't know if others would, although I think they probably should since it has Google Play services and the bootloader is locked once you're done installing.
- There's no Google cloud backup, it uses Seedvault instead. It was a bit of a pain setting up some apps from scratch again (those that didn't have other backup mechanisms), but if I ever reinstall or switch to another phone running GrapheneOS I can copy over the backups and presumably restore them. It also supports some remote storage providers, but I haven't bothered with those yet.
- There's no Google Digital Wellbeing, which I used to track screen time and set limits for some apps. There are some limited alternatives on F-Droid, but I just ended up using Tasker to give me reminders when I'm staring at the screen for too long.
Other than that I didn't have any problems, and really enjoy the privacy features. Especially the ability to block network access per app, and set up custom storage scopes.
> and set up custom storage scopes
There's also Contact Scopes now. We've started work on adding App Communication Scopes for controlling that within profiles and we'd like to do similar features for Camera, Microphone and Location (the standard mock location feature is not great).
It's nearly indistinguishable from stock Android. It seriously Just Works. You may have to enable sandboxed Google Play Services to get some apps but other than that it's basically perfect.
As a daily driver, it's very mature and stable. The only downside for me is just a discovery of how much of the Google apps I use and how much they improve the stock experience. The biggest example for me was the keyboard (including speech to text). Thankfully (and something I give credit to Google for as they could make this hard or impossible), you can install most or all of those apps, including the Pixel Camera app, so you don't really have to give up much.
One important thing to note with Graphene is that they prioritize security, which is a little different than many ROMs in the past. For example, they highly discourage rooting due to its security implications, whereas in the past many ROMs came with root out of the box.
2. Not for me, but this highly depends on the use case. Graphene has good, honest documentation regarding this[0]. Banking is a pain point, because to the phone, GrapheneOS is an unverified third party system. Other than this, I have never seen a single crash, and I even use the YouTube apps with the Play store that it lets you install.
You can use a Pixel Watch or Galaxy Watch paired with GrapheneOS and make payments from the Pixel Watch.
The only issue is that GrapheneOS doesn't provide a built-in way to have root privileges and if you want root on your phone securely you will have to implement that yourself or use some third-party solution (e.g. building a userdebug build, using https://github.com/chriswoope/resign-android-image, using Magisk, etc.).
If not and you use something called the Aurora Store, prepare for nightmares. Or at least that has been my experience as far as inconveniences are concerned with the Aurora Store.
The only inconveniences if you may call them that have been in alerting me of things naughty apps were doing.
Actually, no. One problem I've had is that external audio input via USB has not worked for me. Anyone else figure that out?