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.
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.
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 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.
> 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 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.
There are countries where, as a result of mergers, banking is now down to 3-4 banks, and they all have the same Android requirements, so switching won't get one anywhere.
If those countries are in the EU, you have the right to use a bank based in another EU country. The traditional incumbents will likely demand an in-country residential address (in direct contradiction of EU law). Which leaves the internet-only neobanks. I believe the only FOSS-compatible option is Wise, which has a modern web offering and does not even require that you install a native app. I understand N26 does, but it may work with Graphene. By contrast Revolut is a privacy-invading walled garden and should be avoided at all costs.
If you are not a citizen, but an immigrant, it could be very true in some parts of the world.
I have a living permit and legal status in the country I live in, but only few banks open accounts to people like me, most just deny anyone but citizens of the country.
The ones that open all work in GrapheneOS though, so not big deal for me in my particular case.
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.
> 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.
> 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.
Could be general polarisation, or just that it's a "but in my case it is different" visceral response.
While people might not be moved by data, it would be interesting if some more public information on what people actually use was available. Imagine data points like unpatched/unpatchable iOS or Android devices being multiple percentages, or outdated browsers. Similarly, the effort per app/OS combination; if it costs X to support Y configuration, then it would be somewhat easier to see if it's more about the will to do anything rather than real-world problems.
I use GrapheneOS, but if you as a bank want to gate access to my money via some kind of technology, you better be including it as part of the account.
For example, HSBC continues to let me manage my bank account via the web browser, and continues to offer a battery powered hardware token as the means of authentication.
I let you hold my money, for whatever reason. Why do you expect me to be your distributed infrastructure provider? I am not going to let you require that I run your proprietary malware in order to access my own money.
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.
I'd say that JS webapps are the same but at least there you run things on your terms in a sandbox that you can inspect and look at the requests, and there's no effective enclave carved out of your hardware (except for EME but that's another topic for another day and I'd be complaining if banks started to use it too).
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.
True. Those who only care about meeting regulatory requirements are not going to care if the regulatory requirements cease to exist. Those who care about security may be dismissive of regulatory requirements, but they will do so primarily when they are insufficient or when they conflict with their opinion. In the former case, they probably have the ability to go beyond the regulatory requirements. In the latter case: while I won't claim that regulations are perfect, I would trust them over the an anonymous person who may be going on anything from their personal opinion to legitimate research.
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.
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.
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.
It's not Pixel only for no reason, there aren't any other phones which meet the rather sensible requirements at this moment. And even the latest Pixel phones have regressed.
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.
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.
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?
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.
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.
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.
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?
I have a living permit and legal status in the country I live in, but only few banks open accounts to people like me, most just deny anyone but citizens of the country.
The ones that open all work in GrapheneOS though, so not big deal for me in my particular case.
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.
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.
I'm surprised to see that in this thread. That's usually reserved for politics and arguments about AI.
While people might not be moved by data, it would be interesting if some more public information on what people actually use was available. Imagine data points like unpatched/unpatchable iOS or Android devices being multiple percentages, or outdated browsers. Similarly, the effort per app/OS combination; if it costs X to support Y configuration, then it would be somewhat easier to see if it's more about the will to do anything rather than real-world problems.
I use GrapheneOS, but if you as a bank want to gate access to my money via some kind of technology, you better be including it as part of the account.
For example, HSBC continues to let me manage my bank account via the web browser, and continues to offer a battery powered hardware token as the means of authentication.
I let you hold my money, for whatever reason. Why do you expect me to be your distributed infrastructure provider? I am not going to let you require that I run your proprietary malware in order to access my own money.
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.
I'd say that JS webapps are the same but at least there you run things on your terms in a sandbox that you can inspect and look at the requests, and there's no effective enclave carved out of your hardware (except for EME but that's another topic for another day and I'd be complaining if banks started to use it too).
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.
Ironic 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.
https://privsec.dev/posts/android/banking-applications-compa...
Looks like good progress to me.
https://privsec.dev/posts/android/banking-applications-compa...
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 ...