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.
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.
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.
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?
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 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.
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.
Care to expand on Revolut's privacy invasion? Been using it as a secondary/tertiary account for 8+ years, and I haven't seen any specific intrusive practices, worse than in any other bank.
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?
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.
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".
Notice that requiring the attacker to use a phone doesn't do any good, because the attacker can just use a phone.
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?
Yes. Banks like Monzo allow you to import your other bank accounts into their app. I did it for a while, but ultimately I found it easier to just have separate apps for each. Most apps are very good and improving all the time, so usually one isn’t much better than the other.
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.
>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.
Maybe I misunderstood the point you were trying to make with your original comment, but you seemed to be suggesting that this piece of hardware could negate the risks (from the banks perspective), of allowing their apps to support non-secure devices. If your suggestion only applies to a very small subset of customers, then that doesn't allow them to put their app (which every customer can use), on the untrusted devices.
The existing customers of large banks who have hardware RSA devices are not "a very small subset of customers". Most of the customers who actually matter to the bank already have hardware devices, but with inferior cryptography and hardware aspects inferior to Trezor.
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.
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 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
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.
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.
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.
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.
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.
You can check what data is getting collected (e.g. decompile their distributed app at different versions), and you can - as a government - actually just go to their servers and check what they are doing (with necessary permits and lawful action), or even mandate them to show the source code.
> You can check what data is getting collected (e.g. decompile their distributed app at different versions)
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.
You seem to give too much credit for these companies and too less credit for governments.
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.
> 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).
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.
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.
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.
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?
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
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.
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.