Comment by josephg
4 days ago
I wish we had technical solutions that offered both. For example, a kernel like SeL4, which could directly run sandboxed applications, like banking apps. Apps run in this way could prove they are running in a sandbox.
Then also allow the kernel to run linux as a process, and run whatever you like there, however you want.
Its technically possible at the device level. The hard part seems to be UX. Do you show trusted and untrusted apps alongside one another? How do you teach users the difference?
My piano teacher was recently scammed. The attackers took all the money in her bank account. As far as I could tell, they did it by convincing her to install some android app on her phone and then grant that app accessibility permissions. That let the app remotely control other apps. They they simply swapped over to her banking app and transferred all the money out. Its tricky, because obviously we want 3rd party accessibility applications. But if those permissions allow applications to escape their sandbox, and its trouble.
(She contacted the bank and the police, and they managed to reverse the transactions and get her her money back. But she was a mess for a few days.)
> (She contacted the bank and the police, and they managed to reverse the transactions and get her her money back. But she was a mess for a few days.)
And this almost certainly means that the bank took a fraud-related monetary loss, because the regulatory framework that governs banks makes it difficult for them to refuse to return their customer's money on the grounds that it was actually your piano teacher's fault for being stupid with her bank app on her smartphone (also, even if it were legal to do so, doing this regularly would create a lot of bad press for the bank). And they're unlikely to recover the losses from the actual scammers.
Fraud losses are something that banks track internally and attempt to minimize when possible and when it doesn't trade-off against other goals they have, such as maintaining regulatory compliance or costing more money than the fraud does. This means that banks - really, any regulated financial institution at all that has a smartphone app - have a financial incentive to encourage Apple and Google to build functionality into their mass-market smartphone OSs that locks them down and makes it harder for attackers to scam ordinary, unsophisticated customers in this way. They have zero incentive to lobby to make smartphone platforms more open. And there's a lot more technically-unsophisticated users like your piano teacher than there are free-software-enthusiasts who care about their smartphone OS provider not locking down the OS.
I think this is a bad thing, but then I'm personally a free-software-enthusiast, not a technically-unsophisticated smartphone user.
> And this almost certainly means that the bank took a fraud-related monetary loss, because the regulatory framework that governs banks makes it difficult for them to refuse to return their customer's money on the grounds that it was actually your piano teacher's fault for being stupid with her bank app on her smartphone
In which country? This happened in Australia. The rules are almost certainly different from the US.
That's the cost of business for the bank using an app. If they don't like it, they can try a different business model, like payment cards. The cost of having an app should be borne by the bank who decided all its customers would have to have an app.
For me the answer is separate devices. I have an iphone which is locked down and secure. I have my banking and ID apps on it but I can't mod it however I want. Then I have a steam deck and raspberry pi I have entertainment and whatever I want on. I can customise anything. And if it gets hacked, nothing of importance is exposed.
> . For example, a kernel like SeL4, which could directly run sandboxed applications, like banking apps. Apps run in this way could prove they are running in a sandbox. ... Then also allow the kernel to run linux as a process, and run whatever you like there, however you want.
This won't work. It's turtles all the way down and it will just end up back where we are now.
More software will demand installation in the sandboxed enclave. Outside the enclave the owner of the device would be able to exert control over the software. The software makers don't want the device owners exerting control of the software (for 'security', or anti-copyright infringement, or preventing advertising avoidance). The end user is the adversary as much as the scammer, if not more.
The problem at the root of this is the "right" some (entitled) developers / companies believe they have to control how end users run "their" software on devices that belongs to the end users. If a developer wants that kind of control of the "experience" the software should run on a computer they own, simply using the end user's device as "dumb terminal".
Those economics aren't as good, though. They'd have to pay for all their compute / storage / bandwidth, versus just using the end user's. So much cheaper to treat other people's devices like they're your own.
It's the same "privatize gains, socialize losses" story that's at the root of so many problems.
Good point. I didn't think of that.
It may still be an improvement over the situation now though. At least something like this would let you run arbitrary software on the device. That software just wouldn't have "root", since whatever you run would be running in a separate container from the OS and banking apps and things.
It would also allow 3rd party app stores, since a 3rd party app store app could be a sandboxed application itself, and then it could in turn pass privileges to any applications it launches.
It's what we have now.
I can run an emulator in the browser my phone and run whatever software I want. The software inside that emulator doesn't get access to cool physical hardware features. It runs at a performance loss. It doesn't have direct network access. Second class software.
3 replies →
The problem is it's quite easy to poke holes in a sandbox when you're outside the sandbox looking in, especially when the user is granting you special permissions they don't understand. These apps aren't doing things like manipulating the heap of the banking app, they are instead just taking advantage of useful but powerful features like screen mirroring to read what the app is rendering.
The banking app has no password or 2FA prompt before opening? Even if the 2FA has to come from Authenticator/Authy/etc , that should atleast have a password on it. What am I missing here?
Yes, sandboxing is a technological protection, but once you have important data flowing we often don't have technological protections to prevent exfiltration and abuse. The global nature of the internet means that someone who publishes an app which abuses user expectations (e.g. uses accessibility to provide command and control to attackers) is often out of legal reach.
You also have so much grey area where things aren't actual illegal, such as gathering a massive amount of information on adults in the US via third party cookies and ubiquitous third party javascript.
Thats why platforms created in the internet age are much more opinionated on what API they provide to apps, much more stringent on sandboxing, and try to push software installation onto app stores which can restrict apps based on business policy, to go beyond technological and legal limitations.
> As far as I could tell, they did it by convincing her to install some android app on her phone and then grant that app accessibility permissions.
Did she make it through the non-google play app install flow?
I think all the software the scammers used was in the google play store. I don't think they sideloaded anything.
But I'm not entirely sure. I wasn't there, and she's not tech literate. She was so rattled when I spoke to her about it that it was hard to get a clear story out of her about what happened.
Web browsers already handle sandboxing
Don't know why this was downvoted. Some people prefer to access online services from the safety of a web browser sandbox than through an always-installed wrapper app.