Android developer verification: Balancing openness and choice with safety

News and insights on the Android platform, developer tools, and events.

Android Developers Blog

At this point I'm convinced that there's something deeply wrong with how our society treats technology.

Ruining Android for everyone to try to maybe help some rather technologically-hopeless groups of people is the wrong solution. It's unsustainable in the long run. Also, the last thing this world needs right now is even more centralization of power. Especially around yet another US company.

People who are unwilling to figure out the risks just should not use smartphones and the internet. They should not use internet banking. They should probably not have a bank account at all and just stick to cash. And the society should be able to accommodate such people — which is not that hard, really. Just roll back some of the so-called innovations that happened over the last 15 years. Whether someone uses technology, and how much they do, should be a choice, not a burden.

I was always under the impression security was a red herring and the real reason was control. Google wants to own the device and rent it to users with revocable terms the same way SaaS subscription software works. Locking down what can run is a key step in that process

I worked at a bank on the backend for architecture and security.. and I've posted this attestation here before, but the sheer volume of fraud and fraud attempts in the whole network is astonishing. Our device fingerprinting and no-jailbreak-rules weren't even close to an attempt at control. It was defense, based on network volume and hard losses.

Should we ever suffer a significant loss of customer identity data and/or funds, that risk was considered an existential threat for our customers and our institution.

I'm not coming to Google's defense, but fraud is a big, heavy, violent force in critical infrastructure.

And our phones are a compelling surface area for attacks and identity thefts.

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.