The limits of General Purpose Computation

android CyberSecurity LineageOS security · 9 comments · 600 words · Viewed ~330 times.

Should my bank be able to block me from using their Android app, just because my phone is rooted?

I'm reluctantly coming to the conclusion that... yeah, it's fair that they get to decide their own risk tolerance.

Sage of the Internet, and general Sooth Sayer, Cory Doctorow once gave an impassioned speech on "The Coming War on General Computation". I'll let you read the whole thing but, I think, the salient point is that some people want to restrict the maths we're allowed to do on our computers.

I can tell my computer to run any program and - to the best of its ability - it will⁰. This is the joy and promise of Universal Turing Machines.

But some wicked folks want to stop that. Usually it is Hollywood movie studios. Your computer is perfectly capable of playing back 4K streams from Netflix - but it is artificially restricted from doing so unless the computer can prove that it is "secure". Where secure means "artificially prevented from engaging in copyright infringement."

Similarly, you can't grab an Xbox disk and shove it in your PC to play a game. Your computer may be more powerful than an Xbox, but the software has been artificially restricted so that it won't work on a "General Purpose" computer - it will only play on an intentionally scuppered computer. The Xbox isn't a General Purpose computer - you cannot run your own code on it.

Which brings me on to Android Banking Apps. I have a six year old Android phone. In order to keep it secure, I've flashed it with LineageOS 20. But, in improving my day-to-day security, I've critically weakened some of the OS security.

I now have root control of my device. The bootloader is unlocked so I can load any software I want and have complete control of it.

This terrifies banks. And, I think, that's justified.

A modern phone is reasonably secure. It is unlikely¹ to be infected with a virus and, if it is, there are multiple layers of protection to stop miscreants monkeying with your money.

A rooted phone breaches all those protections. It is possible² that a user could install a tool (intentionally or otherwise) which could open the banking app and send all the money to a criminal. Or redirect the login flow to steal your passwords and authentication tokens. Or take screenshots of your balance and send them to blackmailers. Or... you get the idea.

Banks aren't willing to take that risk. Regulators tend to side with consumers in these matters and banks don't want to lose money or get bad press.

So they've taken the entirely sensible decision that their software will only run on machines which can pass a set of security attestations.

It distresses and upsets me that there's a cryptographic chip in my phone which I can't control. I bought and paid for this device. It should obey only my commands. It shouldn't rat me out to third party vendors.

But... I think it is a rational reaction from the banks. I am free to run whatever software I want on my general purpose computer - but they are free to refuse service to anyone who increases their liability.

Sure, it might be an emulator running slowly. Or my CPU might not have the requisite instruction set. But, in principle, it works. ↩︎
But not impossible. ↩︎
But not likely. ↩︎

9 thoughts on “The limits of General Purpose Computation”

2023-05-28 11:41

Roel said on mastodon.world:

@EdentThe trouble is then, who to trust. This is manorial trust, the world is unsafe and therefore we pray thatthe warlord in his manor protects us from evil ( but we are at his mercy). In this case the banks trust the big google+android warlord.

Reply | Reply to original comment on mastodon.world
2023-05-28 12:00

Hexorg said on techhub.social:

@Edent it’s a very similar problem with VAC secure games. VAC actually looks to see if you have some known cheating tools running and bans you if you do(among a ton of other heuristics). You already mentioned DRM and banking. At the end of the day the software authors need to be able to decide what branch of their software to run, and they need some sensing of your system. However, in case of DRM - the authors of the heuristics tend to err a lot on the safe side, as a result some of the legal/ethical things a user may want to do aren’t supported at which point some people go the pirate route. It seems we still didn’t manage to teach Hollywood that usability, not fear is a way to reduce piracy… hopefully banks will find a middle ground or we’re going to have [ovdc]BankOfAmerica_noroot.patched.arm64.apk.torrent

Reply | Reply to original comment on techhub.social
1. 2023-05-28 17:52
  
  DinoNerd says:
  
  As far as I can tell, the biggest "benefit" of DRM is making it impossible to create a reliable KVM. It's possible that my problems stem from an incompetent manufacturer - I haven't taken a protocol analyzer to the wretched thing - but my POS 2-monitor, 4-computer HDMI KVM regularly drops one or other of the two monitors when I switch computers; it also routinely drops the USB keyboard from one of the computers while I'm using it, without me switching comps. I never saw anything remotely like this with a succession of DVI KVMs, leading me to guess that the most likely root cause is HDMI complexity.
  
  Reply
2023-05-28 12:56

matt_panaro@octodon.social said on octodon.social:

@Edent 3 things I think are missing from this analysis: 1. it's not that root-access doesn't exist: it's that Google has it, but not you. You might try to argue that google is "more secure" than you are/an individual is: but history is replete with examples of security-compromises (or just accidental fuck-ups) in precisely that scenario; and security-considerations completely aside, it's a very effective form of vendor-lock-in.2. "arbitrary control" is almost never good security: the solution to "all my money is gone" isn't root-access restrictions, it's things like 2FA prompts on large transfers; or, since you're advocating for banks managing their risks, then the bank can choose not to allow more than some threshold of dollars to be transacted through the app at all (cf. ATM-withdrawal-limits).I think you're also looking at too narrow a scope: even if it's possible that the bank's risk is diminished & they're interested in that, innovation and improvement and competition in the entire mobile-computing-space is diminished by walled gardens: leading to losses a hell of a lot bigger than some measly bank's profits (not to mention the unquantifiable value of user-freedom, itself)

Reply | Reply to original comment on octodon.social
2023-05-28 12:59

sjmurdoch said on mastodon.social:

@Edent I mostly agree, but my follow up question is should a bank be able to refuse you as a customer if you don’t have a smartphone that meets their criteria. It used to be banks all offered hardware authentication devices but increasingly are pushing customers to apps, in some cases to the extent of refusing to take on customers unwilling or unable to use the app.

Reply | Reply to original comment on mastodon.social
2023-05-28 13:17

Jonathan Frederickson said on jawns.club:

@Edent I disagree. Of course from a bank's perspective they would love to know what software you're running on your device. But I don't think we should allow that level of control over their users! We shouldn't even provide them with mechanisms to do so

Reply | Reply to original comment on jawns.club
2023-05-28 17:41

DinoNerd says:

My bank recently made changes presumably intended to improve the security of their Android app, which have the side effect of reducing security on their web site.
The problem is that it's hard to type a decently secure password on a virtual keyboard. Their app previously recognized this by allowing me to set a less secure password for the app, that could be reliably typed on a cell phone, while keeping a more secure password on the web site. You had to provide the web password once, when setting up the app, and never again. Lesser password security on the app was OK with me, because a potential cracker would need physical possession of the phone - unlike with the web app.
They recently "fixed" this. Now the customer can choose between changing their password to something cell-phone appropriate, like "123"; getting locked out for repeated typos; buying an external keyboard for the cell phone; or not using the app. I'm thinking of returning to turning up at the branch with a stack of cheques to deposit, looking as elderly as possible, and when they try to get me to use the app, explaining that recent changes to it make it no longer work for me, or perhaps any other seniors.
I probably won't do that - too much like work, and I haven't so far gotten myself locked out - but it's a prime pain in the tail. The app won't accept the password direct from my password safe, unlike the web site, making this an even bigger nuisance.
But this just reinforces my belief that their security people are less than competent, and routinely score own goals at the expense of both the bank and its customers.

Reply
2023-05-28 16:51

Hippasus500@federate.social said on federate.social:

@matt_panaro @Edent To me, the crucial question is what ability do I have to chart my own course in this situation. The bank owners choose to bound how I access their services (and my money!). Do I choose to stay in business with this bank? Do other banks put the same limits on what I do with my phone?

Of course, the technical questions are interesting. But..

What we make of our lives is determined by how we choose to live.

Reply | Reply to original comment on federate.social
2023-05-28 18:51

Matthew Flint said on mastodon.me.uk:

@Edent I work on a banking app.We always need to consider that we’re running out code on several million untrusted devices.Sorry dude, but it’s a wonder that we’re allowed to do it at all, even for devices which claim to be unrooted.(Our cyber crew are very paranoid)

Reply | Reply to original comment on mastodon.me.uk
More comments on Mastodon.