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.

Yes; I think that's the real impasse here. As I say, I think there is a middle ground where the device owners keep the keys, but programmers can run whatever software they want within sandboxes - including linux. And sandboxes aren't just "an app". They could also nest, and contain 3rd party app stores and whatever wild stuff people want to make.

But a design like this might please nobody. Apple doesn't want 3rd party app stores. Or really hackers to do anything they don't approve of. And hackers want actual root.

Its not what we have now, for the reasons you list. Web software runs slowly and doesn't have access to the hardware.

SeL4 and similar sandboxing mechanisms run programs at full, native speed. In a scheme like I'm proposing, all software would be sandboxed using the same mechanism, including banking apps and 3rd party software. Everything can run fast and take full advantage of the hardware and all exposed APIs. Apps just can't mess with one another. So random programs can't mess with the banking app.

Some people in this thread have proposed using separate devices for secure computing (eg banking) and "hacking". That's probably the right thing in practice. But you could - at least technically - build a device that let you do both on top of SeL4. Just have different sandboxed contexts for each type of software. (And the root kernel would have to be trusted).

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.

> 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.

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.)