Interesting, just inferring from that it sounds like GrapheneOS's actual-security features might have been tripping up PayPal's root-detection "security" features.

(Rather than something fundamentally incompatible, like them using Play Integrity)

There are valid RASP techniques that involve dynamic code loading, so it actually makes a lot of sense. Source: I worked on RASP a long time ago :)

IMO headline is very misleading, and OP should have tried disabling all exploit protection options before jumping to any conclusions. PayPal isn't actively trying to block GrapheneOS as of now.

So to use paypal you actually have to reduce the security of the phone?

In this case, it only reduces the security of the app against exploits rather than the security of the OS. Secure spawning protects the app via unique ASLR bases, random memory tags, etc. Blocking dynamic code loading prevents common accidental vulnerabilities via insecure code loading and hardens against certain exploit techniques.

As with all things about security — it depends on your threat model.

It reduces security of the app itself, but doesn't affect security of the phone by much.

Not too surprising. I usually have to reduce my browser security on the rare occasion that I access PayPal via the web.

Still works for me, too, and I haven't disabled any of Graphene's security features.

Based on user reports, there are recent updates to PayPal requiring disabling the per-app secure spawning toggle. It already required not enabling some of the other protections which are opt-in for user installed apps.

Secure spawning doesn't cause compatibility issues with non-buggy apps (unlike blocking dynamic code loading via memory/storage or native debugging) and apps rarely have issues with it (unlike memory tagging, which finds lots of bugs) so it's on by default.