0xedbGoogle details new 24-hour process to sideload unverified Android apps
https://android-developers.googleblog.com/2026/03/android-de...
The forced ID for developers outside the Play store is already killing open source projects you could get on F-Droid. The EU really needs to identify this platform gatekeeping as a threat. As an EU citizen I should not be forced to give government ID to a US company, which can blacklist me without recourse, in order to share apps with other EU citizens on devices we own.
The DSA covers App stores with a large numbers of users - this is about allowing users side load unsigned apps. Afaik there is no requirement to identify the developers of applications that can be installed on a vendors platform (outside the app store). Otherwise Microsoft would require Government ID to compile and email someone an EXE.
[dead]
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.
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.
Scammers already will spend multiple days on a scam call. Watch some Kitboga videos, he'll strings them along for a week.
"Google will call you again tomorrow to get you your refund."
There, we've successfully circumvented all of Google's security engineering on this "feature."
Check out this A&E Intervention episode for Greg. They have continuously worked this guy over for months.
https://youtu.be/YIR-nJv_-VA?t=121
They don't mind being patient when they have dozens of other victims in the wait queue.
Intervention: Greg’s Painkiller Addiction and Gambling Obsession Lead to Massive Debt | A&E
This is obvious to anyone with a brain. I'm not familiar with scam logistics or the videos you mentioned, and the exact same line you put in quotes is what first came to my mind.
tl;dr of this post is that Google wants to lock down Android and be its gatekeeper. Every other point of discussion is just a distraction.
Brother, there's an entire genre of scamming where the scammers spend months building rapport with their victims, usually without ever asking for anything, before "cashing out". One day is nothing.
Wouldn't a wait time like 2 hours with some jitter make it more difficult for a scammer to pursue the case? People aren't going to be willing to stay on the phone for hours at a time. With 24 hour wait, the scammer could just schedule another call for the next day.
>People aren't going to be willing to stay on the phone for hours at a time.
"Okay, come back to me in a few hours and we'll continue"
Remember, these are already people who took the time to respond. They are invested.
Right, this friction makes it much harder for a scammer to get away with saying something like, "wire me $10,000 right now or you won't see your child ever again!" as the potential victim is forced to wait 24 hours before they can install the scammer's malicious app, thus giving them time to think about it and/or call their trusted contacts.
The sheer arrogance that you think someone manipulated successfully will just re-think the situation and ask their friends/family. The naivety to assume all scammers are impulsive fools and don't do this for a living, as their primary line of work.
So Google's going to add some nonsense abstraction layer and when this fails to curb the problem after a 24 hour wait, it will be extended more maybe a week, and more information must be collected to release it. We all know how this goes.
Potencial victim's AI agents will wait patiently those 24 hours. In fact it may just wait exactly 24 hours and not one more second.
I think the more important aspect is that people will have 24h to slow down, think, and realize that they are being scammed. Urgency and pressure is one of the top tactics used by scammers.
Scammers will definitely call back the next day to continue. But it is quite possible that by then the victim has realized, or talked to someone who helped them realize that they are being scammed.
There's been some reporting recently where I live about a case of some woman being scammed.
She went to a bank to transfer the scammer money. They told her no. She came back the next day. The police got involved and explained everything to her. Then she came back the next day. After that, she apparently found another location which let her transfer the money.
There's basically zero chance a 24 hour (or any amount of a) cool off period will help these people.
Just because you have one example of someone who would not realize doesn't mean that the number of people who would realize is zero.
It's not one example. The scammers purposefully target people like these. That's their business.
Like, I'm sure there's a small amount of people who normally wouldn't get scammed but fall for it in a panic. But, is that really such a big concern for Google that they absolutely must continue stripping user freedoms from us? Is the current 30s popup which needs 3 confirmations not enough? Will the new one really work?
Yes the most likely to fall are going to be targeted, but if you make that group of people 90% smaller with a delay that is still beneficial.
Whether the feature is beneficial overall is a different story. But helping some people is great even if it doesn't help everyone.
> helping some people is great even if it doesn't help everyone
It's kind of funny, but I very much agree with this. It's just in this case, it's hurting everyone (in ways most don't even realize) so that you can help a few people.
It's like putting everyone in prison, because some people might commit a crime and this would save some victims. A bit of an overreaction, no?
I'm not convinced it's 90% smaller.
>Whether the feature is beneficial overall is a different story.
It's the entore story in my eyes. Hell paved with good intentions (and I don't even think Google's intentions are good).
> - 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?
What apps are those? I've yet to run into any of my banking apps that refuse to run with developer mode enabled. I've seen a few that do that for rooted phones but that's a different story. I've been running android for a decade and a half now with developer mode turned on basically the whole time and never had an app refuse to load because of it.
Wero in Europe. It's really insane. They make wero to make us less dependent on US tech and then hamstring it in this way.
I can use Wero just fine in my banking app. Can't try the app that's called Wero in the Play store because it just directs me to my banking app. But I can open it at least ...
Philippines' most popular e-wallet app GCash outright closes when the developer mode is enabled with the popup saying that the device has "settings [enabled] that are not secure".
Just summarizing the apps below it seems to mostly be banking/payment and government apps specifically outside the US that break under developer mode and sometimes even accessibility access.
I wonder what makes them less trustful of Android security. AFAIK there are still pretty hard limits to what you can do inside apps you did not create. US companies at least seem comfortable with their security even with Developer or accessibility apps enabled.
>- 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.
> “For a lot of people in the world, their phone is their only computer, and it stores some of their most private information,” Samat said.
Not applying the policy to adb installs makes a lot more sense if the people this is trying to protect don't have a computer
If you mean things like Shizuku or local adb connection through Termux, it's quite an awkward process to set up even for someone like me who's been building Android apps since 2011. Like, you can do if you really really need it, but most people won't bother. You have to do it again after every reboot, too.
Scammers will figure something out to help that workflow smoother, you can count on that.
People who want your money always want to have really great UX. I remember how painless buying lottery tickets online was, it was the smoothest checkout experience in all of online shopping I have ever done.
I've seen a few apps that run locally on Android and hook into the ADB connection over loopback networking to do certain things.
This just adds the step of "download Cool ABD Installer from the play store" to the set of directions I would think.
Google could easily put an end to that if they wanted. Just block adb access from the loopback address and VPN. I'm surprised this isn't already in place. The setup flow for those apps you're referring to is awkward enough that it's clear it was never intentional to be able to access adb on-device.
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.
scrcpy can already do that.
Why do you keep harping on about ADB installs. That's not helpful. It doesn't help me install open source apps from FDroid. It's ridiculous that you think booting up a computer and using ADB is a reasonable workaround. It isn't.
You would be able to install f droid and it's apps without going through this flow.