Tell HN: PayPal blocks GrapheneOS It seems like the PayPal app now refuses to run on GrapheneOS. I don't know if it's only because I have enabled the PayPal card for contacless NFC payments, but when opening the app it crashes with the following exception: com.paypal.oslo.app.rasp.RootDetectionSecurityException: Security policy violation: s=root |
You can help by upvoting the update they posted with the solution:
Tap-to-pay is unlikely to be provided via their website and does work on GrapheneOS.
I use latest Aurora Store PayPal version and it still works. I just dont use contactless payment.
There's some countries with very bad financial sector where your option is PayPal or Western Union as the local banks don't know how to do international transfers, Remitly doesn't support all countries and Wise also doesn't work. PayPal works, even if they charge fees.
One of the ladies at daycare is leaving? Here's a paypal link to chip in for a good-bye present.
Split a take-out order with a German friend, but he paid? Here's his paypal to send him your share.
It's just assumed that everyone has paypal over here...
It may also require dynamic code loading via storage, dynamic code loading via memory and native debugging being permitted but those aren't blocked for user installed apps by default. People can opt-in to those being enabled by default for user installed apps similarly to memory tagging, but memory tagging has the biggest positive impact.
You may also not have the update yet. Play Store supports staged rollouts where updates are only available to a set percentage of users.
You may also not have the update yet. Play Store supports staged rollouts where updates are only available to a set percentage of users.
It's because PayPal shipped an update with incorrect anti-tampering code incompatible with secure app spawning. It can be worked around with the per-app secure app spawning toggle until they fix it.
It's because PayPal shipped an update with incorrect anti-tampering code incompatible with secure app spawning. It can be worked around with the per-app secure app spawning toggle until they fix it.
Starling Bank app still works on GrapheneOS too. See here:
https://github.com/PrivSec-dev/banking-apps-compat-report/is...
PayPal's app does still work on GrapheneOS, they only accidentally broke it with the default settings due to bugs in their anti-tampering code. Disabling the per-app exploit protection compatibility mode works around it. They should fix it and start testing on GrapheneOS.
It's because PayPal shipped an update with incorrect anti-tampering code incompatible with secure app spawning. It can be worked around with the per-app secure app spawning toggle until they fix it.
It's one of the toggles changed by the per-app exploit protection compatibility mode. If an app doesn't work, that's the first thing to try. It can then be narrowed down to a specific setting.
The more aggressive exploit protections uncovering a lot of compatibility issues are only enabled for the base OS and specific user installed apps by default. Those can be set to enabled by default for all user installed apps and then people have to deal with the per-app toggles a lot more. This applies to memory tagging, disallowing dynamic code loading via memory/storage and disallowing native debugging (ptrace).
Depending on which state you are in, your experience can be vastly different.
All the states used to be kinda independent two hundred years ago. Including having different currencies. Unification happened 1871. Bismarck and later Hitler kinda brought the nation together, but after losing two world wars national pride got frowned upon and having the iron curtain cut through the country didn't help in fostering a German identity, either. Reunification was only 36 years ago. Though, about a third to maybe half of the German territory remains lost after losing the wars. Instead we got the EU. The more things change, the more they stay the same.
It's always funny to see foreigners make fun of German supposed clichés that I never had any exposure to whatsoever, like Lederhosen, which is only a thing in Southern Germany.
It was a big reality check for me usually living in Germany and having access to a lot of banks and modern neo-banks.
The whole "I pay this time you pay next time" is already covered by "everybody brings a case once in a while", but if the guys without cars just ask someone else to pay for it when it's their turn it won't add up.
If you're going to make assumptions, perhaps start with those that don't paint me in a bad light.
I know many adults who believe that splitting bills is a normal and reasonable thing to do.
[0] https://www.europeanpaymentscouncil.eu/what-we-do/sepa-direc...
One-off SEPA Direct Debit is virtually unheard of, recurring payments are a bit more common but usually involve a €0,01 payment to prove ownership of the account. The transactions are also trivial to undo, and can only be initiated by companies.
So no, "IBAN fraud" isn't a thing in practice. You can safely share your IBAN with your friends for instant free wire transfers.
But for the small person-to-person type thing, paypal is the defacto here (sadly).
If this was a long time friend, I'd let it slide. It's just a case of beer, and in Germany beer is dirt cheap. If this was a new acquaintance, I'd let it slide and take note that it's not a person to make friends with.
> If you're going to make assumptions, perhaps start with those that don't paint me in a bad light.
Good point. But all of this isn't a problem of payment systems, but of people's behaviour.
Maybe an analogy could be about using metal detectors as a layer to reduce bank robberies. A gun in a good guy's hands is a good thing to prevent robberies. Guns in a bad guy's hands are a bad thing to prevent robberies. Paypal knows you have a gun but they don't know if you're a good guy or a bad guy so it's easier to just ban guns.
Thankfully, PayPal hasn't banned GrapheneOS and their app still works on it. They accidentally broke compatibility with our secure app spawning feature which has a per-app toggle to disable it along with the other exploit protections which can cause compatibility issues.
There's an overall per-app compatibility mode toggle instead of users needing to figure out which protection is an issue but it's best to figure out the minimal workaround after determining that works.
It's similar to how people don't like sites blocking entire countries or access from Tor, etc. You might be doing it for privacy...but all the people trying to commit fraud are also using those same channels to hide their identity. The blockades are one piece of a holistic security picture that frustrate the well intentioned users.
A more apt analogy might be game developers who demand admin rights so they can install a rootkit to detect "cheating".
The needs of the user don't matter to them at all.
They have all the data they need, and they choose not to use it.
and if GrapheneOS was a root-having OS.
From a Paypal security POV, weather you use "custom Android OS" or an hugely outdated Android phone, you have:
- a similar risk for the "you" want to mess with Paypal case, in both cases the "you" can technically most likely mess with anything including the "virtual secure module" thingy android uses for NFC
- a lower risk for "others" wanting to mess with Paypal through your phone, at least if "custom Android OS" is GrapheneOS or another up-to-date android fork with decent security handling
so as far as I can tell, this inconsistency is very clearly not about PayPal's security.
IMHO it's about two other things:
1. marketing, if PayPal doesn't work on Android they lose customers, GrapheneOS for now has a tool small customer base for them to care. Outdated Android phone do have a large customer base.
2. compliance/politics BS. including potentially involving insurance. Compliance is mostly about checking of tickmarks(1) on outdated Android they can check them off and blame the user, Goodle or "hackers" for the issue. On GraphemeOS they have a harder time checking it of. Add the smaller user base and end up with PayPal doesn't care. Also iff things go wrong with Paypal on GraphemeOS in a public manner you will have all the "crime os" bad news bs, you won't have that if things go wrong with a even more risky highly outdated Android phone.
-----------------------
I got a bit to much off topic below:
(^1): Technically compliance should be about building robust, secure, law compliant systems and "showing" that by being able to pass a compliance tests consisting about a bunch of requirements. Practically there is way to many ways you can be "fully compliant" (on paper) but not secure and "very secure" but not compliant (wrt. security regulations). In the former case this might still come back and bite you iff you get sued or people suing which should get right don't get it because of ad-absurbum reasoning like "they comply with security regulations, hence can't have acted negligent". It's a shit show I don't know how to fix even if I could just magically change laws as compliance rules need technological flexibility, but if you give them that that will be abused to make insecure things pass. And the whole industry around checking that isn't really one who cares about actual security, sometimes outright corrupt (like groups which have the necessary accredited to check your compliance, are strangely more expensive then other groups, and somehow find less issues in average, with some excuse of why that isn't strange ...) :/
---
Lastly similar to how Teams or Slack could easily support FF (^2) but not only don't but outright refuse to try to even work. PayPal likes to act similar and doesn't care about niches. E.g. at least on some Mobile browsers WebAuthn works, but the PayPal website refuses to _even try_ 2FA with WebAuthn on mobile no matter if the APIs are there or not.
(^2): Yes there are some challenges, AFIK especially in certain edge cases most user might never run into. But Jitsi made it work, other smaller apps also made it work. And Jitsi is open source, so they technically can "look up" all the tricks to make it work (algorithmic ticks, not copy-pasting code) or outright just use their system with an appropriate contract (probably would be even cheaper wrt. maintenance cost then building your own system). At Slack/MS Teams scale that behavior is just messed up.
It's because PayPal shipped an update with incorrect anti-tampering code incompatible with secure app spawning. It can be worked around with the per-app secure app spawning toggle until they fix it.
The first thing to try when an app doesn't work is trying the per-app exploit protection compatibility mode. That sets all the per-app exploit protection toggles to the compatibility mode. If that works which is likely the problem, it can be narrowed down.
Nearly all Android apps are compatible with GrapheneOS. The exception are around 10% of banking and government apps which use the Play Integrity API to ban using a non-Google-approved device or OS. That's visible to users on GrapheneOS via a Play Integrity API usage notification. After the first use by an app, GrapheneOS provides a menu for blocking using the Play Integrity API which sometimes gets apps working because many don't enforce it working. It's not fully reliable and can have downtime so apps often don't enforce providing a result.
"OS that user compiled herself" can avoid this nonsense
No "smallcorp" is safe from Silicon Valley "largecorp" for long with the amounts of money SV largecorp can, and will, offer smallcorp if smallcorp grows. SillyCon Valley "largecorp" wants data about/from users, not users' money
"Safe way to make sure I'll stop being your customer - also YES!"
The user is not SV largecorp's customer
I don't think they care at all about the size of graphene os market share
if its jeopardize entire userbase then its not worth it
I'd wager that if it doesn't really hurt their bottom line to not support GrapheneOS, they won't really care.
I had to update exploit protection after their latest update — I think it was enabling dynamic code loading via both memory and storage that did the trick.
Edit: checked now, I have also disabled secure app spawning.
(Rather than something fundamentally incompatible, like them using Play Integrity)
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.
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.
Play Integrity API: Not blocked
Hardened memory allocator: Enabled
Memory tagging: Enabled
Extended virtual address space: Enabled
Secure app spawning: Enabled
Native code debugging: Allowed
WebView JIT: Disabled
Dynamic code loading via memory: Allowed
Dynamic code loading via storage: Allowed
I think this is the problem here.
A lot of NFC related tech is deeply rooted in having "trusted (aka large company)", "attested (aka you can't easily lie)", secure module functionality.
What should have happened is to just not enable the contactless payment functionality for given app, even if the user enabled it in general. And not crash.
Also as others have pointed out, this might be an accidental mishap not an intended outcome.
But it's not like PayPal is known to care about small user-base edge cases (quite the opposite). Which I guess is the actual root problem.
Version 8.107.0
com.paypal.android.p2pmobile
version 10.10.0
com.paypal.android.p2pmobile
versionCode 1160090162
Even tried completely nuking app data and logging in again. Login, security check, fingerprint setup, everything worked (I even got the alert that it used the Play Integrity API)
I assume if anything, this is probably the contactless payments. I do somewhat understand why they are really trying to lock something like this down, but as everyone pointed out, giving the green light to a CVE infested version of Android while prohibiting the use of a version that goes above and beyond when it comes to security is absurd.
What do you mean "some banks"? I thought the whole value proposition of Wero was instant bank transfers with SEPA but using phone numbers?
I've read once that there are paid app testing labs which test if an app has root and custom ROM detection and when they don't have that it's a minus point on the report.
We have per-app toggles for exploit protections known to have compatibility issues. Secure spawning wasn't expected to cause any compatibility issues so we didn't have a per-app toggle for it until recently but it's available now.
Hanlon's Razor is a useful tool. https://en.wikipedia.org/wiki/Hanlon%27s_razor
There's an overall per-app compatibility mode toggle instead of users needing to figure out which protection is an issue but it's best to figure out the minimal workaround after determining that works.
PayPal's app still works with our per-app secure spawning toggle disabled. It's a bug in their anti-tampering code.
So, best to grow the user base fast now and let every user send a complaint for every app that gets blocked. A few million users will be harder to ignore.
I also get why they'd be desperate to fight bots. It's a weak excuse for not doing it better, but at least it makes some sense.
https://arstechnica.com/gadgets/2026/08/motorolas-grapheneos...
GrapheneOS officially passes only the MEETS_BASIC_INTEGRITY tier of the Google Play Integrity API and fails the MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY levels.
Many banking apps I use in my country require this level plus something from the GPI API, which makes them unusable. You need a regular, unmodified smartphone to use them.
Have you tried the per-app exploit protection compatibility mode or the finer-grained toggles for those apps? 90% of banking apps work on GrapheneOS but MANY have problematic anti-tampering code requiring the per-app compatibility mode.
If they want to ban arbitrary operating systems, they can use attestation and it can't be fooled the way you're describing. Apps doing this can explicitly verify GrapheneOS and we've convinced some apps to do that. We've also convinced a smaller number to stop doing that at all.
But GrapheneOS isn't root, that's just PayPal's thing being broken.
Funnily enough, the only way to hide those detections was to Root my phone... And i still remember when i had an appointment there, they wanted to see something in my Bank app, i opened it (and i assume it had an update since i then last used it) and a big "THIS DEVICE IS NOT SUPPORTED. ROOT IS NOT SUPPORTED" poped up
But was as simple as readding the bank app to my root hiders.
but still, i hate this security theater
That would make a great blog post
Mistakes happen and ya can't fix what you don't know about. Always report issues.
Also strongly consider just using the website.
Several of the more aggressive exploit protections are enabled for the base OS but are opt-in for user-installed apps. Memory tagging should work with all user installed apps but is opt-in because it's so good at detecting invalid memory accesses and uncovers a lot of bugs. Dynamic code loading via storage, dynamic code loading via memory and native debugging are allowed by default since a significant fraction of apps need those and it's not usually a bug. Users can set those as enabled by default for user installed apps which is particularly recommended for memory tagging but then people need to deal with the incompatibilities. The defaults don't cause issues with most apps so not everyone is aware of the per-app toggles.
Jokes on you though, I'm neither of those things.
I've been called worse.
This is evil in itself.
Similarly, payment processors lose their appeal if they can't prevent people stealing your money, or spending stolen money on your products.
I think that's a limitation of the analogy because there is no correspondence with trusted computing. I guess it would be some sort of a magical gun that some other company is endorsing as of limited use during bank robberies? Maybe like some sort of RFID thing that disables the gun when inside a bank?
Anyway it really stretches the analogy to get tied up in technical details (risks missing the forest for the trees type error).
UK politics has been quite isolationist, though, so I doubt the banks will see much in interoperating with the rest of Europe.
As for geo fencing or blocking Tor... HAH! As if that's ever stopped anyone with the will. That is the last concern of anyone with a malicious intent. Sure, it stops irritating kids but no one beyond that.
The simple fact is that cybersecurity was in an abysmal state before the slopification began and it's infinitely worse now. Paypal is no different given that much of their support has been outsourced to slop machines. Punishing the users that know what they are doing while rewarding the ones that don't is the most counter-productive and detrimental crap anyone could come up with.
It's not about user security.
From what we see above it sounds like the change trips their rootkit detection, which they are probably interpreting as a compromised device.
It sounds like you're expecting them to have a perfect security posture that can correctly identify fraud in call cases and only block the real thing. It's more complicated than that and there's typically some type of scoring system involved with numerous triggers that are higher value indicators of potential fraud. If they think the device is compromised, that's probably a high value indicator.
This is just me speculating.
No. It's the offensive fraud vector coming from unsecured devices that account for a significant portion of the noise. Requiring device profiling aggravates this vector.
Bullshit! Source:
> The reality is that European laws are much harsher when it comes to payments and personal data protection and the security team I was being interviewed for was catastrophic
Sounds like someone who wanted to impress the audience with fluffed up claims.
It reduces security of the app itself, but doesn't affect security of the phone by much.
On the payment provider technology side, you're right, but the wallet feature uses phone numbers (and I think email addresses) so you can send each other money without sharing your IBAN (which is slightly longer and probably not in your contacts).
Just because you argue with vigor and intent, it doesn't make you right.
People are offering their opinions, try not being a dick about it.
GrapheneOS is a privacy orientated OS which is great. But if the vectors to achieve privacy are the same as used by bad actors, I'd block it too.
Get over it, don't like it? Use a different product. Or make a better one.
A financial security audit is one of the most thorough security audits you can ask for in software.
GrapheneOS gets blocked because it doesn’t follow the secure system requirements (root).
>(root)
GrapheneOS is not rooted.
They do their damndest to prevent owners from having full control of their property, over claims of 'insecurity'.
And complaints of this nature get inane drivel responses of "lol just fork Graphene"
Also, I've seen such audits internally, and they don't care about security at all. They care about the theatrics of security waaaaay more.
For example, I was at Santander in 2024, during its huge data breach. Here is the list of actions which are supposed to prevent the same kind of attacks again in the future:
-
Yeah, it's an empty list.
But of course, they made our life more difficult. In the end, I literally had more permission than before, because they were even sloppier than before. But of course, I had to change my password more frequently, and I had to type it about 5x more.
I assume the issue is it failing the deeper play integrity check which is about it not being "Google approved."
It's normal to have root (or Administrator) on your devices. After all, they are yours. They don't belong to the device manufacturer. You should have full access to your own devices by default.
Only recently did we somehow normalize the idea that the user should not be the ultimate decider over their own devices.
I propose you buy enough ingredients from the supermarket and make a big batch.
The scientific test is: how far do you get, before your door is kicked in?
If that fails, then science #2: have fun lighting it!!
You almost win both ways. (although I admit I wouldn't fund you even via a trustworthy intermediary say a Kickstarter campaign.
On a side note, if you want to be extremely specific, the line between the physical and digital threat does not exist anymore. There are two things people need to be afraid of: incompetent friends and competent enemies. Tech giants are already filled to the brim with incompetent friends, which drastically lowers the bar for the competence of their enemies.
This is a really, really poor-quality take.
> complaints of this nature get inane drivel responses of "lol just fork Graphene"
It’s a fork of AOSP, which you can just…use.
Its only since the smartphone era (2008) with locked down shit devices has this view changed. And people challenging this are somehow defective, tone policed, shamed, or likewise.
GrapheneOS users are treated as 'rooted phones', at the exact same time tools that would attack and prevent corporate surveillance (xprivacy, etc) are withheld cause they would involve root.
Even this thread is full of a lot of anti-owner hand wavey shit that amounts to 'we don't trust our users, and fork you'. https://discuss.grapheneos.org/d/18953-why-the-stigma-agains...
No, that’s called sharing your opinion.
You shared your opinion, someone else shared there’s that just so happened to be “I disagree with you” and suddenly that’s some type of censorship? Nobody is shaming you, either.
Leave the abusive relationship with those entities. Don’t lay this at the feet of the GrapheneOS Project.
If you read their FAQ, you’ll see how limited the OS actually is in retaining your privacy if you still insist on using these providers that don’t respect you.
Said another way: stop trying to solve human problems with technical means.
and definitely stop trying to get others to do it for you for free.
Or, continue: I’m not a cop.
It is a common userspace decision to lock things to userspace. It’s good hygiene.
If you want less-secure software, use AOSP or one of its many forks.
You’re not defective: you just have different needs and threat model,
and you’re harassing and degrading the public image of a project that’s opinionated in a very welcome way by folks in the security community - especially those who value stability and usability.
Also I highly doubt that there is any real statistics anywhere about whether this is a real threat or not. I guarantee that nobody did such statistics properly. The only known data is from companies which sell root prevention tools, so totally unreliable. And internally I guarantee, that no banks collect such info.
So no, banks lie about this only because they can sell this to judges as safety feature, when they fuck up, which happens continuously.
If you have a nominally unrooted phone on an old Android version and download malware, it can exploit a kernel bug and give itself root access and do whatever it wants.
Protecting against the first case and not the second is at best security theater.
They allow you to open PayPal.com on any web browser. Running Windows/macOS/Linux is basically identical to a rooted Android phone (you have local admin rights, you can modify and automate the browser, and can run unsigned code).
Apparently the world can't adult and be responsible for their actions, or people believe in that.
Yes, running in userspace for the majority of tasks is good hygiene.
Preventing the user from ever escalating beyond that layer on their own devices, however, is restricting their freedom to control their device. When that happens with tractors, cars or other gadgets that's considered anti-user. The same attitude should extend to phones.
You have complete control of the device.
You choose to lock certain things when using GrapheneOS. That’s their security model.
If you want to argue that, go study it and argue that.
If your threat model is different, if your desired security model is different, then: it’s not for you, use one of many other options.
Like all software projects, it doesn’t necessarily exist for you - or anyone specifically.
It’s not harming you for it to exist.