Android developer verification: Balancing openness and choice with safety

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

Android Developers Blog

This is going to hurt legitimate sideloading way more than actually necessary to reduce scams:

- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?

- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need. This kills the pathway for new users to sideload apps that have similar functionality to those on the Play Store.

The rest -- restarting, confirming you aren't being coached, and per-install warnings -- would be just as effective alone to "protect users," but with those prior two points, it's clear that this is just simply intended to make sideloading so inconvenient that many won't bother or can't (dev mode req.).

>- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?

Hi, I'm the community engagement manager @ Android. It's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.

If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.

>- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need.

ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.

> ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.

Someone is just going to make a nice GUI application for sideloading apks with a single drag-and-drop, so if your idea is that ADB is a way to ensure only "users who know what they're doing" are gonna sideload, you've done nothing. This is all security theatre.

The scammers don't even need to make a GUI, they just need to get you to enable adb-over-tcp and bridge that to their network somehow - an ssh client app would do the trick.
How many people do you suspect are gullible enough to fall for these scammers but also competent enough to install an SSH client and enable port-forwarding for an ADB proxy? Like fifteen people worldwide?
How many people are gullible enough right now to plug a phone to a laptop over USB and execute an exe on an operating system with no sandboxing at all? ADB even seems to work over webusb. (at that point you may as well give up on hacking the phone, but I digress). That's exactly why I believe the problem is more complicated and why Google's solution is not really fixing anything, not for the users.
There's going to be a lot of people who don't have a laptop/desktop handy right now - because they're out of the house, because it's unplugged in a cupboard, or because they borrow it from a friend or use an internet cafe when they need that. So a requirement to use that and connect your phone to it is effectively similar to the 24 hr waiting period: time to think, time to mention it to a friend who's heard about this scam before. This is why phones are such an attractive target in the first place.