Currently, besides if you use cryptocurrencies, I don't think you can rely solely on "written regulations and systems of checks", somewhere along those processes there are a bunch of humans with their altruism (or lack of), taste and daily life moving those processes along. And judging by the state of the cryptocurrency ecosystem, this is probably a good thing more than a bad thing.
Lmao, it's never legislation and/or enforcement. It's the checkboxes that their insurances told them they had to check or they wouldn't be covered. Half of the problem goes back to insurances being thieves who would do anything to not pay up, the other half goes to upper management not giving a shit about people.
Yep. I used to work for an FQHC, and the only thing that improved our network security was the insurance premiums we'd incur without proving compliance. Ofc course, HIPAA is a thing, but that was simply the baseline.
After that guy was arrested for wiping his GrapheneOS phone with a duress password, some reports appeared of previously usable apps becoming unusable specifically on GrapheneOS. This now reads like a possible reversal of that trend.
We're not aware of any apps banning GrapheneOS because of that. Play Integrity API adoption has been ongoing for a while. The device and strong integrity levels don't specifically ban using GrapheneOS but rather any non-Google-certified OS. Google certification isn't available to GrapheneOS.
Where is this list of 12+ banks that explicitly allow graphene. My understanding is if the banks do not explicitly state support also in terms of ToS, they might pull the rug any moment. With neo banks you are then basically left without a bank.
I found some evidence of half a dozen that there might be support 'by desogn' (all of them might pull the rug at any time again as far as I understand TOS, which however seems true for any android in theory): Swissquote, Yuh, UBS, Starling Bank, Triodos Bankieren NL, AmeriCU Credit Union. More?
Banking app compatibility has greatly improved, mainly due to GrapheneOS working around bugs in the apps and adding per-app opt-out for exploit protections known to cause incompatibilities. Around a dozen banking apps have explicitly permitted using GrapheneOS in one way or another. Some removed or changed checks they had to begin permitting it. Other apps began verifying it and potentially other operating systems via Android hardware attestation as an alternative to the Play Integrity API.
There are around 6-8 banking companies which have made changes to explicitly permit GrapheneOS that we're aware of and several have multiple apps which add up to around a dozen apps. There are likely other apps which have made changes to support it without us being aware. Compatibility has improved a lot and we can't attribute that all to any one particular change.
Complain to other hardware vendors that they sell insecure crap or do not release updates :/
And yeah, it'll be Motorola from the next year on, but a proper, first party cooperation. I think that Motorola wants to become the answer to the question: "what's the best, safest android smartphone?"
In my experience with UK banks & financial institutions, GrapheneOS support can be roughly divided into four types.
None. Explicitly banned. And, though I feel bad for saying it, I can't blame them. If some idiot roots their phone and downloads malware, the bank may be responsible for refunding them. I can see why they don't want that headache.
Some. App works, but some functionality is unavailable. I've got a credit card app which works, but refuses to set up virtual cards or use "remember me". That's good enough for my use. Similarly, I had a merchant account which let me see my balance, but I couldn't use my phone as a credit card reader.
Works, but only in main profile. I'd rather keep financial things in a locked profile. But lots of banks disallow that.
Full. Everything works (although you may need to toggle some exploit protection off).
Some banks are reasonably good at letting you pass on technical queries to their developers - mostly the smaller ones. The nice thing about the UK banking sector is that it is trivial to move banks. So I switched accounts to providers which worked with my phone and let the old ones know why I was moving.
> The nice thing about the UK banking sector is that it is trivial to move banks.
Are there countries where this is a hassle? Now I've only had personal banking accounts in ~3 countries (so far?), so maybe I'm in a bubble, but in none of the countries has "switching banks" been more than basically create a new account, start using new IBAN for incoming transfers, move direct debits to use new IBAN and start using new card(s). Those last two were even automatic in the last move I did for a lot of stuff. Is it typically more difficult than that in other countries?
Having the debits move to the new IBAN automatically had to be mandated and built. It doesn't just happen. In markets with large incumbent banks they have no incentive whatsoever to make switching easy.
Having to change IBAN is a hassle, and shouldn't have been necessary. In fact, I think some countries (Germany?) actually got that right, and allow you to take your IBAN with you when switching banks. Like keeping your phone number when switching telco.
Why is that so much of a hassle? In the US switching banks is just updating some numbers and reconnecting. The entire process can just be done online. In the US the only annoying part can be older companies that still do the account verification via a deposit and withdrawal, so it takes one whole day instead.
Also I don't think I would actually want it done automatically. Some banks have better saving rates, some banks offer higher interest on checking, some banks are much better for taking cash out internationally, some banks have more ATMs/branches around where I live, etc. I have a few different banks I move money around in.
Because there are about two dozen companies that do direct debits from that account. Some of them may be automatically informed of the change, but for most I'd have to figure out how to update my payment info. Similarly, friends and family might hold on to account numbers to send money back and forth. (Though that's probably less of a thing now, with all those apps for sharing convenient payment requests.)
It automatically moves all of your Direct Debits, recurring payments, balance etc. It even redirects incoming payments to your old account to your new one.
> None. Explicitly banned. ... I can't blame them. If some idiot roots their phone and downloads malware, the bank may be responsible for refunding them. I can see why they don't want that headache.
I mean this is the whole reason GrapheneOS does not ship a rooted version that they attest to. I doubt they are explicitly banning GrapheneOS, what they are doing is only trusting Google attestation.
The reason some banks explicitly allow GrapheneOS is because its easy for them to also trust GrapheneOS attestation, because it is not a rooted OS, and sensible security teams in banks can see that its more secure than any other Android phone including Pixels.
I wish people would understand this better, its what gives GrapheneOS a fighting chance of becoming a legitimate open source mobile OS that is accepted as secure for consumer use and that is not controlled by Apple or Google.
That's not the whole reason, or even the main reason GrapheneOS doesn't support or encourage root access.
The central design theme of GrapheneOS is to have stronger sandboxes and more limits on what apps can access than stock Android does. Granting an app root access does exactly the opposite; someone behaving rationally and consistently usually won't want to do both on the same device.
Providing root access to a huge portion of the OS with a way for apps to obtain it goes against the privacy and security focus. It's never a reasonable way to implement the features provided by those kinds of apps. It's an insecure shortcut being taken to implement features poorly and insecurely without proper integration. Providing root access to end users is a much different thing than giving it to a huge portion of the OS with a way for apps to request it.
We wouldn't mind providing a 2nd set of releases with user root access but those would have separate signing keys for privacy and security reasons. It would not be accessible to large portions of the OS to apps. We don't do it because it would double the number of builds and would be a massive amount of additional work for managing and testing it. It would take immense resources to create a variant of the OS which we'd recommend against almost anyone using mainly to provide a novelty. We have much better uses for our resources. Resources are always limited and doubling the number of OS releases for a 2nd time would have a huge cost.
Without evidence that using an OS that isn't approved by Google or Apple actually correlates with a higher rate of account compromise or fraud, I do blame them for trying to force it on users.
I've done a couple casual web searches for such evidence and come up short. If somebody has good data on this, I don't think they're publishing it.
I'm pretty sure it's actually anti correlated: not because degoogled Androids are safer by themselves, but because the average user is way savier than the average Joe (which have an out of date Android full of unpatched security vulnerabilities, in the first place).
My theory is that they're trying to counter simulated phones. In the old days fraudsters would use their stolen credentials on a windows RDP rented from someone who sells fraud infra with clean IPs. I wouldn't be surprised if fraudsters have tried to develop an android based VM meant to look like a legitimate customer endpoint.
Though the most effective way to cut out that kind of fraud is to stop using SMS for authentication, which banks don't seem to be interested in doing.
That's my first instinct too. I've seen a claim that devices with root, which is distinct from degoogled, both of which are distinct from using a third-party Android distribution, have an increased probability of malware. I suspect that statistic includes things like secondary devices people use for cheating in pay-to-win games and the like.
It would be interesting to see statistics comparing who
1. Byod (just gets a SIM card from the carrier)
2. Keeps updating their phone to whatever the carrier offers via billing credits
3. Just keeps using the same phone they got from the carrier when they started
Since that’s “likely” correlated (and a “likely” is often enough), a product manager will take the most optimal decision for themselves and the company - reject such use cases as unsupported. This is easier than to manage such an edge case for “a few” legitimate users.
Few orgs understand compliance. While there might be some compliance people at the org level, individual teams implementing features will need to have a good line to them. In the end, knowledge is siloed and everyone needs to deliver on time. So it’s easier to forbid with some controlled collateral damage than to permit with an uncontrolled downside variance. Just a derisking hedge.
Serving use cases that drift away a bit “too far away” from the average (+ some sigmas) use case is not economically justified for a product manager - their KPIs would deteriorate from such “altruism”. No one will care if a few low-margin customers can’t use the product.
Their main concern is malware not capable of exploiting OS vulnerabilities. They focus on protecting against malicious clones or modifications of their apps along with enforcing having a mandatory app sandbox and not running non-approved accessibility services, non-approved keyboards, etc.
Most of the banks don't require not being months or years behind on bare minimum Android security patches let alone requiring anything close to proper security patches. That may rapidly change in the near future due to AI accelerated exploit development making exploits far more accessible and broadly deployed.
Nearly all these apps aren't banning GrapheneOS on purpose but rather because they're doing the least possible work to implement weak anti-tampering measures. Play Integrity device or strong integrity levels are an easy way to do it. They can use strong integrity if they're willing to forbid extraordinarily insecure devices failing to meet a very low bar for security. Most banks aren't willing to do that since it would mean blocking the majority of Android devices so they use device integrity which barely does anything more than enforcing licensing Google Mobile Services to reinforce Google's monopolies. Even the strong integrity level doesn't enforce much more than that, it's mostly just much harder to bypass at scale.
I have two to add: Works, but only every other app version. Second: works if the aosp keyboard or gboard are active but not with LeanType. Easy fix once you know, but that was not a fun time debugging.
> though I feel bad for saying it, I can't blame them. If some idiot roots their phone and downloads malware, the bank may be responsible for refunding them. I can see why they don't want that headache.
Most of us understand the desire to protect customers from fraud, but I don't think we should accept blanket restrictions on everyone's freedom simply because some people might make poor security decisions.
There's also the unspoken/uncomfortable economic reality here: the optimal level of fraud isn't zero. At some point, the cost of preventing additional fraud, including the loss of individual choice and autonomy, exceeds the benefit.
Could we aim for proportionate, evidence-based security rather than treating the least capable user as the benchmark for everyone?
The scope is much smaller than that: restriction on what banking conveniences are provided.
> Most of us understand the desire to protect customers from fraud
> At some point, the cost of preventing additional fraud, including the loss of individual choice and autonomy, exceeds the benefit
> Could we aim for proportionate
I think you have answered your own question here; if a less than single percentage of retail customers use something that's not a general iOS or Android device, anything beyond that is not really worth it until regulation says otherwise.
> The scope is much smaller than that: restriction on what banking conveniences are provided.
The freedom to install whatever OS you like on your own phone?
> if a less than single percentage of __________ anything beyond that is not really worth it
My goodness one could fill in that blank in so many different ways, and all of the ones I can immediately think of would drag this thread straight into any number of dire arguments, so I'd better not.
This is about the bank. You get a service from the bank. The bank has to make a trade-off which services they want to provide under which conditions.
Somewhere, 100 steps later, you might get to a "which OS on which hardware" aspect, but that's so far removed from normal life for the meaningful customer base that unless you want to stretch the scope of the post two orders of magnitude bigger than it is, it's not even close.
The bank makes a tradeoff, usually based on money: if they lose 5 customers because they can't use a specific app on a specific OS on a specific piece of hardware, they aren't going to care.
You can apply that to most businesses, especially the profitable ones. You shouldn't be surprised by that.
Would anyone know why? My understanding of profiles is arguably very limited, but I always saw those as equivalent to device owner profile from app runtime standpoint.
I’m not very familiar with android because I don’t daily it, but I have an old Pixel 4 with GOS that I was using to evaluate GOS. I know for example that some MDMs don’t work on a secondary “Work” profile in GOS, despite it being one of the main use cases for secondary profiles. If I recall correctly, it was because of how some MDMs can be configured by the organization’s admin they require some handshake with the Owner profile that doesn’t work in GOS. you would have to install them on the owner profile defeating the point I think,
Certain MDM apps support using the Play Integrity API to ban using non-Google-certified devices. Some MDM apps simply don't know how to successfully create a functional work profile without Google Play being automatically installed in it which can be worked around and we can provide an easier way to deal with it. Work devices should really be separate devices provided by the company instead of them managing a work profile on your personal device though.
It's worth noting AOSP and GrapheneOS have both drastically changed since Android 13 on the Pixel 4. GrapheneOS is based on Android 17 since June 2026 and soon Android 17 QPR2 in December 2026.
I don't get why people accept that kind of intrusion into their own device commonly known as BYOD. If a smartphone is necessary to carry out work duties, let the employer provide one.
Thank you. That’s totally fair. I know I’m using an unsupported old device and that it’s better to have a separate work managed device. I just hate the idea of carrying 2 phones and was hoping there is a way I could still use GrapheneOS while containing what MDM can do. Though I realize MDM’s whole point is control of the device, so perhaps what I’m looking for is a logical contradiction.
I can't think of a legitimate reason to check this and refuse to run in a secondary profile. But banking apps sure love to cargo-cult invasive nonsense.
> ”If some idiot roots their phone and downloads malware, the bank may be responsible for refunding them.”
This obviously depends on jurisdiction, but how commonly is this actually the case?
I’ve thankfully never personally been on the receiving end of fraud or identity theft, but my impression is that here, everything that happens up until the point you tell your bank ”hey, uh, I think my account’s been compromised” is pretty much on you. I don’t think rooting your phone, installing a banking app from some umauthorized source et.c would be hard to construe as negligence.
I don't know anything about the actual legal responsibilities, but even there aren't any, a defrauded customer takes up support resources just having the conversation about it. Upset customers (regardless of how well placed that upset is) will complain about it in reviews etc.
A lot of people aren't able to distinguish "I got scammed" from "the bank took my money away".
In the UK, the bank is liable for any transactions on your account that you didn't approve. Doesn't matter that they thought you approved it because someone knew your pin, or compromised your device.
Unless the bank has reason to believe that you're either trying to defraud the bank, or where unduly careless with your banking credentials (and you have to be really careless to meet that bar in the eyes of the regulator and the courts), then they're expected to refund you.
I've seen banks refund £100ks to customers that were defrauded over many months via romance scams. There are cases ruling by the Financial Ombudsman forcing banks to refund customers to handed over their cards and PINs to carers that then stole money.
The general attitude of the law in the UK, the regulators, and the courts, is basically it's the banks responsibility to provide appropriate security, in a form that their customers can easily use and understand. If banks want to make it easy for customers to move and spend money, then the risks associated with that convenience accrue with the bank, not their customers.
Obviously banks work very hard to worm their way out of their responsibilities here. But if you use the consumer protection tools that exist in the UK, which are very easy to access, and which your bank is required to inform you of, then it's surprisingly easy to force a bank to refund you for any fraud you suffer.
> In the UK, the bank is liable for any transactions on your account that you didn't approve.
The question isn't whether they have to refund the money when the customer gets defrauded. The question is whether preventing the customer from using a less popular OS in any way prevents them from being defrauded.
To which the answer is somewhere between "negligible difference" and "it's actually anti-correlated with that because the custom ROM is more up to date".
Question: In the UK, thanks open banking, couldn't you use a compatible bank like monzo and load all the other bank accounts via open banking into that single app?
>If some idiot roots their phone and downloads malware, the bank may be responsible for refunding them.
I keep reading this justification, and it doesn't make an ounce of sense to me.
first of all, the number of people who want to root their phones is a fraction of 1%. children, teenage girls, and senile boomers don't do that. the number of people with rooted phones who could fall for "hello sir, I am sir John Whiteman from Microsoft, you're phone have virus, sir, please do the needful install this a pee kaa, sir" is near zero.
second of all, phones get stolen all the time, and it would make sense to reduce liability by not providing apps at all.
> people who want to root their phones is a fraction of 1%. children, teenage girls
If someone lies to them and tells them there is an app that lets them get free Roblox bucks or whatever, but first they have to root their phone, they will. If someone lies or makes an app that removes pimples or adds makeup in realtime, or something, but they make it only work on rooted phones, they will.
I did a rough estimate of all the people I know and the number of those people who would want to root their phone. It’s not a big number but it’s way bigger than “a fraction of 1%”.
And it’s a completely different demographic than those would would fall for the phone call scam, but it’s incredibly disingenuous of you to suggest that the only malware distribution vector is being tricked into installing an APK.
I know people who are interested in modding games, pirating software, and installing “cool” apps just for the novelty. I would argue the most likely reason those people installed malware is voluntarily, because they searched out a hacked version of Bloons Tower Defence. Not because they “needed to pay an outstanding Windows service bill”.
If the banks were really so concerned about malware on the user's endpoint, and they had competent CTO, then they would write an app for Trezor or offer a Trezor with their own logo and app on it and users could sign transactions with it.
Trezors show on a screen to the user "this is the amount and where to be sent that you are signing for".
Malware with high privileges on a compromised user endpoint can bamboozle the user but a hardware wallet would catch that.
You are suggesting an entirely second piece of hardware when there are people in this thread claiming (IMO correctly) that many customers prefer an app over the browser because it's very mildly more convenient.
And there is a very large swath of banking customers who I wouldn't be surprised to learn that banks will earn less than $130 from over the course of a decade.
Correct, an enTiReLy second piece of hardware. That's the whole point of a hardware wallet.
The use can be optional, I don't think anyone would suggest (or even presume?) otherwise.
Accounts with balance under $30,000 need not apply.
Many of the "good customers" (from a bank's perspective) already have a Trezor.
Big banks already require customers pay the $50 for an RSA fob anyway. No bank is providing these devices as a courtesy.
Many GrapheneOS users would rather pay out of their own pocket for a Trezor Safe 5 than have "you need to carry an additional phone too, a shit-phone" forced on them when GrapheneOS is perfectly adequate to run any app and with more meaningful security assurances than any other Android distro.
I don't know where you live or with whom you bank, but there were plenty of hardware tokens for banking for almost two decades until phone apps took over. They are not likely to return. Managing many hardware tokens is a big undertaking and people regularly forget them or destroy them. Phones are so much easier and people generally don't want to carry extra devices. They don't even want to carry comparably tiny credit cards given the choice.
No no, we don't want tokens. We don't want that at all.
In the United States, users of Chase are already using FIDO2, which has the same cryptography-grounded effects I suggested above. The legacy tokens never had this kind of functionality, and from a security perspective are as crummy and vulnerable to MITM as OTP/TOTP.
As far as holding onto hardware keys, users don't lose hardware keys/wallets when those are attached to a keychain and the users are instructed to attach to add it to their general car/house keys. Attached to general car/house keys/fobs, hardware keys survive user-chaos at a much better rate than smartphones do. Other security-focused IT pros/execs have reported the same.
The key difference between those hardware tokens and hardware keys/wallets that do OpenPGP, or PIV, or the underlying cryptograpy functionality of "Bitcoin wallet", is they
1.] generate a cryptographic signature for the actual content ie "this much $xx.xx to meloney@example2.com" that the bank can keep and present later as reliable proof if appropriate
and
2.] display on the screen the contents for #1, so a compromised user endpoint (smartphone or laptop) displaying false info is less likely to successfully bamboozle a user.
Then it's not GrapheneOS and your bank won't recognise it as GrapheneOS, it will recognise it as some emulator pretending to be GOS and will refuse to let you log in.
GrapheneOS doesn't have app accessible root and has it limited to a tiny set of processes where it's still largely contained via SELinux. Debug builds of GrapheneOS have root for Android Debug Bridge (ADB) and it doesn't limit how people can modify it. We don't recommend using a debug build on a production device and people should at least set ro.adb.secure=1 if they do.
GrapheneOS is an open source project and people can make their own builds with arbitrary modifications. We recommend not adding a third party system giving root access to a large portion of the OS and making it possible to grant to apps with a dialog since it greatly reduces security if it isn't used. People can do what they want regardless of our recommendations.
Modifying GrapheneOS in any way creates a new OS which is no longer GrapheneOS itself. Forks of GrapheneOS must come up with their own name and branding if they're going to distribute their modifications. We don't want software which isn't GrapheneOS being confused with it.
> And, though I feel bad for saying it, I can't blame them. If some idiot roots their phone and downloads malware, the bank may be responsible for refunding them. I can see why they don't want that headache.
This argument has never held any water for a simple reason:
Consider 2 phones.
1. Runs self-built lineageos (latest version), with magisk installed.
2. Runs official stock ROM, no mods, all apps from Play Store. Also, hasn't gotten any updates in 6-9 months and is running a 4.4.x kernel that isn't even the latest version on its branch.
If your app blocks phone 1 and allows phone 2, then you're doing security theater in a way that actively undermines actual security. The ability for a user to flash an OS or allow apps root access doesn't make a device insecure, but the ability for any app to grant itself root because the vendor can't be bothered to patch the OS certainly does.
Not necessarily, it depends on how they fixed it. It isn't up to us. Some of these apps began supporting it by fixing their own anti-tampering code to stop being incompatible with our exploit protections to avoid needing users to opt-out for the app.
Some were using the Play Integrity API and stopped doing it.
Others were using the Play Integrity API and implemented the Android key attestation API as an alternative which means only a list of operating systems and hardware they choose to permit will work in addition to Google certified devices with the stock OS via the Play Integrity API.
Thanks. It's unfortunate that some of them decide to use the key attestation API. I guess that's one of its intended purposes, but not where I'd personally like to see it. Just a little salty that certain things like rooting will be forever out of reach on GrapheneOS for users of those apps, because you will never be able to do that with the official signing keys.
We try to convince them not to do it at all, but if they insist on doing it then we point them to our signed list of verified boot key fingerprints and Google's library for key attestation verification. We have a page with a guide on allowing GrapheneOS this way for apps using the Play Integrity API. We keep a list of a small subset of apps using the Play Integrity API to ban GrapheneOS there for users to pressure them to allow GrapheneOS too. We definitely don't encourage adopting it for apps not using the Play Integrity API already but rather it's a compromise to get support for the official releases of GrapheneOS and other operating systems with verified boot and the app sandbox intact for apps otherwise banning them.
Of course, it's better for apps that insist on attestation to at least support the official GrapheneOS rather than none of it. I can definitely understand making that an option as that's certainly better for your users.
Good. I am tired of vendor-lock-in of a few corporations
dominating the world here. Capitalism was never
corporate-fascism - after all one element is free competition
in a free market. This has been broken numerous times again
and again, and the US justice department is deliberately
unwilling to remedy this situation - thus also betraying
the idea behind capitalism. No wonder since the orange
mafia is running the show right now, with all signs of
real dementia now being obvious.
Capitalism was never the same as free-market. In a free market there's competition, but in capital-ism it's all centralised at a few people, the ones who have all the capital.
You singlehandedly created the synapse connection I needed to understand why people hate capitalism. I've defended it so many times and now realize what I was actually trying to defend was the free market and me and the arguer were talking past each other.
I wonder how many of these supported apps are supported, because there are some geeks on the inside of the banks who want to have their favorite mobile OS supported.
You might be overthinking it. Most people want to use their phone for convenience, and if an app allows them to remove just one step in their banking activities, they'll probably do that.
As for the second part (separate authentication methods), sure, would be rather problematic if they require you to have a phone, but that's a completely separate and different issue.
Companies tend not to do illegal things when they're likely to get caught.
The trouble with data laws is that once they have your data, they're the only ones who actually know what they're doing with it. Which means the thing you need to prevent is them having it, which is typically not the thing those laws do.
Watch what comes out about Samsung TVs in Europe in the next few days.. the companies do mountains of illegal things because everything devices send/receive is encrypted now and they thought they'd never get caught. After a couple of firmware updates and CA certificate fixes for the eMudhra vulnerability, people will forget all about it and they will go back to doing it.
On GrapheneOS you can install your bank app in a different user profile, and run Google Play sandboxed, so this scenario of a bank app doesn't result in anyone have access to your other information.
Android apps are isolated by default. Graphene can do a bit more, but overall Google Play store doesn't get access to your app data. So what I meant is that your banking data is as safe from the store in the app as it is in the browser.
Note that the user profiles aren't the basis of sandboxing. The bank app is still sandboxed, and GPlay as well if you only use a single profile. Profiles have use cases of course, they offer separate app data, user data and VPN configurations. They also have a separate list of apps marked as installed, a list apps can see in a profile. IPC also can't take place cross profile, which is useful to prevent communication between apps based on mutual consent. Also nice is that they offer separate encryption keys and can be put at rest manually. In the past they also had the advantage of having a separate clipboard but this isn't an advantage anymore given that GrapheneOS recently shipped within-profile clipboard control.
If you dont need any of the above its perfectly fine to run the banking app on your single, main profile.
> As for the second part (separate authentication methods), sure, would be rather problematic if they require you to have a phone, but that's a completely separate and different issue.
It's getting somewhat annoying nowadays with banks pushing that crap, but fortunately legislation for access of people with disabilites forces them to provide tokens still.
A lot of them now switched to banking apps on the phone acting as token without a chance to opt out, though, so as a result I've stopped doing anything bank related on phones nowadays.
HSBC pressure you into using the app and I don't think there is a way back to the battery powered OTP device. At least not that I know in the UK. I resisted until the battery failed and they basically make you go into the branch and then plead why you can't use a smartphone. got sick of this dance after 3 years
Most of those devices are interchangeable, so if you have one from NatWest, Barclays etc it will probably work with your card. It's also possible to replaec the battery on most of them.
I got a replacement widget recently, the website pushes the app but when I asked in branch they gave me one without even asking my name. I had to wait on the phone to register the new serial number, maybe I could've done that in person too, but it lasted years (and multiple phones) so I don't mind too much
That their app wouldn't run on my phone "wasn't a valid reason" to not use it, they said. Luckily, it is a charitable/community account and an organisational rule prohibiting officers from having bank apps on their personal phones was accepted - for now.
Indeed they did. I had to go to a branch to get a new security device, mine having run out of battery. This involved speaking to their customer support on the phone anyway, and they told me that. Telling them that the organisation (a local sports club using a charity account) had that policy caused them to back down, though they hinted that they wouldn't do so in future. As you might guess, I created the policy once they gave me the "not a valid excuse" line (I run the club).
Their agent seemed very confused by my assertion that the app would not run, because it runs on Android and iOS (they claimed) and they presumably thought that those are the only smartphones which exist.
In my case, the app offers functionality that isn't available on the web version. So I resentfully use the app, but I'd prefer all features were available via the web instead.
Web banking means you need the card reader gadget as well for the authentication. The app uses secure features of the OS to aid authentication so you don't need to read the card. Web access on your phone still needs the card reader gadget.
Modern cards and phones support NFC, so you would only need a "gadget" (NFC reader) when using a PC that doesn't already have one, and a USB one is ~$20.
What this really needs is better browser support for NFC:
The way chip cards work is that a challenge is issued to the card and it sends back a response. The challenge is just a random number that makes it so you can't replay a previous response to a future challenge. The bank can then verify that the response came from the card, i.e. that you have the card right now.
Your computer doesn't need to have any keys to do this. The card has a secret key, but it doesn't give it to the reader, it just responds to the challenge. The challenge often comes from a point of sale terminal, but it could just as easily come from the bank's web servers, and it isn't really a secret.
The only thing which resembles a secret here is the response from the card, which is the thing anyone can get regardless when have the card. Also, the entire premise of the card is that the attacker doesn't have it, so if they do then you've already lost.
It's not the NFC the bank is interested it, it the MFA provided by your phone PIN, fingerprint or face unlock.
When you open the app on your phone, the phone probably needed to be unlocked first, though not everyone sets a PIN or biometric lock on their phone.
Then you will be prompted for a separate PIN or your fingerprint within the banking app. This provides a stronger signal to the bank that you are the legitimate account holder. If your phone is lost or stolen, the chances of someone else being able to authenticate to your banking app are considerably reduced.
With the web app, people will often save their bank website login credentials in the browser. So now someone nefarious only needs to access the unlocked computer or phone the go to the bank's website to gain unauthorised by still authenticated access to the customer's accounts.
Yes, there are now laptops and tablets with biometric authentication, so the potential is there for adding biometric authentication for banking website. However, when you look at the demographics of banking app vs website use, a strong majority of Millennials and Gen-Z do all their banking via the phone app. Gen-X also slightly favour the phone app whereas Boomers strongly prefer the website. So banks focus their development efforts where the majority of users are.
> When you open the app on your phone, the phone probably needed to be unlocked first, though not everyone sets a PIN or biometric lock on their phone.
The same is true for PCs. They've supported that sort of thing for decades, and it's optional for both the phone and the PC.
On top of that, a phone that people carry around everywhere is dramatically more likely to be lost or stolen than a desktop PC that never leaves their house.
> With the web app, people will often save their bank website login credentials in the browser.
If the bank actually cares about this then there are various ways to disable or impede it.
> However, when you look at the demographics of banking app vs website use
This is just the thing where you make something worse so fewer people use it and then use that as an excuse to keep making it worse. Nobody needs an app that could have been a web page, people use them because it's what get shoved down their throat if they don't go out of their way to do something else.
Depends on where in the world you are, Norway for instance has not been using card chips for 2fa consumer auth for banking. Instead the 2fa has been a separate code generating gadget, and now also alternatively an app (which I do get the feeling the company that the banks set up handle auth for all of them are kinda pushing everyone into, but for now there thankfully is an option where you only need 1 online device with nothing more than a functioning browser).
meanwhile in my case the app offers functionality that isn't available on the web version while simultaneously requiring the web version for some of the things
How often do you think companies are in the habit of doing things for your convenience?
Not who you replied to, but requiring me to install your app or create an account is usually going to mean I skip your thing unless I'm really motivated to use it.
I daily drive an app inside of an advertisement inside of a mini app inside of an everything app. Its terrible but there is no escape… unless you quit ordering coffee (which I just did)
I use a terrible investment platform that purposefully nerfs the web app so you are forced to use the mobile app.
For something like a bank, I think they ought to be mandated to offer a functional website, yes. A slick app is nice too, but not if it’s the only option, specifically designed to steal my data and spy on me.
I empathise with GP’s anger. “You hold my money” should be enough of a reason to do all in their power to build great web apps and support alternative OS’es.
I find that banking apps deserve that extra bit of anger pointed towards them. (It’s also increasingly hard to find an ATM in many countries. What are banks up to?)
The thing is, people like GP don't seem to realize that holding their money is not much of an asset to these banks. Like, at all. Maybe no that interest rates are higher. But in general, you're not doing them any favor. My understanding is that holding retail money is a loss leader for most banks. Unless GP is ultra wealthy, they're not doing the bank any favors by giving them their savings or whatever.
Your comment is kind of misleading. Banks absolutely make money on retail deposits, and you definitely are doing them a favor by putting your money in.
Banks do spend a lot on marketing to acquire a given customer, and will then upsell that customer on more profitable products like loans and credit cards. But having a high customer acquisition cost and then upselling is not quite the same as being a "loss leader" (which sort of implies that marginal profit is negative - that is, the bank is worse off having a customer who just deposits money and buys nothing else, than not having that customer at all - which is definitely not true).
> which sort of implies that marginal profit is negative
Was it not when interest rates were low, like when LIBOR was near zero? My understanding of that era was that many retail banks were working to shed retail deposits. Holding money was not profitable in that era, especially retail. And today I would still suspect it's not what banks are going for big picture.
interest rates being low doesn't mean banks stop making money on retail deposits. there is still a spread between the interest they pay to the account holder and the interest they make loaning out that money.
Okay, but here: I pay my main bank 2€/month to have my account. Am I not a customer? I didn’t ask them for favours. I pay for my account, my partner has insurance with them, we buy bonds and their insurance products, etc. But since their app is so immensely bad, we’re slowly moving to a different bank.
No, I don't want to run any apps, particularly commercial ones. I only run a few FOSS apps like K9, IronFox, Signal, Home Assistant.
I have, on occasion, downloaded and tested apps from the Play Store in a separate profile, and my experience of such apps has been extremely negative. Clearly, these apps don't exist for the user's benefit, and their purpose is to extract information about the user, including phone number, location, other apps used, contacts, etc.
I get that you'd want to protect you data, but that list is a bit weird. The phone number is rarely available to the apps today - you need to provide it yourself typically (SIM feature rather than Android thing), location can be denied, contacts can be denied, listing other apps requires a permission that very few apps are allowed to carry. Typically apps cannot do any of what you listed without explicit approval and it's definitely true for the legit ones.
What's more convenient than a permanent irreversible requirement that if I ever want to do any banking, I must use my phone or go to a physical branch (which are slowly all disappearing) to recover access. I can never just go back to _not_ using the app, I can only move the app to another phone. And the app restricts which apps I can have installed and even which developer settings I can enable.
The average banking app is not about convenience, it is about restricting how a user can access their account, compliance box ticking and an endless march towards minimising liability at all cost. Meanwhile people are getting mugged and moving money at knifepoint because the device they normally carry around everywhere with them is now a gateway to their bank account.
I only run apps that are open source, or that I can audit and that don't abuse Android's silly features to restrict me, and only when the app isn't a requirement to access or interact with something. For example I refuse to buy any hardware which requires a proprietary app to use a feature.
Move to the UK, none of your listed issues exist due to open-banking [1] (or, at least I’ve never personally encountered any of those issues with any of the four bank accounts I have).
Optionally. And passkeys attestation only covers the HW key for example, not the OS running the website or the website. You're still completely free to re-implement it your way + FIDO2 is a standard, so eg. if you want to write your own native app for the bank web API, or whatever else, you can and passkey attestation will not stop you.
>Why do you expect me to be your distributed infrastructure provider?
...You realize that we're talking about banks, right? Institutions operating on a fractional reserve? Take your money, use it as collateral to print 10x their holdings in interest-bearing debt? Free to restrict your withdrawals and bail-in funds from your account to save their own hides? Those banks.
The Occupy Wall Street and Bitcoin dudes and dudettes had it right, which is why they were carefully marginalized and appropriated, respectively.
If you have Bitcoin in a self-custody wallet, there isn't a bank corporation to "restrict your withdrawals and bail-in funds from your account to save their own hides", right?
My fiancée who _does_ have the HSBC app has had to choose between enabling accelerated animations in the android developer settings and being able to access her bank account.
I think the HSBC app qualifies as malware but I'm morbidly curious how bad South Korea's version is...
Yeah, putting up HSBC as some bastion of great experience is an odd choice. Their web UI is straight out of the early 2000s, complete with odd little redirects to even crustier even older web portals for doing certain operations. And their app is pretty garbage as well.
My bank pestered me so much to use their app that I eventually caved in. Ironically, they claim it's more secure than normal internet banking from the PC with 2-factor authorization, even though they send the SMS token for in-app transfers to the same phone as the app...it makes no sense.
The state requires this as single sing-on to several other entities. By owning both your password (which they have by definition, it's where you log in) and the 2nd factor (it's an algo on their app, conveniently backed up on their servers).
It's already public five eyes did worse in the past. This is very much in their alley.
What what reason you would have to REMOVE security features you already had in place?
Assuming your phone cannot be trivially unlocked by a thief, it likely is safer to bank on it than on a computer.
Because unless your desktop is dedicated to banking, there's always the chance that one of your other activities will install malware. If you don't use FDE (the majority of people) and you saved your banking password in the browser rather than a password manager (likely a scary amount of people), then theft is also an issue.
Neither of those things are really a problem on a mobile device.
The banking app _is_ the malware. It interferes with the normal use of your mobile device. For example, you can't use developer options to speed up the UI animation speed if you want to access your bank account. You can't install any app you want if you want to access your bank account. etc...
That is not the same Walt. I'm assuming you found the TrustPilot site for https://walt.io, which is some Telegram crypto thing from the US. What GP linked to is an independent wallet app that currently supports passes and is scheduled to support tap-to-pay in the near future.
I've heard that an NFC alternative to ApplePay & Google{Pay|Wallet} is Curve Pay, but sadly it requires KYC (while the former ones don't). Do you know if Walt will require KYC too? It's not clear from their website.
If I remember correctly in their newsletter they mentioned that they will, as it was unavoidable. But I'm talking from memory, that email is long gone from my inbox.
the problem I had with Curve is that this privacy policy is a bit trash, and their DPO was unresponsive when I tried to exercise some of my GDPR rights
Right... and let's just hope those banks pushing the app-everything culture with semi-working web interfaces still online don't start requiring unauditable WASM binaries to run them.
> I am not going to let you require that I run your proprietary malware in order to access my own money.
Why do they need to tailor to you how they do business? They could cut you off from accessing your money over the internet entirely if they wanted. They don't even have to offer a debit card, it could be a bank where you can only deposit and withdraw cash in-person.
My point is that you choose the institution you want to bank with based on what they offer and if it works for you. Banking is the poster child for an industry where people switch institutions based on what the institution offers.
> The idea where you are effectively _expected_ to constantly provide free compute for companies to run their complete garbage on hardware _you own_ just for the privilege of giving them money is one of the most absurd trend in recent times.
Corporations offer services for money only under very narrow requirements and conditions because relaxed requirements would cost them money overall. If people are expected to provide free compute, and 99.9999999% of your customer base is okay providing that free compute, then they'll go that route.
: The actual cost to run any given javascript or web app is probably less than a penny, even if you add the actual energy cost to do so plus amortize the hardware cost over the lifetime of your hardware
"Let you hold my money"? In what society is that true? Banks run our financial infrastructure, and you can't just opt out of them. If you want to have a salary, do your taxes, or raise children you will need a bank. They have an immense amount of power and operate in a heavily regulated area so there's guaranteed to be very little competition.
Voting with your wallet does not work here. There is only a handful of banks, and in many (most?) countries they all force proprietary software and/or unreasonable contracts on their customers, switching between them does not help.
> Banks run our financial infrastructure, and you can't just opt out of them. If you want to have a salary, do your taxes, or raise children you will need a bank.
After getting screwed around by my bank (ASB) I am looking to get away from them. Wise is tempting. They are not a bank.
My salary can go to them. Why would I need a bank for taxes or my children?
The only thing holding me back is the fact that money isn’t government guaranteed as secure with them. With ASB NZ$100k is government guaranteed.
Very good news. It's a good sign if banking companies are considering the actual security issues at play and not just blindly rejecting all unofficial ROMs.
GrapheneOS will have official support on multiple devices from Motorola and will likely eventually have green verified boot state on the subset of their devices with support for it. This won't help with the Play Integrity API banning using it. Apps aren't banning non-stock operating systems but rather non-Google-certified operating systems.
Google certification isn't open to us due to requiring licensing Google Mobile Services and agreeing to an enormous amount of anti-competitive terms including banning many of the privacy and security features we provide. It would also be incompatible with providing updates without unacceptable delays.
Yes, we very actively engaged in discussion with the EU Commission. It hasn't resulted in any major actions against Google in this area yet. The people we've talked to seem to understand what we've told them but it's not more broadly understood. They focus on easier to understand and less technical things where Google can't fool them with misleading claims and misdirection as easily such as forcing them to allow alternatives to the Play Store and Google AI.
Play Integrity API is disguised as a security feature and is aligned with governments wanting to crack down on people freely using arbitrary software and hardware which makes it hard to convince governments to stop it.
Our point is that GrapheneOS will be an officially supported OS on Motorola devices and will be sold with it officially installed but will still be banned. It's likely it can have green verified boot state eventually but it will still be banned.
> GrapheneOS will have official support on multiple devices from Motorola
This is excellent news, because the phone that has been confirmed so far (the Signature 27) is absurdly large and expensive. The Pixel 9 I currently run Graphene on is already too big for my taste.
This post is actually really bad for a Hn post, it appears to be a reply to someone else hence the lack of context here, and the link appears to be a list of banking apps that are have some level of compatibility at all, not the official 12.
Our linked reply says most banking apps work on GrapheneOS and that only around 10% are unavailable due to banning a non-Google-certified OS. What we said about banks specifically permitted it means some of those former 10% of apps not allowing it began explicitly permitting it in one way or another. Some did it by removing or modifying certain checks while others did it by checking for GrapheneOS and potentially other operating systems via Android hardware attestation as an alternative to the Play Integrity API.
It requires sandboxed Google Play. If you want to avoid that, you need an account at one of the European banks with tap-to-pay not using Google Pay and an app which can run without Google Play. We don't have a specific list but there are a bunch throughout Europe.
Curve works on GrapheneOS but requires sandboxed Google Play. There are European banking apps with support for tap-to-pay without Google Play. If you're not in Germany, the only way to do without sandboxed Google Play is getting an account at one of those banks. We don't have a specific list of those banks on hand.
In Germany Sparda-Banken and, I think, Volks- und Raiffeisenbanken support tap-to-pay through their apps. (And maybe other banks providing apps developed by the same contractor, Atruvia AG.)
PayPal also offers tap-to-pay, though I recently had to disable Graphene's "secure app spawning" feature for the PayPal app to get it to open.
If we want our bank to add suppprt for GrapheneOS and specifically for “tap to pay” on GrapheneOS, without Google pay, what technically and specifically should we be asking for?
I wish I had a good answer for you! I don't think there's anything specific they need to do for GrapheneOS. They "just" need to use Android's NFC API[0] and then do the necessary magic incantations to implement the relevant payment scheme, i.e. exchange data with the credit card terminal and talk to the bank's backend servers. How exactly that works… no idea. But if there's anyone who knows it's them!
There was a time when I thought about figuring this out in detail and building an open-source alternative to Google Pay. But from what I've heard, integrating with credit cards is not something that can be done in an agnostic manner but actually requires support and buy-in by the issuing banks. Not a great perspective for such an app.
Mine (KH bank) does perform a safetynet attestation that fails, as I don't even pass basicintegrity, then proceeds to completely ignore the result and still let me in on GOS.
(FWIW, sometimes when you _block_ the app from the Play Integrity API (in this pop-up) the app that wants to perform the check works, while it fails when you do not block it)
Basic integrity requires being logged into an account. You can create a throwaway account and you'll pass. You may need a VoIP number if you're using a VPN to meet the phone number requirement for IPs without a good reputation.
This post is awful, the link posted here is to a social media reply and even that reply does not contain a list of the 12 banks, it does however contain a link to a much larger list of banks, which are supported but not necessarily officially supported.
Let's hope your comment won't summon Daniel Micay to this thread once it's daytime in the USA, dropping 10000-character comments on why all of us are wrong, flanked by his alt-accounts validating his every point and gaslighting whoever argues with him.
I think GP may not realize it's (likely) all legitimate accounts, just from 'devoted' GrapheneOS sycophants. They just get sic'd on HN comments if they opt-in to "Do you want to opt-in to mentions for help addressing inaccurate media coverage of GrapheneOS?" on the official Discord.
Evidently GP hit a nerve[0], though I don't know what they were expecting trying to poke the bear like that.
It appears pretty clear that you are active there too to both inform yourself of your "sworn enemy" (to orchestrate your own attacks) and to denounce the existence of a clearly benign effort, what you just did. Because if it weren't benign, then could you ever point to evidence, for a start? Maybe comments that resort to the same rethoric techniques as yours instead of bringing correct information, and politely so.
It greatly discredits what you say about us, the GrapheneOS community, when not only all you have are ad hominem reactions (against the entirety of the community it seems, as well as against the developers[0]) but you are guilty yourself[0] of what you accuse your enemy of, persecution / harassment.
What further evidence is necessary after your own Discord screenshot in your comment I'm replying to? It is quite bizarre how this platform allows this to go on.
I fail to see how my being in the Graphene discord discredits anything I've said. I use the project, so I remain in the Discord to keep up with updates.
You'll notice that I always say I use the project, I think it's excellent usability-wise and I appreciate the technical work you have done. And that, in spite of that, while you are not my "sworn enemy" I still find your behavior pathetic and off-putting.
I'm all but certain the only reason you often get so many throwaway accounts that attempt to troll the official community platforms is because of how often the core contributors take the bait and 'crash out', as the kids would say.
And the reason why there's more and more real accounts on HN (and elsewhere) that now criticize the behavior of the core contributors (and sycophants) is because it's very off-putting to observe the behavior in real time. Each time you behave this way, when every single critical comment in an HN thread has been flagged due to being posted in the Graphene discord and having a legion of sycophants downvote it, there will be more and more people with raised eyebrows.
Louis Rossman comes to mind, someone who could have been a great ally to the project yet got burned by this "persecution complex" behavior for no real reason.
In that very comment you link to, every single reply of anyone even lightly criticizing the project has been flagged. That's not natural for HN, almost all discussions generally go both ways on here (for any given topic, some criticism, some appreciation) and it's clear the discussion has been brigaded.
You claim HN is suppressing your voice and it's being unfair in platforming "libel and harassment" against you, yet you'll notice none of your replies are ever flagged or silently removed by moderators. HN is simply a neutral platform, you are going to get both criticism and support unless it is explicitly suppressed by the moderators. Yet you keep throwing hissy fits when they doesn't automatically censor any dissenting opinions about you on the platform on your behalf.
There is a significant difference between coordinating community members to brigade and notifying community members about threads which contain factual inaccuracies about the projects technical work or history.
As an open-source project and a non-profit foundation, there is not a PR team or firm. It is perfectly normal to have an opt-in notification role for community members who wish to help clarify technical misconceptions in public discussions. It is a transparent and not uncommon practice.
HN has built-in protections against external voting and flagging. Comments that end up being flagged are rarely (if ever) substantive criticisms related to the OS or foundation. In nearly every case they are comments serving to derail technical discussions into personal attacks, armchair psychology, or unsubstantiated accusations against contributors and community members (like repeatedly calling community members "sycophants" and "pathetic").
Constructive technical criticism of the project happens every day, and is welcomed without issues. Expecting those discussions to remain focused on technical aspects and factual realities rather than personal hostility isn't "crashing out".
> There is a significant difference between coordinating community members to brigade and notifying community members about threads which contain factual inaccuracies about the projects technical work or history.
There is no functional difference when the obvious end-result is sending a horde of external people to influence voting in the thread, the definition of brigading.
> As an open-source project and a non-profit foundation, there is not a PR team or firm. It is perfectly normal to have an opt-in notification role for community members who wish to help clarify technical misconceptions in public discussions. It is a transparent and not uncommon practice.
This is absolutely not a common practice. Point to other notable FOSS projects that act in this manner, I've legitimately never seen it from other projects.
> HN has built-in protections against external voting and flagging. Comments that end up being flagged are rarely (if ever) substantive criticisms related to the OS or foundation. In nearly every case they are comments serving to derail technical discussions into personal attacks, armchair psychology, or unsubstantiated accusations against contributors and community members
The behavior of the core maintainers and broader community is still intrinsically tied to the technical aspects of the project, and the discussion at large. When there are threads about OpenAI (and other commercial AI providers) and the U.S., do people stop at discussing solely technical aspects of both, or do they understandably bring up relevant social and communal points as well?
A security project demands particularly high trust, which is where my concern stems. I would love to use GOS without worry, my hope is that the project can course-correct and eventually put this behavior behind them.
> (like repeatedly calling community members "sycophants" and "pathetic").
The community does in fact have some sycophants. I never asserted that every single member is one, or that they are the majority of the community (as they are not). And I called the behavior pathetic, not the member. Your framing of these comments is disengenious.
> Constructive technical criticism of the project happens every day, and is welcomed without issues. Expecting those discussions to remain focused on technical aspects and factual realities rather than personal hostility isn't "crashing out".
Firstly, the "crashing out" was in the context of random trolls messing with core contributors in official communication channels and successfully getting a rise out of them (IE "don't feed the trolls and they'll go away"), though I do infact argue expecting people to solely focus on technical aspects of an inherently multi-faceted project to be unreasonable, for reasons stated above.
Go touch grass, what sort of positive beneficial value does this add to any conversation.
Your type make HackerNews more like Mumsnet full of feminine energy, gossip and character assassination avoiding a single logical thought or adding anything of technical value.
This asinine nonsense is like reading a 14 year old girls diary. Grow up.(And before you think going after my feels will help it won't chick, I know the above after laughing with my wife when we went back to hers.)
Your account is freshly created for the purpose of attacking GrapheneOS including making personal attacks on our team. There are usually multiple of these freshly created accounts attacking GrapheneOS in each thread about it.
GrapheneOS has over half a million users. It has a lot of support on Hacker News from people who either use it, want to use it or know they benefit from the work we're doing. Most of the people countering inaccurate claims about GrapheneOS and attacks on our team have participated on the site for years and post about many topics.
I just wanted to mention that my criticism of the original post comes from a place of love for GrapheneOS and its mission. I really wanted to know what the official 12 banks are because I want to consider using one of those banks.
I always have to roll my eyes when someone tells me they consult for banks like that's supposed to be impressive.
That crowd thinks 12 Factor applications are some monumental thing, "oh no, we can't do that, we would have to hire only the most expert experts, nobody does 12 Factor applications". They're all Windows tards.
Then as highlighted the other day, the big banks, including LLoyds, all run on Google's Cloud because ding ding ding big surprise they couldn't figure it out themselves, and they didn't deploy multi-AZ. They didn't do a rudimentary thing that virtually every startup knows to do and does.
The banks and the clowns that surround them are, by today's standards, barely computer literate.
Why not just use a web app from laptop at home? Why do you even need an app on your phone? So that you can urgently transfer money to some scammers you met in the street?
I do not have any banking apps, and I log into a bank account maybe once in month or less often.
The same functionality available through a web app on a laptop is available on a GrapheneOS phone through the same web app. Banks increasingly limit features such as sending transfers or depositing cheques to their iOS and Android apps. There are government regulations and industry standards being put in place which require using an app with device and app integrity checks to approve transfers. The EU has these kinds of regulations but temporarily allowed using insecure SMS 2FA for confirmation instead.
> banking apps began specifically permitting GrapheneOS
In my view, that's not any better than specifically permitting Google only. This should not be a whitelist at all. I assume my self-signed GrapheneOS would fail this test?
Not necessarily, it depends on how they fixed it. It isn't up to us. Some of these apps began supporting it by fixing their own anti-tampering code to stop being incompatible with our exploit protections to avoid needing users to opt-out for the app. Some were using the Play Integrity API and stopped doing it. Others were using the Play Integrity API and implemented the Android key attestation API as an alternative with the GrapheneOS verified boot keys specifically permitted.
The fact that GrapheneOS digitally signs their releases doesn't make them not open source. This is indeed a bad situation, but the badness is 100% the fault of Google for having a hardware attestation "feature".
GrapheneOS is open source. This has nothing to do with that. GrapheneOS has heavily pushed back against apps using remote attestation to restrict which operating systems and hardware can be used. When apps are unwilling or unable to remove it such as due to government regulations, we try to convince them to permit GrapheneOS and other alternatives via a standard Android API instead of only using the Play Integrity API.
Banks are increasingly adding checks for Google certified devices. In the EU, there are regulations requiring banks to start verifying device integrity. It's headed that way worldwide with a growing number of regulations and industry standards requiring it. Apple's App Attest API and Google's Play Integrity API have repeatedly been the only options recommended by the EU which has contributed to the worsening situation in the EU in particular. We convinced the EU to remove those specific examples from several official standards. No one has been able to convince them to stop heading down this path despite a lot of people pushing back against it. We haven't been able to convince them to define actual requirements let alone to require permitting anything which meets those requirements. They give a vague description of what they require doing shaped around the Apple and Google integrity APIs.
We convinced around a dozen banks mostly in the EU to use the standard Android key attestation API included in the Android Open Source Project as an alternative. It allows apps to verify the OS verified boot key hash, patch level, app signing key hash(es) and app version code based on a root of trust. This meets the requirements for the EU standards and enables permitting any alternative with verified boot and a mandatory app sandbox with support for verifying the app's signing key and passing it to the hardware keystores. Other operating systems can publish their signing keys in the signed JSON format we published and ask the same companies to include their keys too.
Once apps implement an alternative to the Play Integrity API to permit a single OS, it's easy for them to add more. The hardest part is getting them to even consider doing it. It's nearly impossible to get in contact with the right people and to convince them to do it. Once we establish that contact and convince them to ship it, it's a lot easier. There has been an ongoing issue of these apps not adding our new verified boot keys which are per-device-model for security reasons similarly to the Pixel OS. We tried to solve that by creating a standard signed JSON format which can be automatically retrieved and used to automatically include the new signing keys. Exactly the same approach can be used to delegate certification and inclusion of arbitrary operating systems to other organizations. It can also be used for handling which roots of trust for non-Google-certified hardware are also permitted.
We would prefer if none of this existed but we don't live in that world and we're doing what we can to convince apps to permit GrapheneOS and other alternatives. We're heavily fighting against it being done in the first place and against more standards and regulations requiring it. We're also fighting against more centralized attestation systems such as the Play Integrity API as opposed to systems with actual standards where anything meeting those standards can be included. It would not be a good thing for there to an EU alternative to the Play Integrity API permitting specific operating systems and devices based on geopolitics and business interests. That would only accelerate adoption of attestation by EU apps which is already happening at a faster pace than elsewhere thanks to both EU regulations and what many of the countries are doing themselves.
If it's impossible build the binary from the source you've been given, then you haven't been given the source. The binary in question is one that passes attestation and secure boot. If I don't have the key, I don't have the source.
MIT allows this (you not giving me the source). GPL2 allows this in some jurisdictions - notably, not in Germany. GPL3 absolutely doesn't, which is the reason Google refuses GPL3 upstreams.
I emailed the moderators about your comment being dead, after vouching failed to bring it back. They said it looks like it was a false positive hit in a spam filter and they have taken steps so it should not hit you with any more false positives.
As far as secure boot and attestation goes, my understanding is that these are based on signatures.
Things like signing keys have generally not been considered to be source code under GPL. Such things before GPLv3 were completely out of scope.
In GPLv3 they were brought into scope, but not by changing the way they define source code. Instead they added a new category, "Installation Information", for "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work [...]".
Section 6 of GPLv3, which is where the part your quote comes from, under some circumstances requires that you must accompany the conveyed Corresponding Source must be accompanied by the Installation Information.
The circumstances where this is required are pretty narrow. Before we get to that we need one more term that was added for GPLv3: "User Product".
>> A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
Installation Information must be included when two things are true:
1. The object code conveyance is in, with, or specifically for use in, a User Product, and
2. The conveying is part of a transaction in which the right of possession and use of the User Product is transferred to the recipient.
In short, under GPLv3, if you want use GPLv3 code in the software or firmware you include out of the box on hardware you are distributing you need to include Installation Information.
As far as I know GrapheneOS is only distributed as a third party download you can install on a device you already own, so does not trigger the GPLv3 Installation Information requirement.
Permissively licensed open source code is open source code. Firmware on a secure element can be open source without it being possible to replace it without the signing key on a production device.
Many of our posts about it heavily criticize apps limiting which operating systems and hardware can be used in addition to the Play Integrity API itself.
I think this is the real problem here if it's true. The community must absolutely retain the ability to fork the project and reintroduce things like root that the developers are obstinately against. If not, then Graphene will simply become another Google/Apple.
I think root is precisely what most of these apps are trying to avoid. They think (at least the finance app I used to work for thought) that with root, user credentials the app stored would be accessible by whatever uses those root permissions and they didn't want the risk
> I think root is precisely what most of these apps are trying to avoid.
Maybe, but it's necessary when you want to modify some aspect of the system you disagree with. For example, Android has a mechanism that prevents the user, the owner of the phone, from snapping a screenshot of an app he can see with his own eyes. Those kinds of limitations are enraging, and are just one example of why root is needed if the user is to truly own the device.
Well yes, that's exactly the sort of the thing banking apps would want to prevent. Android also blocks overlays on banking apps to prevent a whole class of attacks.
I don't get this philosophy at all. When I root my phone, I take manual steps to get myself access to my device. Even if in some outlooks it wasn't before, clearly the security of my phone is fully on me at that point. Can't they say that in their terms instead of locking you out?
But you can do that. You can go and root it with a fork. You just won’t run banking apps on it, because it introduces undue risk that they don’t want to absorb.
This ‘all or nothing’ attitude in the comments is a bit silly to be honest.
Not necessarily, it depends on how they fixed it. It isn't up to us.
Some of these apps began supporting it by fixing their own anti-tampering code to stop being incompatible with our exploit protections to avoid needing users to opt-out for the app.
Some were using the Play Integrity API and stopped doing it.
Others were using the Play Integrity API and implemented the Android key attestation API as an alternative which means only a list of operating systems and hardware they choose to permit will work in addition to Google certified devices with the stock OS via the Play Integrity API.
It's properly sandboxed, which is a lot better than Google Play Services on regular Android. Far from ideal of course, but I assume GrapheneOS is built with those people in mind for whom Google is unavoidable.
It depends on how they fixed it. It isn't up to us. Some of these apps began supporting it by fixing their own anti-tampering code to stop being incompatible with our exploit protections to avoid needing users to opt-out for the app.
Some were using the Play Integrity API and stopped doing it.
Others were using the Play Integrity API and implemented the Android key attestation API as an alternative which means only a list of operating systems and hardware they choose to permit will work in addition to Google certified devices with the stock OS via the Play Integrity API.
There's five banking apps that support it specifically listed here [1]. I guess the dozen is not listed somewhere. Roblox, Hyundai, and Kia are also apps that officially support GrapheneOS. We should note that not all that are supporting it are using attestation.
I find all the people complaining about this to be rather insane. This is a completely open source linux distro getting official support from banks, some of the most legacy companies of all. This is good news. If companies are open-minded enough to support GrapheneOS, they're gonna be much more likely to also officially support other secure operating systems that are open source.
These are banking apps that weren't previously possible to be used on GrapheneOS. We're going from zero to one, not a step back.
GrapheneOS and AOSP are Linux distributions. Linux is not glibc, systemd, GNU coreutils, GCC and GNOME. Linux doesn't have a specific libc, init system, command-line utilities, compiler toolchain, graphical environment or other userspace components. There are many Linux distributions beyond Android not using those components. There's no standard Linux userspace and a distribution using OpenRC, musl, Clang/LLVM, uutils coreutils and other software isn't somehow not Linux. Linux distribution doesn't mean systemd/GNU/Linux.
GrapheneOS and AOSP do use the userspace components developed with the Linux kernel such as iproute2. GNU components aren't part of Linux or the broader Linux project. Those don't even use a compatible license. It isn't legal to use the Linux kernel source code as a reference for writing glibc code since GPLv2-only does not permit the additional restrictions of GPLv3.
I’d just like to interject for a moment. What you’re referring to as “Android,” is in fact Android/Linux, or as I’ve recently taken to calling it, Android plus Linux kernel.
Linux is not an operating system unto itself, but rather a kernel—a core component that manages hardware resources. Android uses the Linux kernel, but replaces the traditional GNU userland with its own runtime, libraries, and system framework.
Many users run Linux-based systems every day without realizing it. Through a peculiar turn of events, the Linux kernel combined with Android’s userspace is often simply called “Android,” and many of its users are not aware that it is built on Linux at its core.
There really is Linux in Android, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs you run. The kernel is an essential part of the system, but useless by itself; it can only function in the context of a complete operating system.
Android is normally used in combination with the Linux kernel: the whole system is basically Android/Linux, a Linux-based operating system with a distinct userspace, not a GNU/Linux system like traditional desktop distributions.
It's very difficult to convince these apps to officially support a single alternative to Apple and Google Mobile Services devices. Once they're convinced to it and have committed to it, it's much easier to convince them to support more alternatives. Many of these apps are required to check device and app integrity by government regulations or industry standards. The EU has defined multiple standards requiring it. Multiple of the EU standards have at least initially explicitly referred to the Apple App Attest API and Google Play Integrity API as ways to verify device and app integrity. People were unable to convince them not to do it. We convinced them to remove references to specific Apple and Google APIs from several standards. We were unable to convince them to define any actual requirements or especially to require permitting any OS or hardware meeting those requirements. We tried very hard to convince them to do that and were unsuccessful.
GrapheneOS has heavily pushed back against using attestation to permit only specific software and hardware for running apps and using services. We've convinced dozens of apps to stop doing it altogether. We haven't had much success convincing banking apps to stop using the Play Integrity API to enforce Google certification, but we have convinced at least around 6 companies published at least around 12 apps to use the Android key attestation API to permit GrapheneOS. Those apps can now also easily add other operating systems supporting verified boot too. They're now aware of this being a choice and are considering how to handle it instead of simply going along with the typical approach of permitting only Google certified hardware running the stock OS.
We defined a signed JSON format for distributing verified boot key hashes for use with the Android key attestation API. This can be implemented by other operating systems implementing verified boot, a mandatory app sandbox and support for passing the signing key hashes and version of an app using it to the standard hardware keystores. It can be implemented beyond Android-based operating systems.
Unless people can convince the EU and other regulators to move in the opposite direction, this is where things are headed for access to many important government, banking and other services. We've tried our best to convince the EU and others to stop heading down this path and to start forbidding apps and services from doing this instead. They've continued heading down this path and we're working hard to keep apps working and to roll back the gradual loss in compatibility with banking apps gradually adopting the Play Integrity API. We need our community to help heavily pressure apps using it to stop or provide an alternative. We're gradually having success due to our growing userbase and influence. Perhaps one day we can convince the EU and many countries around the world to forbid using attestation to limit which OS or hardware can be used but right now they're doing the opposite.
284 comments
[ 0.70 ms ] story [ 16.4 ms ] threadIronic for apps that are often so paranoid about "security" and "hardware attestation"
But both are examples of cybernetic entities, if they don't care then their control loops aren't correctly aligned.
There are around 6-8 banking companies which have made changes to explicitly permit GrapheneOS that we're aware of and several have multiple apps which add up to around a dozen apps. There are likely other apps which have made changes to support it without us being aware. Compatibility has improved a lot and we can't attribute that all to any one particular change.
I'm just starting a deep-dive on it.
As a newbie, can existing users point out any other gotchas?
* EDIT: Oh ffs, only on Pixel phones ...
I'm a previous Moto user and despite Pixel supposedly being more advanced, I really disliked them. I always preferred the Moto phones.
Gives me hope!
And yeah, it'll be Motorola from the next year on, but a proper, first party cooperation. I think that Motorola wants to become the answer to the question: "what's the best, safest android smartphone?"
None. Explicitly banned. And, though I feel bad for saying it, I can't blame them. If some idiot roots their phone and downloads malware, the bank may be responsible for refunding them. I can see why they don't want that headache.
Some. App works, but some functionality is unavailable. I've got a credit card app which works, but refuses to set up virtual cards or use "remember me". That's good enough for my use. Similarly, I had a merchant account which let me see my balance, but I couldn't use my phone as a credit card reader.
Works, but only in main profile. I'd rather keep financial things in a locked profile. But lots of banks disallow that.
Full. Everything works (although you may need to toggle some exploit protection off).
Some banks are reasonably good at letting you pass on technical queries to their developers - mostly the smaller ones. The nice thing about the UK banking sector is that it is trivial to move banks. So I switched accounts to providers which worked with my phone and let the old ones know why I was moving.
Are there countries where this is a hassle? Now I've only had personal banking accounts in ~3 countries (so far?), so maybe I'm in a bubble, but in none of the countries has "switching banks" been more than basically create a new account, start using new IBAN for incoming transfers, move direct debits to use new IBAN and start using new card(s). Those last two were even automatic in the last move I did for a lot of stuff. Is it typically more difficult than that in other countries?
Also I don't think I would actually want it done automatically. Some banks have better saving rates, some banks offer higher interest on checking, some banks are much better for taking cash out internationally, some banks have more ATMs/branches around where I live, etc. I have a few different banks I move money around in.
It automatically moves all of your Direct Debits, recurring payments, balance etc. It even redirects incoming payments to your old account to your new one.
It other countries it is a lot less trivial.
I mean this is the whole reason GrapheneOS does not ship a rooted version that they attest to. I doubt they are explicitly banning GrapheneOS, what they are doing is only trusting Google attestation.
The reason some banks explicitly allow GrapheneOS is because its easy for them to also trust GrapheneOS attestation, because it is not a rooted OS, and sensible security teams in banks can see that its more secure than any other Android phone including Pixels.
I wish people would understand this better, its what gives GrapheneOS a fighting chance of becoming a legitimate open source mobile OS that is accepted as secure for consumer use and that is not controlled by Apple or Google.
The central design theme of GrapheneOS is to have stronger sandboxes and more limits on what apps can access than stock Android does. Granting an app root access does exactly the opposite; someone behaving rationally and consistently usually won't want to do both on the same device.
We wouldn't mind providing a 2nd set of releases with user root access but those would have separate signing keys for privacy and security reasons. It would not be accessible to large portions of the OS to apps. We don't do it because it would double the number of builds and would be a massive amount of additional work for managing and testing it. It would take immense resources to create a variant of the OS which we'd recommend against almost anyone using mainly to provide a novelty. We have much better uses for our resources. Resources are always limited and doubling the number of OS releases for a 2nd time would have a huge cost.
I've done a couple casual web searches for such evidence and come up short. If somebody has good data on this, I don't think they're publishing it.
Though the most effective way to cut out that kind of fraud is to stop using SMS for authentication, which banks don't seem to be interested in doing.
Few orgs understand compliance. While there might be some compliance people at the org level, individual teams implementing features will need to have a good line to them. In the end, knowledge is siloed and everyone needs to deliver on time. So it’s easier to forbid with some controlled collateral damage than to permit with an uncontrolled downside variance. Just a derisking hedge.
Serving use cases that drift away a bit “too far away” from the average (+ some sigmas) use case is not economically justified for a product manager - their KPIs would deteriorate from such “altruism”. No one will care if a few low-margin customers can’t use the product.
Most of the banks don't require not being months or years behind on bare minimum Android security patches let alone requiring anything close to proper security patches. That may rapidly change in the near future due to AI accelerated exploit development making exploits far more accessible and broadly deployed.
Nearly all these apps aren't banning GrapheneOS on purpose but rather because they're doing the least possible work to implement weak anti-tampering measures. Play Integrity device or strong integrity levels are an easy way to do it. They can use strong integrity if they're willing to forbid extraordinarily insecure devices failing to meet a very low bar for security. Most banks aren't willing to do that since it would mean blocking the majority of Android devices so they use device integrity which barely does anything more than enforcing licensing Google Mobile Services to reinforce Google's monopolies. Even the strong integrity level doesn't enforce much more than that, it's mostly just much harder to bypass at scale.
Most of us understand the desire to protect customers from fraud, but I don't think we should accept blanket restrictions on everyone's freedom simply because some people might make poor security decisions.
There's also the unspoken/uncomfortable economic reality here: the optimal level of fraud isn't zero. At some point, the cost of preventing additional fraud, including the loss of individual choice and autonomy, exceeds the benefit.
Could we aim for proportionate, evidence-based security rather than treating the least capable user as the benchmark for everyone?
I'm surprised to see that in this thread. That's usually reserved for politics and arguments about AI.
The scope is much smaller than that: restriction on what banking conveniences are provided.
> Most of us understand the desire to protect customers from fraud > At some point, the cost of preventing additional fraud, including the loss of individual choice and autonomy, exceeds the benefit > Could we aim for proportionate
I think you have answered your own question here; if a less than single percentage of retail customers use something that's not a general iOS or Android device, anything beyond that is not really worth it until regulation says otherwise.
> The scope is much smaller than that: restriction on what banking conveniences are provided.
The freedom to install whatever OS you like on your own phone?
> if a less than single percentage of __________ anything beyond that is not really worth it
My goodness one could fill in that blank in so many different ways, and all of the ones I can immediately think of would drag this thread straight into any number of dire arguments, so I'd better not.
Somewhere, 100 steps later, you might get to a "which OS on which hardware" aspect, but that's so far removed from normal life for the meaningful customer base that unless you want to stretch the scope of the post two orders of magnitude bigger than it is, it's not even close.
The bank makes a tradeoff, usually based on money: if they lose 5 customers because they can't use a specific app on a specific OS on a specific piece of hardware, they aren't going to care.
You can apply that to most businesses, especially the profitable ones. You shouldn't be surprised by that.
Would anyone know why? My understanding of profiles is arguably very limited, but I always saw those as equivalent to device owner profile from app runtime standpoint.
It's worth noting AOSP and GrapheneOS have both drastically changed since Android 13 on the Pixel 4. GrapheneOS is based on Android 17 since June 2026 and soon Android 17 QPR2 in December 2026.
I can't think of a legitimate reason to check this and refuse to run in a secondary profile. But banking apps sure love to cargo-cult invasive nonsense.
This obviously depends on jurisdiction, but how commonly is this actually the case?
I’ve thankfully never personally been on the receiving end of fraud or identity theft, but my impression is that here, everything that happens up until the point you tell your bank ”hey, uh, I think my account’s been compromised” is pretty much on you. I don’t think rooting your phone, installing a banking app from some umauthorized source et.c would be hard to construe as negligence.
A lot of people aren't able to distinguish "I got scammed" from "the bank took my money away".
Unless the bank has reason to believe that you're either trying to defraud the bank, or where unduly careless with your banking credentials (and you have to be really careless to meet that bar in the eyes of the regulator and the courts), then they're expected to refund you.
I've seen banks refund £100ks to customers that were defrauded over many months via romance scams. There are cases ruling by the Financial Ombudsman forcing banks to refund customers to handed over their cards and PINs to carers that then stole money.
The general attitude of the law in the UK, the regulators, and the courts, is basically it's the banks responsibility to provide appropriate security, in a form that their customers can easily use and understand. If banks want to make it easy for customers to move and spend money, then the risks associated with that convenience accrue with the bank, not their customers.
Obviously banks work very hard to worm their way out of their responsibilities here. But if you use the consumer protection tools that exist in the UK, which are very easy to access, and which your bank is required to inform you of, then it's surprisingly easy to force a bank to refund you for any fraud you suffer.
The question isn't whether they have to refund the money when the customer gets defrauded. The question is whether preventing the customer from using a less popular OS in any way prevents them from being defrauded.
To which the answer is somewhere between "negligible difference" and "it's actually anti-correlated with that because the custom ROM is more up to date".
I keep reading this justification, and it doesn't make an ounce of sense to me.
first of all, the number of people who want to root their phones is a fraction of 1%. children, teenage girls, and senile boomers don't do that. the number of people with rooted phones who could fall for "hello sir, I am sir John Whiteman from Microsoft, you're phone have virus, sir, please do the needful install this a pee kaa, sir" is near zero.
second of all, phones get stolen all the time, and it would make sense to reduce liability by not providing apps at all.
it's security theater.
If someone lies to them and tells them there is an app that lets them get free Roblox bucks or whatever, but first they have to root their phone, they will. If someone lies or makes an app that removes pimples or adds makeup in realtime, or something, but they make it only work on rooted phones, they will.
And it’s a completely different demographic than those would would fall for the phone call scam, but it’s incredibly disingenuous of you to suggest that the only malware distribution vector is being tricked into installing an APK.
I know people who are interested in modding games, pirating software, and installing “cool” apps just for the novelty. I would argue the most likely reason those people installed malware is voluntarily, because they searched out a hacked version of Bloons Tower Defence. Not because they “needed to pay an outstanding Windows service bill”.
If the banks were really so concerned about malware on the user's endpoint, and they had competent CTO, then they would write an app for Trezor or offer a Trezor with their own logo and app on it and users could sign transactions with it.
Trezors show on a screen to the user "this is the amount and where to be sent that you are signing for".
Malware with high privileges on a compromised user endpoint can bamboozle the user but a hardware wallet would catch that.
And there is a very large swath of banking customers who I wouldn't be surprised to learn that banks will earn less than $130 from over the course of a decade.
The use can be optional, I don't think anyone would suggest (or even presume?) otherwise.
Accounts with balance under $30,000 need not apply.
Many of the "good customers" (from a bank's perspective) already have a Trezor.
Big banks already require customers pay the $50 for an RSA fob anyway. No bank is providing these devices as a courtesy.
Many GrapheneOS users would rather pay out of their own pocket for a Trezor Safe 5 than have "you need to carry an additional phone too, a shit-phone" forced on them when GrapheneOS is perfectly adequate to run any app and with more meaningful security assurances than any other Android distro.
In the United States, users of Chase are already using FIDO2, which has the same cryptography-grounded effects I suggested above. The legacy tokens never had this kind of functionality, and from a security perspective are as crummy and vulnerable to MITM as OTP/TOTP.
As far as holding onto hardware keys, users don't lose hardware keys/wallets when those are attached to a keychain and the users are instructed to attach to add it to their general car/house keys. Attached to general car/house keys/fobs, hardware keys survive user-chaos at a much better rate than smartphones do. Other security-focused IT pros/execs have reported the same.
The key difference between those hardware tokens and hardware keys/wallets that do OpenPGP, or PIV, or the underlying cryptograpy functionality of "Bitcoin wallet", is they
andGrapheneOS is an open source project and people can make their own builds with arbitrary modifications. We recommend not adding a third party system giving root access to a large portion of the OS and making it possible to grant to apps with a dialog since it greatly reduces security if it isn't used. People can do what they want regardless of our recommendations.
Modifying GrapheneOS in any way creates a new OS which is no longer GrapheneOS itself. Forks of GrapheneOS must come up with their own name and branding if they're going to distribute their modifications. We don't want software which isn't GrapheneOS being confused with it.
This argument has never held any water for a simple reason:
Consider 2 phones.
1. Runs self-built lineageos (latest version), with magisk installed.
2. Runs official stock ROM, no mods, all apps from Play Store. Also, hasn't gotten any updates in 6-9 months and is running a 4.4.x kernel that isn't even the latest version on its branch.
If your app blocks phone 1 and allows phone 2, then you're doing security theater in a way that actively undermines actual security. The ability for a user to flash an OS or allow apps root access doesn't make a device insecure, but the ability for any app to grant itself root because the vendor can't be bothered to patch the OS certainly does.
Some were using the Play Integrity API and stopped doing it.
Others were using the Play Integrity API and implemented the Android key attestation API as an alternative which means only a list of operating systems and hardware they choose to permit will work in addition to Google certified devices with the stock OS via the Play Integrity API.
https://privsec.dev/posts/android/banking-applications-compa...
https://privsec.dev/posts/android/banking-applications-compa...
Looks like good progress to me.
As for the second part (separate authentication methods), sure, would be rather problematic if they require you to have a phone, but that's a completely separate and different issue.
Companies tend not to do illegal things. Especially if they’re public or have shareholders that might lose significant value if found out.
The trouble with data laws is that once they have your data, they're the only ones who actually know what they're doing with it. Which means the thing you need to prevent is them having it, which is typically not the thing those laws do.
If you have Google Play in the same sandbox as your banking app, why can't Google access everything there? Or are they in different sandboxes?
If you dont need any of the above its perfectly fine to run the banking app on your single, main profile.
It's getting somewhat annoying nowadays with banks pushing that crap, but fortunately legislation for access of people with disabilites forces them to provide tokens still.
A lot of them now switched to banking apps on the phone acting as token without a chance to opt out, though, so as a result I've stopped doing anything bank related on phones nowadays.
https://www.wellsfargo.com/biz/online-banking/securid/
Do you not run apps at all?
What this really needs is better browser support for NFC:
https://developer.mozilla.org/en-US/docs/Web/API/Web_NFC_API
But so let's do that then.
Your computer doesn't need to have any keys to do this. The card has a secret key, but it doesn't give it to the reader, it just responds to the challenge. The challenge often comes from a point of sale terminal, but it could just as easily come from the bank's web servers, and it isn't really a secret.
The only thing which resembles a secret here is the response from the card, which is the thing anyone can get regardless when have the card. Also, the entire premise of the card is that the attacker doesn't have it, so if they do then you've already lost.
When you open the app on your phone, the phone probably needed to be unlocked first, though not everyone sets a PIN or biometric lock on their phone.
Then you will be prompted for a separate PIN or your fingerprint within the banking app. This provides a stronger signal to the bank that you are the legitimate account holder. If your phone is lost or stolen, the chances of someone else being able to authenticate to your banking app are considerably reduced.
With the web app, people will often save their bank website login credentials in the browser. So now someone nefarious only needs to access the unlocked computer or phone the go to the bank's website to gain unauthorised by still authenticated access to the customer's accounts.
Yes, there are now laptops and tablets with biometric authentication, so the potential is there for adding biometric authentication for banking website. However, when you look at the demographics of banking app vs website use, a strong majority of Millennials and Gen-Z do all their banking via the phone app. Gen-X also slightly favour the phone app whereas Boomers strongly prefer the website. So banks focus their development efforts where the majority of users are.
The same is true for PCs. They've supported that sort of thing for decades, and it's optional for both the phone and the PC.
On top of that, a phone that people carry around everywhere is dramatically more likely to be lost or stolen than a desktop PC that never leaves their house.
> With the web app, people will often save their bank website login credentials in the browser.
If the bank actually cares about this then there are various ways to disable or impede it.
> However, when you look at the demographics of banking app vs website use
This is just the thing where you make something worse so fewer people use it and then use that as an excuse to keep making it worse. Nobody needs an app that could have been a web page, people use them because it's what get shoved down their throat if they don't go out of their way to do something else.
How often do you think companies are in the habit of doing things for your convenience?
Not who you replied to, but requiring me to install your app or create an account is usually going to mean I skip your thing unless I'm really motivated to use it.
For something like a bank, I think they ought to be mandated to offer a functional website, yes. A slick app is nice too, but not if it’s the only option, specifically designed to steal my data and spy on me.
I find that banking apps deserve that extra bit of anger pointed towards them. (It’s also increasingly hard to find an ATM in many countries. What are banks up to?)
The thing is, people like GP don't seem to realize that holding their money is not much of an asset to these banks. Like, at all. Maybe no that interest rates are higher. But in general, you're not doing them any favor. My understanding is that holding retail money is a loss leader for most banks. Unless GP is ultra wealthy, they're not doing the bank any favors by giving them their savings or whatever.
Banks do spend a lot on marketing to acquire a given customer, and will then upsell that customer on more profitable products like loans and credit cards. But having a high customer acquisition cost and then upselling is not quite the same as being a "loss leader" (which sort of implies that marginal profit is negative - that is, the bank is worse off having a customer who just deposits money and buys nothing else, than not having that customer at all - which is definitely not true).
Was it not when interest rates were low, like when LIBOR was near zero? My understanding of that era was that many retail banks were working to shed retail deposits. Holding money was not profitable in that era, especially retail. And today I would still suspect it's not what banks are going for big picture.
Tell that to Vanguard or Fidelity. Two of the largest 'money holders' in existence, and probably the two worst financial apps I can think of.
No, I don't want to run any apps, particularly commercial ones. I only run a few FOSS apps like K9, IronFox, Signal, Home Assistant.
I have, on occasion, downloaded and tested apps from the Play Store in a separate profile, and my experience of such apps has been extremely negative. Clearly, these apps don't exist for the user's benefit, and their purpose is to extract information about the user, including phone number, location, other apps used, contacts, etc.
The average banking app is not about convenience, it is about restricting how a user can access their account, compliance box ticking and an endless march towards minimising liability at all cost. Meanwhile people are getting mugged and moving money at knifepoint because the device they normally carry around everywhere with them is now a gateway to their bank account.
I only run apps that are open source, or that I can audit and that don't abuse Android's silly features to restrict me, and only when the app isn't a requirement to access or interact with something. For example I refuse to buy any hardware which requires a proprietary app to use a feature.
[1] https://www.openbanking.org.uk/
...You realize that we're talking about banks, right? Institutions operating on a fractional reserve? Take your money, use it as collateral to print 10x their holdings in interest-bearing debt? Free to restrict your withdrawals and bail-in funds from your account to save their own hides? Those banks.
The Occupy Wall Street and Bitcoin dudes and dudettes had it right, which is why they were carefully marginalized and appropriated, respectively.
This is likely meant as hyperbole, but South Korea's online banking requirements really tries to live up to this reputation
I think the HSBC app qualifies as malware but I'm morbidly curious how bad South Korea's version is...
it's so obvious they need backdoor access it's not even funny.
The state requires this as single sing-on to several other entities. By owning both your password (which they have by definition, it's where you log in) and the 2nd factor (it's an algo on their app, conveniently backed up on their servers).
It's already public five eyes did worse in the past. This is very much in their alley.
What what reason you would have to REMOVE security features you already had in place?
Because unless your desktop is dedicated to banking, there's always the chance that one of your other activities will install malware. If you don't use FDE (the majority of people) and you saved your banking password in the browser rather than a password manager (likely a scary amount of people), then theft is also an issue.
Neither of those things are really a problem on a mobile device.
the problem I had with Curve is that this privacy policy is a bit trash, and their DPO was unresponsive when I tried to exercise some of my GDPR rights
Why do they need to tailor to you how they do business? They could cut you off from accessing your money over the internet entirely if they wanted. They don't even have to offer a debit card, it could be a bank where you can only deposit and withdraw cash in-person.
My point is that you choose the institution you want to bank with based on what they offer and if it works for you. Banking is the poster child for an industry where people switch institutions based on what the institution offers.
> The idea where you are effectively _expected_ to constantly provide free compute for companies to run their complete garbage on hardware _you own_ just for the privilege of giving them money is one of the most absurd trend in recent times.
Corporations offer services for money only under very narrow requirements and conditions because relaxed requirements would cost them money overall. If people are expected to provide free compute, and 99.9999999% of your customer base is okay providing that free compute, then they'll go that route.
: The actual cost to run any given javascript or web app is probably less than a penny, even if you add the actual energy cost to do so plus amortize the hardware cost over the lifetime of your hardware
Voting with your wallet does not work here. There is only a handful of banks, and in many (most?) countries they all force proprietary software and/or unreasonable contracts on their customers, switching between them does not help.
After getting screwed around by my bank (ASB) I am looking to get away from them. Wise is tempting. They are not a bank.
My salary can go to them. Why would I need a bank for taxes or my children?
The only thing holding me back is the fact that money isn’t government guaranteed as secure with them. With ASB NZ$100k is government guaranteed.
Google certification isn't open to us due to requiring licensing Google Mobile Services and agreeing to an enormous amount of anti-competitive terms including banning many of the privacy and security features we provide. It would also be incompatible with providing updates without unacceptable delays.
Play Integrity API is disguised as a security feature and is aligned with governments wanting to crack down on people freely using arbitrary software and hardware which makes it hard to convince governments to stop it.
Potato, potato, right?
Is there such a thing as a non-stock operating system that is certified by Google?
This is excellent news, because the phone that has been confirmed so far (the Signature 27) is absurdly large and expensive. The Pixel 9 I currently run Graphene on is already too big for my taste.
Word is that banking apps that implement their own nfc interface within their app can be used for “tap to pay” on Graphene.
Curious as to how we can know which providers support this.
PayPal also offers tap-to-pay, though I recently had to disable Graphene's "secure app spawning" feature for the PayPal app to get it to open.
There was a time when I thought about figuring this out in detail and building an open-source alternative to Google Pay. But from what I've heard, integrating with credit cards is not something that can be done in an agnostic manner but actually requires support and buy-in by the issuing banks. Not a great perspective for such an app.
[0]: https://developer.android.com/develop/connectivity/nfc/nfc
I wonder if it's intentional.
https://play.google.com/store/apps/details?id=gr.nikolasspyr...
(FWIW, sometimes when you _block_ the app from the Play Integrity API (in this pop-up) the app that wants to perform the check works, while it fails when you do not block it)
Evidently GP hit a nerve[0], though I don't know what they were expecting trying to poke the bear like that.
[0] https://files.catbox.moe/7a0wr2.jpg (From the official GrapheneOS Discord)
It greatly discredits what you say about us, the GrapheneOS community, when not only all you have are ad hominem reactions (against the entirety of the community it seems, as well as against the developers[0]) but you are guilty yourself[0] of what you accuse your enemy of, persecution / harassment.
[0] https://news.ycombinator.com/item?id=47217356
What further evidence is necessary after your own Discord screenshot in your comment I'm replying to? It is quite bizarre how this platform allows this to go on.
You'll notice that I always say I use the project, I think it's excellent usability-wise and I appreciate the technical work you have done. And that, in spite of that, while you are not my "sworn enemy" I still find your behavior pathetic and off-putting.
I'm all but certain the only reason you often get so many throwaway accounts that attempt to troll the official community platforms is because of how often the core contributors take the bait and 'crash out', as the kids would say.
And the reason why there's more and more real accounts on HN (and elsewhere) that now criticize the behavior of the core contributors (and sycophants) is because it's very off-putting to observe the behavior in real time. Each time you behave this way, when every single critical comment in an HN thread has been flagged due to being posted in the Graphene discord and having a legion of sycophants downvote it, there will be more and more people with raised eyebrows.
Louis Rossman comes to mind, someone who could have been a great ally to the project yet got burned by this "persecution complex" behavior for no real reason.
In that very comment you link to, every single reply of anyone even lightly criticizing the project has been flagged. That's not natural for HN, almost all discussions generally go both ways on here (for any given topic, some criticism, some appreciation) and it's clear the discussion has been brigaded.
You claim HN is suppressing your voice and it's being unfair in platforming "libel and harassment" against you, yet you'll notice none of your replies are ever flagged or silently removed by moderators. HN is simply a neutral platform, you are going to get both criticism and support unless it is explicitly suppressed by the moderators. Yet you keep throwing hissy fits when they doesn't automatically censor any dissenting opinions about you on the platform on your behalf.
There is a significant difference between coordinating community members to brigade and notifying community members about threads which contain factual inaccuracies about the projects technical work or history.
As an open-source project and a non-profit foundation, there is not a PR team or firm. It is perfectly normal to have an opt-in notification role for community members who wish to help clarify technical misconceptions in public discussions. It is a transparent and not uncommon practice.
HN has built-in protections against external voting and flagging. Comments that end up being flagged are rarely (if ever) substantive criticisms related to the OS or foundation. In nearly every case they are comments serving to derail technical discussions into personal attacks, armchair psychology, or unsubstantiated accusations against contributors and community members (like repeatedly calling community members "sycophants" and "pathetic").
Constructive technical criticism of the project happens every day, and is welcomed without issues. Expecting those discussions to remain focused on technical aspects and factual realities rather than personal hostility isn't "crashing out".
There is no functional difference when the obvious end-result is sending a horde of external people to influence voting in the thread, the definition of brigading.
> As an open-source project and a non-profit foundation, there is not a PR team or firm. It is perfectly normal to have an opt-in notification role for community members who wish to help clarify technical misconceptions in public discussions. It is a transparent and not uncommon practice.
This is absolutely not a common practice. Point to other notable FOSS projects that act in this manner, I've legitimately never seen it from other projects.
> HN has built-in protections against external voting and flagging. Comments that end up being flagged are rarely (if ever) substantive criticisms related to the OS or foundation. In nearly every case they are comments serving to derail technical discussions into personal attacks, armchair psychology, or unsubstantiated accusations against contributors and community members
The behavior of the core maintainers and broader community is still intrinsically tied to the technical aspects of the project, and the discussion at large. When there are threads about OpenAI (and other commercial AI providers) and the U.S., do people stop at discussing solely technical aspects of both, or do they understandably bring up relevant social and communal points as well?
A security project demands particularly high trust, which is where my concern stems. I would love to use GOS without worry, my hope is that the project can course-correct and eventually put this behavior behind them.
> (like repeatedly calling community members "sycophants" and "pathetic").
The community does in fact have some sycophants. I never asserted that every single member is one, or that they are the majority of the community (as they are not). And I called the behavior pathetic, not the member. Your framing of these comments is disengenious.
> Constructive technical criticism of the project happens every day, and is welcomed without issues. Expecting those discussions to remain focused on technical aspects and factual realities rather than personal hostility isn't "crashing out".
Firstly, the "crashing out" was in the context of random trolls messing with core contributors in official communication channels and successfully getting a rise out of them (IE "don't feed the trolls and they'll go away"), though I do infact argue expecting people to solely focus on technical aspects of an inherently multi-faceted project to be unreasonable, for reasons stated above.
Your type make HackerNews more like Mumsnet full of feminine energy, gossip and character assassination avoiding a single logical thought or adding anything of technical value.
This asinine nonsense is like reading a 14 year old girls diary. Grow up.(And before you think going after my feels will help it won't chick, I know the above after laughing with my wife when we went back to hers.)
GrapheneOS has over half a million users. It has a lot of support on Hacker News from people who either use it, want to use it or know they benefit from the work we're doing. Most of the people countering inaccurate claims about GrapheneOS and attacks on our team have participated on the site for years and post about many topics.
That crowd thinks 12 Factor applications are some monumental thing, "oh no, we can't do that, we would have to hire only the most expert experts, nobody does 12 Factor applications". They're all Windows tards.
Then as highlighted the other day, the big banks, including LLoyds, all run on Google's Cloud because ding ding ding big surprise they couldn't figure it out themselves, and they didn't deploy multi-AZ. They didn't do a rudimentary thing that virtually every startup knows to do and does.
The banks and the clowns that surround them are, by today's standards, barely computer literate.
I do not have any banking apps, and I log into a bank account maybe once in month or less often.
Not only these features. Viewing PIN, enabling bank cards for internet purchases, enabling/disabling cards.
In my view, that's not any better than specifically permitting Google only. This should not be a whitelist at all. I assume my self-signed GrapheneOS would fail this test?
0 - https://www.gnu.org/philosophy/right-to-read.en.html
Banks are increasingly adding checks for Google certified devices. In the EU, there are regulations requiring banks to start verifying device integrity. It's headed that way worldwide with a growing number of regulations and industry standards requiring it. Apple's App Attest API and Google's Play Integrity API have repeatedly been the only options recommended by the EU which has contributed to the worsening situation in the EU in particular. We convinced the EU to remove those specific examples from several official standards. No one has been able to convince them to stop heading down this path despite a lot of people pushing back against it. We haven't been able to convince them to define actual requirements let alone to require permitting anything which meets those requirements. They give a vague description of what they require doing shaped around the Apple and Google integrity APIs.
We convinced around a dozen banks mostly in the EU to use the standard Android key attestation API included in the Android Open Source Project as an alternative. It allows apps to verify the OS verified boot key hash, patch level, app signing key hash(es) and app version code based on a root of trust. This meets the requirements for the EU standards and enables permitting any alternative with verified boot and a mandatory app sandbox with support for verifying the app's signing key and passing it to the hardware keystores. Other operating systems can publish their signing keys in the signed JSON format we published and ask the same companies to include their keys too.
Once apps implement an alternative to the Play Integrity API to permit a single OS, it's easy for them to add more. The hardest part is getting them to even consider doing it. It's nearly impossible to get in contact with the right people and to convince them to do it. Once we establish that contact and convince them to ship it, it's a lot easier. There has been an ongoing issue of these apps not adding our new verified boot keys which are per-device-model for security reasons similarly to the Pixel OS. We tried to solve that by creating a standard signed JSON format which can be automatically retrieved and used to automatically include the new signing keys. Exactly the same approach can be used to delegate certification and inclusion of arbitrary operating systems to other organizations. It can also be used for handling which roots of trust for non-Google-certified hardware are also permitted.
We would prefer if none of this existed but we don't live in that world and we're doing what we can to convince apps to permit GrapheneOS and other alternatives. We're heavily fighting against it being done in the first place and against more standards and regulations requiring it. We're also fighting against more centralized attestation systems such as the Play Integrity API as opposed to systems with actual standards where anything meeting those standards can be included. It would not be a good thing for there to an EU alternative to the Play Integrity API permitting specific operating systems and devices based on geopolitics and business interests. That would only accelerate adoption of attestation by EU apps which is already happening at a faster pace than elsewhere thanks to both EU regulations and what many of the countries are doing themselves.
MIT allows this (you not giving me the source). GPL2 allows this in some jurisdictions - notably, not in Germany. GPL3 absolutely doesn't, which is the reason Google refuses GPL3 upstreams.
As far as secure boot and attestation goes, my understanding is that these are based on signatures.
Things like signing keys have generally not been considered to be source code under GPL. Such things before GPLv3 were completely out of scope.
In GPLv3 they were brought into scope, but not by changing the way they define source code. Instead they added a new category, "Installation Information", for "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work [...]".
Section 6 of GPLv3, which is where the part your quote comes from, under some circumstances requires that you must accompany the conveyed Corresponding Source must be accompanied by the Installation Information.
The circumstances where this is required are pretty narrow. Before we get to that we need one more term that was added for GPLv3: "User Product".
>> A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
Installation Information must be included when two things are true:
1. The object code conveyance is in, with, or specifically for use in, a User Product, and
2. The conveying is part of a transaction in which the right of possession and use of the User Product is transferred to the recipient.
In short, under GPLv3, if you want use GPLv3 code in the software or firmware you include out of the box on hardware you are distributing you need to include Installation Information.
As far as I know GrapheneOS is only distributed as a third party download you can install on a device you already own, so does not trigger the GPLv3 Installation Information requirement.
This sounds great. Could you give some examples of this pushing back?
Many of our posts about it heavily criticize apps limiting which operating systems and hardware can be used in addition to the Play Integrity API itself.
Maybe, but it's necessary when you want to modify some aspect of the system you disagree with. For example, Android has a mechanism that prevents the user, the owner of the phone, from snapping a screenshot of an app he can see with his own eyes. Those kinds of limitations are enraging, and are just one example of why root is needed if the user is to truly own the device.
Is this just not legally possible?
This ‘all or nothing’ attitude in the comments is a bit silly to be honest.
Some were using the Play Integrity API and stopped doing it.
Others were using the Play Integrity API and implemented the Android key attestation API as an alternative which means only a list of operating systems and hardware they choose to permit will work in addition to Google certified devices with the stock OS via the Play Integrity API.
all these reports assume user installed google play store and google services.
this is like installing linux, then wine, then all the windows bloatware back.
Thanks, but no thanks. Remote attestation is simply not acceptable. You use it, I won't use your app.
Some were using the Play Integrity API and stopped doing it.
Others were using the Play Integrity API and implemented the Android key attestation API as an alternative which means only a list of operating systems and hardware they choose to permit will work in addition to Google certified devices with the stock OS via the Play Integrity API.
You get the roughly the same security properties by enrolling user-owned pubkeys.
I find all the people complaining about this to be rather insane. This is a completely open source linux distro getting official support from banks, some of the most legacy companies of all. This is good news. If companies are open-minded enough to support GrapheneOS, they're gonna be much more likely to also officially support other secure operating systems that are open source.
These are banking apps that weren't previously possible to be used on GrapheneOS. We're going from zero to one, not a step back.
[1] https://github.com/PrivSec-dev/banking-apps-compat-report/is...
GrapheneOS and AOSP do use the userspace components developed with the Linux kernel such as iproute2. GNU components aren't part of Linux or the broader Linux project. Those don't even use a compatible license. It isn't legal to use the Linux kernel source code as a reference for writing glibc code since GPLv2-only does not permit the additional restrictions of GPLv3.
Linux is not an operating system unto itself, but rather a kernel—a core component that manages hardware resources. Android uses the Linux kernel, but replaces the traditional GNU userland with its own runtime, libraries, and system framework.
Many users run Linux-based systems every day without realizing it. Through a peculiar turn of events, the Linux kernel combined with Android’s userspace is often simply called “Android,” and many of its users are not aware that it is built on Linux at its core.
There really is Linux in Android, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs you run. The kernel is an essential part of the system, but useless by itself; it can only function in the context of a complete operating system.
Android is normally used in combination with the Linux kernel: the whole system is basically Android/Linux, a Linux-based operating system with a distinct userspace, not a GNU/Linux system like traditional desktop distributions.
GrapheneOS has heavily pushed back against using attestation to permit only specific software and hardware for running apps and using services. We've convinced dozens of apps to stop doing it altogether. We haven't had much success convincing banking apps to stop using the Play Integrity API to enforce Google certification, but we have convinced at least around 6 companies published at least around 12 apps to use the Android key attestation API to permit GrapheneOS. Those apps can now also easily add other operating systems supporting verified boot too. They're now aware of this being a choice and are considering how to handle it instead of simply going along with the typical approach of permitting only Google certified hardware running the stock OS.
We defined a signed JSON format for distributing verified boot key hashes for use with the Android key attestation API. This can be implemented by other operating systems implementing verified boot, a mandatory app sandbox and support for passing the signing key hashes and version of an app using it to the standard hardware keystores. It can be implemented beyond Android-based operating systems.
Unless people can convince the EU and other regulators to move in the opposite direction, this is where things are headed for access to many important government, banking and other services. We've tried our best to convince the EU and others to stop heading down this path and to start forbidding apps and services from doing this instead. They've continued heading down this path and we're working hard to keep apps working and to roll back the gradual loss in compatibility with banking apps gradually adopting the Play Integrity API. We need our community to help heavily pressure apps using it to stop or provide an alternative. We're gradually having success due to our growing userbase and influence. Perhaps one day we can convince the EU and many countries around the world to forbid using attestation to limit which OS or hardware can be used but right now they're doing the opposite.