There are substantial security consequences to not using exec-based spawning like GrapheneOS. There's also a privacy impact. CalyxOS only has a couple of the minor privacy enhancements used by GrapheneOS. Whole point of GrapheneOS is enhancing the privacy and security of AOSP.
Conversation
Also, push notifications do work on GrapheneOS as long as apps don't have a hard dependency on FCM. If you're using FCM on CalyxOS, then you're using Google's FCM servers and the data sent via their push notifications is available to Google as it passes through their servers.
1
3
There are many apps like WhatsApp and Signal with their own push notification implementation. If FCM is present, they will use FCM instead of their own implementation. Some apps like WhatsApp require configuration to use their push notification implementation in the background.
1
2
Perhaps we should make an app to demonstrate the consequences of not using exec-based spawning. Could display the values for ASLR, stack canaries, setjmp canaries, etc. and then it's easy to show those values are shared across all apps even across profiles without the feature.
1
5
Without exec spawning, an app with no permissions installed in a secondary profile is given all of these secrets for every other app on the system including core OS components. The secrets also don't change until reboot, rather than being chosen randomly when apps are spawned.
1
3
We think providing substantially better security is worth waiting ~100-200ms for the first time an app is launched after boot. Exec spawning has no impact on runtime performance and doesn't slow down subsequent app spawns, only the first one unless it's pushed out of memory.
2
7
Similarly, we ship hardened_malloc as the default allocator along with other exploit mitigations to provide strong protections against exploitation. These have performance costs, just like the standard protections in AOSP. You could build AOSP without those to make it faster...
1
4
You could increase overall throughput by ~10% overall by disabling all the AOSP memory protections (SSP, CFI, stack canaries, ShadowCallStack, etc.). GrapheneOS takes another step in the direction of security and sacrifices another ~15% throughput for much better security.
1
2
4
Over time, AOSP has enabled many of the mitigations we used to enable ourselves. They've steadily chosen to make many of the same performance sacrifices we made in the past. Android 11 adopts several more features with a performance cost that we've had for multiple years.
1
3
So for example, AOSP has Scudo as a security-aware allocator offering some of the hardening features of hardened_malloc. It doesn't offer most of what hardened_malloc does, but they sacrificed some performance to get some of it.
1
2
They also started auto-initializing stack variables as we've done for years, which is in the ballpark of an ~2% performance cost overall for C and C++ code. Just like hardened_malloc, these things don't impact the performance of Java and Kotlin. They're already memory safe.