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.

I don't think Google should be changing Android this way at all, and fear that it will later be used for evil. That said, I thought of an improvement:

Allow a toggle with no waiting period during initial device setup. The user is almost certainly not being guided by a scammer when they're first setting up their device, so this addresses the concern Google claims is driving the verification requirement. I'll be pretty angry if I have to wait a day to install F-Droid and finish setting up a new phone.

Evil, for the record would mean blocking developers of things that do not act against the user's wishes, but might offend governments or interfere with Google's business model, like the article's example of an alternative YouTube client that bypasses Google’s ads. Youtube is within its rights to try to block such clients, but preventing my device from installing them when that's what I want to do is itself a malicious act.

> Allow a toggle with no waiting period during initial device setup

I like this idea in principle but I think it could become a workaround that the same malicious entities would be willing to exploit, by just coercing their victims to "reset" their phones to access that toggle.

That wipes all the data on the device and requires logging back in to accounts. It seems to me that's high enough friction to resist most coercion.
Isn't app data, photos etc. usually synced with the Google account? Besides, Google claims that the scammers are using social engineering to create a feeling of panic and urgency, so I think the victim would be willing to reset and log in to the accounts again in such a frame of mind.

Some is, some is optional, some isn't.

I'm sure there's a hypothetical scenario where someone successfully runs a scam that way, but there's also a hypothetical scenario where a 24 hour wait doesn't succeed at interrupting the scam.

The perfect is the enemy of the good.
Which applies just the same to the hypothetical option during initial device setup.
I don't think it does because of the workaround I mentioned upthread.
The victim also can't be on the phone with the scammer using that device during the setup process. We're talking about a very high-friction scenario.
None of this is stopping a malicious entity. We keep trying to use tech (poorly thought out tech at that) to solve issues of social engineering. And no one is asking for a solution, either; it's being jammed in for control.