Around a dozen banking apps began specifically permitting GrapheneOS
grapheneos.social
grapheneos.social
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.
Companies tend not to do illegal things. Especially if they’re public or have shareholders that might lose significant value if found out. And it’s borderline impossible to stop people finding 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.
Which only helps if you're trying to prevent them from collecting the data rather than use it for a given thing, which is the thing they're not doing.
As an obvious example, if they keep all your files/messages on their cloud storage by default, they have all your files/messages by default.
> and you can - as a government - actually just go to their servers and check what they are doing (with necessary permits and lawful action)
Which generally only happens when you have reason to suspect they're doing something, which is the thing you wouldn't have when they're the only ones who know that they're doing it.
And even if you do go to look at the servers they have in your jurisdiction, there is no way to tell that the data hasn't been copied to servers outside of your jurisdiction, or what is happening to it over there.
First of all, most companies just want to make money, with minimal risk. It's significantly easier to make money when you are at worst doing grey area stuff and stay mostly legal (or even "better" is to lobby your thing into being legal). And any info known by more than 2 people is no longer a secret, and you ain't paying enough to your employees to lie under oath for their employer. So no, I don't believe it's happening all too often, and even if it does happen it's mostly out of ignorance, not a deliberate attempt to go against the law.
Look at the stuff Apple does, openly and in front of everybody, in response to laws they don't like, e.g. EU DMA. Now what is a scummy surveillance corporation going to do in the face of a law which there is no easy way to tell if they're violating?
> And any info known by more than 2 people is no longer a secret, and you ain't paying enough to your employees to lie under oath for their employer.
Consider how a large company works. Suppose as many as 95% of the employees are honest and/or risk-averse. Those 95% don't do it. When the remaining 5% do it without even being asked to because it's the thing that makes number go up and number going up is what gets them a bonus, they aren't going to tell on themselves and the other 95% don't even know that it's happening. Really the other >99% because 5% of people being willing to do it doesn't require 5% of people to be in on it.
> even if it does happen it's mostly out of ignorance, not a deliberate attempt to go against the law.
Getting screwed by ignorance rather than malice is still getting screwed.
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.
But there should always be at least one bank which can give you what you want, whatever that is. There are dozens to choose between if you're banking in USD or EUR.
Americans in these threads recommending switching banks are often unaware of how the USA is a relative outlier when it comes to diversity of banking. A lot of that is due to the rather distinctly American concept of the credit union. But within corporate banking, even the USA has seen successive mergers and some decline in choices.
"Oh no! My employer doesn't allow me!"
"Oh no! My tax collector doesn't allow me!"
"Oh no! My government doesn't allow me!"
If you're a free man you do what you want, and the rest is their problem. If you're a thrall, you aren't allowed to be on the internet unless you show me a permission paper from your lord.
I'm a bit mocking, because it is such a silly trait among many (mainly Northern) Europeans to have a total thrall mentality when it comes to their banks.
In the real world, there is no problem at all for you to open a EUR account in a number of foreign EUR banks. Your employer pays to an IBAN account just like if you had a national bank. Your income is declared just as normal, because it doesn't matter one bit in which country the bank account is and tax authorities don't ask. That's how it functions in reality, and people claiming anything else are either uninformed or just spreading their mommies old boogey man tales.
Moreover, you aren't considering that some countries have BankID systems for everything from tax matters to accessing healthcare, and that only works with a local bank account (so much so that people moving from other EU countries are commonly shut out of everything for weeks until their local bank ID comes through).
People may prefer a foreign bank for any and every good reason besides mobile OS nerding, and that's nobody's business. Certainly not your employers business.
As for BankID, I know of it and it might just as well be called ThrallID from how ridiculous and pathetic it is that people would let their IDs be controlled and owned by private banks. You must admit that it's nothing to be proud of.
You can also keep your national bank account for your salary and ThrallID if you want to, and just transfer all your money to a foreign account every time you get your paycheck. That way your money is also a whole lot safer, and you get some better peace of mind.
Also, theory and practice are very different. While I agree you can fight back for your rights, I remember having contacted different kind authorities for 7 months because a company was rejecting my SEPA IBAN. Unfortunately, that was the only company I could use for that mandatory service, and after they got fined, they happily continued accepting only national IBANs.
The result has been months of frustration, endless calls/appointments with authorities to gain nothing. If I could go back, I would give them a different IBAN, even if on a theory level they were wrong.
They take you to court for not paying tax. You provide the judge with evidence that you actually did pay tax, but the tax office refunded it back to your account. The tax office looks very silly and the judge orders them to either accept the payment or waive the tax.
Nobody would move all their money out of the country they live in.
Just because you haven't considered it doesn't make it anything strange or "bad faith" or "out of spite". People ate sushi before you ever heard of it.
Continuing to patronize a business that will not sell you a product you want is being a pushover. The flip side is if a business is in the custom of only providing certain services to those who threaten to leave, then they shouldn't be surprised when people threaten to leave in order to receive good service.
I suspect that you live in Canada, which has the banking oligopoly that leads to banks not giving a shit, and customers that are used to banks not trying. If more people were willing to take their money and walk, Canadian banking would probably suck less ass.
Just because there are juggernauts ("the big five/six") doesn't mean it's an oligopoly. This isn't like telecom where there are only 3 choices (4 in some provinces) and nobody else can enter the game because it costs too much.
The existence of Credit Unions and small banks that offer similar but limited service does not negate the pricing power of Canadian banks. E.g. in most other modern countries paying $17-$35/mo for a checking account is not normal. In Canada that is just what every major bank charges for a checking account.
its also worth highlighting that many of the "options" in Canada are just online only brands of the big 6.
So is it now their official policy that to have a bank account with them you must own a phone that can run their app?
I really don't get how your excuse worked, but I am guessing this is a made up policy and the fact it's a charity made them think twice about being assholes about this.
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.
It's RFID communication with a smart card. The bank would have to transmit keys to your computer to be able to interface with it, which they probably won't want to do for security reasons.
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 that part of the game.
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 (or forced basically) 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, 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.
Android app/os attestation on the other side is a complete lockdown that prevents you from creating your own apps on top of server side apis the original mobile apps use.
...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
Exactly, VCRs should be banned -- why should cable companies tailor to you how they do business, and be forced to allow you to plug in anything into their distribution network? Only approved TVs should be an option.
Hopefully people are educated about that fact before they purchase said TV, though.
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.
At what number would you consider this to be more than "very little competition"?
The European Union has tried to create a pan-European banking market for a long time without success. Banks are still a national business, even if banks themselves operate internationally you always do business with their local prescence. In theory you could keep your accounts in another country, in practice that is a massive headache.
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.
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?
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.
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.
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.
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".
Notice that requiring the attacker to use a phone doesn't do any good, because the attacker can just use a phone.
I haven’t looked for a one-app-to-rule-them-all, but in principle it’s possible.
I think the UK banking sector is in rude health. It’s very competitive and it’s easy to move. The quality of the apps is very much part of any competitive advantage.
I have accounts with four uk banks and it’s trivial to manage them. It’s an example of legislation working really well.
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.
Boomers don't generally have Trezor wallets. Many millennials who aren't in the "failed to launch" category have a Trezor wallet or something similar, as do gen Z.
A Pixel running GrapheneOS is hardly a "non secure" device. As a user, I'm not naive enough to consider iOS or lamestream Android to be "trusted", which is why I run GrapheneOS.
If a bank's app runs on iOS or lamestream Android, but not GrapheneOS, it's not because those operating systems that aren't GrapheneOS are more "trusted", it's because the CTO of the bank is a fucking moron.
Trezor runs open source firmware. Solving the problem with a Trezor is what I want and what most loosely in the category of "hacker" want. Every legitimate IT pro will prefer, for securing their own bank account, this approach over another.
Whatever bank can set whatever threshold they want.
If they want to require a signature from a hardware wallet where their app runs on an unrecognized OS or for a Zelle transaction over $3,000 then they can specify whatever details they want in software at the speed of software. Banks already tune thresholds unique to customer's individual risk profiles.
As has already been widely demonstrated with some of the hardware keys in the Yubikey 5C family, users don't lose their hardware keys/wallets when they are attached to their physical key ring for house key/fob and car key/fob etc. Users cycle through or lose smartphones all the time but "muh keys" not so much.
In the United States, users of Chase are already using FIDO2 to access their Chase accounts with hardware keys often priced at $15 or $20 made by a diverse set of 3rd party vendors such as Yubico, which has the same cryptography-grounded effects I suggested above. One hardware key can store private keys for several remote sites, this is a basic part of FIDO2.
Before Chase did this, I directly kvetched at Chase on LinkedIn pointing out that many smaller banks had already been securing access to accounts with FIDO2.
Trezor and Yubikey 5C devices happen to also do FIDO2, but the ultimate answer that provides end-to-end cryptography, meaning the cryptographic pieces reach all the way to the record matching the actual contents of the transaction stored at the bank, uses a different format. The legacy tokens never provided end-to-end cryptography, 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
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.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.
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.
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.
I don't know why some of my comments are being shadowbanned. It might be an AI filter gone awry.
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.
German courts are not bound by precedent in the same way as US courts and you're referring to a specific case in Germany which cannot be broadly applied.
AOSP ships a lot of GPLv2 code (Linux kernel and OpenJDK libraries among other components) but doesn't use GPLv3 for multiple reasons.
AOSP used to use a lot of GPLv3 code as part of the toolchain for building AOSP but that was replaced with LLVM, ToyBox and other permissively licensed projects.
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. Our focus is mainly on the Play Integrity API because it's the only relevant system resulting in compatibility issues in practice. We don't have to worry about Apple's App Attest API and we aren't aware of any app banning GrapheneOS with the Android key attestation API.
We've convinced dozens of apps to drop using attestation with user pressure. We've also convinced a much smaller number of apps to at least permit GrapheneOS and other alternatives chosen by them with the Android key attestation API instead of only permitting Google-certified operating systems. We aren't aware of any app using the Android key attestation API in a way which reduces compatibility since apps generally only use the Play Integrity API and have to be convinced to either drop it or at least use an alternative where they can permit non-stock operating systems based on verified boot key hash and non-Google roots of trust.
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.
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.
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.
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.
https://privsec.dev/posts/android/banking-applications-compa...
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
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 do not have any banking apps, and I log into a bank account maybe once in month or less often.
Apps are not required to use the Play Integrity API or a similar attestation API. The details of what they're required to do are unspecified and open ended. Many are interpreting it as meaning they use the Play Integrity API and we have to convince each one to permit GrapheneOS via the Android attestation API. It's not good and we would greatly prefer if this wasn't happening even if we were managing to convince most apps to permit GrapheneOS.
Not only these features. Viewing PIN, enabling bank cards for internet purchases, enabling/disabling cards.
https://privsec.dev/posts/android/banking-applications-compa...
Looks like good progress to me.
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?
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.
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)
They want to stop people from using tampered or fake versions of their app which could be tricking the user into doing things. They also want to enforce using a device with a mandatory app sandbox and some level of security patches/protections intact. Most aren't willing to ban using highly insecure Android devices which haven't received security patches for many years, but it's trending in that direction.
Around 90% of banking apps are currently compatible with GrapheneOS. It would likely be more like 50% if we hadn't put a lot of effort into improving compatibility with a lot of workarounds for the bugs and problematic anti-tampering checks done by these apps. It would be closer to 20% if we not only didn't have that but also didn't have our sandboxed Google Play compatibility layer feature.
The remaining apps not compatible with GrapheneOS is mainly due the Play Integrity API device and strong integrity levels enforcing having a Google certified device running the unmodified stock OS. Google doesn't allow GrapheneOS to be certified. Certification also disallows many of our privacy and security features. It also isn't compatible with providing fast security updates and would waste substantial resources as it does for Android OEMs. Those apps need to be convinced to stop using the Play Integrity API or to use the Android hardware attestation API provided as part of key attestation to verify the hardware, OS and app are genuine. The latter only solves it for operating systems and hardware they choose to permit.
Zelle does work on GrapheneOS via many banking apps. It isn't clear why it wouldn't work for that app when it works in others and no one has investigated it.
Most banking apps around the world only support Google Pay and Apple Pay for tap-to-pay on a smartphone. Google Pay bans using GrapheneOS so that's why tap-to-pay on GrapheneOS is only available in regions with alternatives to Google Pay. Europe has Curve Pay, PayPal tap-to-pay and many banks implementing their own tap-to-pay. That site currently doesn't list whether an app has their own working tap-to-pay or similar additional details.
https://privsec.dev/posts/android/banking-applications-compa...
All of the ones relevant to me, just work fine.
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.
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.
But they are explicitly changing their terms: https://discuss.grapheneos.org/d/17714-revolut-mobile-financ...
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.
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'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?"
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.