> The Security Additions, Sandboxing Setup and a bit of slowness due to the hardened memory allocator are more annoying than just using plain android
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....