[NoboruWataya]

Anyone know if partnering with a major OEM for official support makes it more likely that they will be able to consistently support things like banking apps (and maybe even payment apps) in the future?

I suspect the answer is "no" but I want to believe...

[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...

[xethos]

I sincerely doubt it, but a large OEM with first-party support makes it (IMO) more likely for banking apps to support GApps-less handsets(instead of the inverse, Graphene supporting banking apps) - a dramatically better outcome, as that allows Waydroid more breathing room as a viable solution for Linux-first handsets too.

This would of course be contigent on GrapheneOS growing their market- and mind-share in the general public, while also taking several years to impact the least move-fast-and-break-things industry (consumer banking).

But still, a man can dream.

[zb3]

If those apps use "Play Integrity" (bad choice) then the probability is close to zero because it's Google that controls it. Other OEMs that currently pass it do it only because the device was certified by Google.

But being certified by Google of course precludes not preinstalling or sandboxing their GMS apps.

[IlikeKitties]

The answer is it depends. Banking and similar Apps trying to "protect" the user from themselves aka treat the user like a retarded child do this through several mechanisms:

> Google Play Integrity

Essentially a Google API that App Developers integrate that checks if the device runs an Operating System signed by Google as "Play Certified". This can go as far as being backed by a hardware trusted platform module. I doubt Google will certify GrapheneOS given their modifications towards sandboxing the play services. This can be faked to a degree but GrapheneOS choses not to do it and to fake the TPM part you need leaked keys. For more details on how to fake it look at this thread: https://xdaforums.com/t/guide-how-to-pass-strong-integrity-o...

> Fingerprinting the Device OS

This can very from app to app and just tries to fingerprint the device in many ways to see if it's running a custom rom of some kind. This does things like check to see if the bootloader is unlocked or if root is installed. I think this is something an official grapheneos phone might fix since the phone vendor could allow grapheneos to sign their releases as native equivalent

> Banning GrapheneOS by Name

Some Apps Developers literally ban GrapheneOS by name.

> Failures due to Google Play Sandboxing

Since GrapheneOS sandboxes Google Play Services there might be compatibility issues that prevent the app from working right. This would likely be unaffected by a GrapheneOS Phone.

> Failures due to Advanced Security Features

Some Apps just don't "like" the advanced security features like the hardened malloc and other protections and just fail. This can be disabled most of the time

[esseph]

If the phone is rooted, most banks will not support it. That includes grapheneOS.

[MaximilianEmel]

Your phone isn't rooted on GrapheneOS.

[hardran3]

GOS isn't rooted.

[esseph]

Apologies meant bootloader unlocked

[akimbostrawman]

Relocking bootloader is part of installing GOS

[esseph]

Cool, I didn't know that!