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

The one-day waiting period is so arbitrary. Have they demonstrated any supporting data? We know google loves to flaunt data.

Something like Github's approach of forcing users to type the name of the repo they wish to delete would seem to be more than sufficient to protect technically disinclined users while still allowing technically aware users to do what they please with their own device.

> The one-day waiting period is so arbitrary.

Scammers aren't going to wait on the phone for a day with your elderly parent.

Sure, but what about a 30 minute delay? 1 hour? 2 hour?

24 is just so long.

But also, my expectation is that a scammer is going to just automate the flow here anyways. Cool, you hit the "24 hour" wait period, I'll call you back tomorrow, the next day, or the next day and continue the scam process.

It might stop some less sophisticated spammers for a little bit, but I expect that it'll just be a few tweaks to make it work again.

24 hours is long enough to get them off the phone, and potentially talking to other people who might recognize the scam.

There will be some proportion of people who mention to their spouse/child/friend about how Google called them to fix their phone, and are saved by that waiting period.

Exactly - the idea is to make it harder for scammers to create a false sense of urgency.
This is too long. It's Google locking in users with hostile user practices.

Sure, but wouldn't 35 hours do the same trick? Or 5 hours? Or 10 hours and 28 minutes? :)

The question is, why exactly 24 hours? The argument is that the time limit is set to protect the users and sacrifice usability to do so. So it would be prudent to set the time limit to the shortest amount that will protect the user -> and that shortest amount is apparently 24 hours, which is rather.. suspiciously long and round :)

You've got to pick some time value (if you choose this route at all), and if the goal is to prevent urgency-coercion it needs to be at least multiple hours. An extremely-common-for-humans one seems rather obvious compared to, like, 18.2 hours (65,536 seconds).

Unless you want to pick 1 week. But that's a lot more annoying.

Well, I guess 24 hours gives a good change to include at least one window where a vulnerable person might be able to speak with a trusted contact.

Someone who lives in another timezone or works weird hours etc. Our routines generally repeat on 24hour schedules, so likely to be one point of overlap.