[baobun]

The situation you're alluding to is not a case of "GrapheneOS doesn't support banking apps" but rather "Some app publishers employ Google Play Protect and other measures in order to explicitly block GrapheneOS". GrapheneOS can not do anything about that. Choose your banking and payment apps accordingly.

FWIW I have run several banking apps on GrapheneOS without any issues whatsoever, never had any blocks or compatibility issues. Might just be luck of the draw but just to say you probably do have options.

[NoboruWataya]

Yes, I understand many banking apps do work and from reports I have read online it even seems like a couple of the banking apps I use are among the good ones. What gives me pause is how fragile the situation is. Banking apps get "upgraded" all the time to include new security "features". Already I have had my main banking app refuse to work because I had accessibility features enabled for a different app, and subsequently refuse to work again because I had developer mode enabled. If my banking app works on GrapheneOS I am convinced it is because the bank has not gotten round to blocking it yet and it's only a matter of time, unfortunately.

[warkdarrior]

If you want your bank to take the liability for any monetary losses from your account getting hacked (for example, through spyware using accessibility on Android), then you have to be OK with their requirements.

If you don't like their requirements, you need to take the liability yourself. You could use PayPal or a stablecoin to store your money.

[spaqin]

Or root with Magisk and hide the developer mode from the offending app. Unfortunately it's always a cat and mouse game, so for some apps it's probably easiest to have a cheap, outdated (and by some metrics thus unsafe) device in a drawer at home.

Your money is far more at risk with scams and phishing than it is with whatever boogeyman spyware you may try to think of that does not exist in real life.

[realusername]

Spyware using accessibility on Android still makes Play Integrity valid.

We're in this funny situation where the hacked and outdated device is considered more "secure" by Google because Google controls it

[array_key_first]

There has to be a limit here. Blocking accessibility in the name of security is piece of shit behavior. That's uh, a technical term.

Banks have plenty of money. They don't need to be up your ass to keep liability down.

[Dylan16807]

> GrapheneOS can not do anything about that.

OEM support is a step toward passing integrity, and that's what those apps are looking for.

[charcircuit]

>GrapheneOS can not do anything about that

They can fund the development and support work for attesting GrapheneOS along with funding support for compatibility with the os. The more users that GrapheneOS has the less money they'll need to pay to fund such a project.

[jameshilliard]

> Google Play Protect

Play Protect really is the root of all evil, Google certainly seems to be incentivized to write services like Play Protect that effectively act like malware/spyware in order to force users to see more ads by making it as difficult as possible to run effective system wide ad-blockers on mobile devices by crippling the ability of users to run non-Google sanctioned code on their devices at high enough privilege levels. They've deliberately designed Play Protect for maximum user hostility instead of trying to come up with ways to provide security while maintaining user freedom. For example they could have instead implemented much stronger sand-boxing of apps so that apps would have as little knowledge as possible regarding what type of environment they are running in, similar to webapps, yet they chose the exact opposite approach and went out of their to prevent users from restricting app permissions/system visibility deliberately.

Additionally the sideload blocking plan they published seems to be effectively Google deliberately using installation whitelisting in order to prevent users from removing ads from apps with tools like revanced(revanced is an APK patcher and relies on the ability to effectively self sign/install APK's without googles approval if running on bootloader locked devices).

These elaborate user hostile schemes of theirs even uses similar dubious technical justifications as manifest V3's ad-block crippling did for Chrome.

> GrapheneOS can not do anything about that.

I mean, they could help write exploits to help users bypass the Play Protect malware/spyware I suppose, although that probably doesn't align with their goals. I'm really not sure what other practical options there are in regards to fighting these malicious spyware services that Google wants to force on everyone.

Since Google doesn't have effective full control over the Android hardware supply chain like Apple does undermining the Play Protect spyware scheme should be much easier as one probably just needs to come up with some key extraction attacks against certified Android devices with terrible hardware security(lot of cheap Chinese SoC's used in Android phones that have rather poor cryptographic key protections). In theory one can then use extracted attestation keys to emulate a secure boot chain in software on other devices along with sufficient sandboxing to trick Play Protect into thinking it's running on a Google sanctioned bootloader locked device even when running with a custom OS.

[gradeless]

>GrapheneOS can not do anything about that.

GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids

[jameshilliard]

> GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids

The issue is more that GrapheneOS still allows apps to view OS attestation information[0], which is similar how Play Integrity API attempts to prevent you from running on your own OS. The specific feature I'm referring to which is the problem is the Play Protect API which allows apps to inspect the host system bootloader/TPM state essentially. The problems with giving any apps(even webapps) access to this sort of attestation information are well documented[1] as it encourages app developers to lock out legitimate users who want to run unofficial operating systems. Effectively breaking this app verification capability is what is needed to prevent app developers from enforcing arbitrary security requirements on the host OS. Essentially GrapheneOS just wants app developers to trust their keys in the same way Google wants you to trust theirs(using the Play Integrity API).

[0] https://grapheneos.org/articles/attestation-compatibility-gu...

[1] https://en.wikipedia.org/wiki/Web_Environment_Integrity#Rece...