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.
Conversation
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
Daniel, thanks for chiming in. Appreciate the comments. Wondering what your thoughts are on this video.
1
1
It's highly misleading. It completely misrepresents the impact of exec spawning. It only slows down cold start app spawning. Please read grapheneos.org/usage#exec-spa. Not using exec spawning cripples important mitigations, substantially weakening security, and it hurts privacy a bit.
1
1
So, sure, you can avoid 100-200ms extra time for cold start app spawning by not using exec spawning. You are paying a substantial security cost to avoid it. The same goes for other features like hardened_malloc. We use hardened_malloc in a very security-focused configuration too.
2
1
What's the substantial security cost? What could go wrong in terms of security? Can someone remotely gain access to my phone? Is it a physical security cost?
1
1
Read the grapheneos.org/usage#exec-spa section.
Not using exec spawning makes code execution exploits against apps substantially easier for attackers. It makes it substantially easier for an attacker to exploit apps. It cripples a bunch of standard security features and ones we add.
1
Most local and remote code execution vulnerabilities are heap corruption vulnerabilities. Our hardened_malloc project is a counter to those, and provides important protections against them. It also doesn't slow down Java or Kotlin at all. This is the whole point of GrapheneOS.
1
4
GrapheneOS is not a branded build of AOSP with various tweaks and bundled apps. It's AOSP with substantial privacy and security improvements. Better permissions, stronger app sandbox, much stronger protections against remote / local compromise by attackers, better encryption, etc
AOSP is Android without Google apps and services included. GrapheneOS is AOSP with substantially better privacy and security via a bunch of added features improving those. You should read the information on our site. Many people seem to be quite confused about what GrapheneOS is.
1
1
What we provide isn't simply a branded build of AOSP with updates, standard Android privacy / security and without Play Services.
CalyxOS is not GrapheneOS with microG and bundled apps. It doesn't have our privacy and security improvements which is the whole point of GrapheneOS.
1
2
Show replies