In Google's announcement in Nov 2025, they articulated a pretty clear attack vector. https://android-developers.googleblog.com/2025/11/android-de...
> For example, a common attack we track in Southeast Asia illustrates this threat clearly. A scammer calls a victim claiming their bank account is compromised and uses fear and urgency to direct them to sideload a "verification app" to secure their funds, often coaching them to ignore standard security warnings. Once installed, this app — actually malware — intercepts the victim's notifications. When the user logs into their real banking app, the malware captures their two-factor authentication codes, giving the scammer everything they need to drain the account.
> While we have advanced safeguards and protections to detect and take down bad apps, without verification, bad actors can spin up new harmful apps instantly. It becomes an endless game of whack-a-mole. Verification changes the math by forcing them to use a real identity to distribute malware, making attacks significantly harder and more costly to scale.
I agree that mandatory developer registration feels too heavy handed, but I think the community needs a better response to this problem than "nuh uh, everything's fine as it is."
A related approach might be mandatory developer registration for certain extremely sensitive permissions, like intercepting notifications/SMSes...? Or requiring an expensive "extended validation" certificate for developers who choose not to register...?
Permissions are a great way to distinguish.
Or would you be OK knowing that Thunderbird you downloaded from https://thunderbird.net/ is signed by the thunderbird.net certificate owner?
The permissions approach isn't bad. I may trust Thunderbird for some things, but permission to read SMS and notifications is permission to bypass SMS 2FA for every other account using that phone number. It deserves a special gate that's very hard for a scammer to pass. The exact nature of the gate can be reasonably debated.
In contrast, convincing someone to read an OTP over the phone is a one-time manual bypass. To use your logic..
A insalled app - Like a hidden camera in a room.
Social engineering over phone - Like convincing someone to leave the door unlocked once.
The motivating example as described involves "giving the scammer everything they need to drain the account". Once they've drained the account, they don't need ongoing access.
Why would an app silently intercepts SMS/MMS data ? Why does an app needs network access ?
Running untrusted code in your browser is also "a persistent technical compromise" but nobody seems to care.
The sideloading warning is much much milder, something like "are you sure you want to install this?".
> Please enter the code we sent you in the app.
lol, lmao even
This reeks of "think of the children^Wscammed". I mean, following this principle the only solution is to completely remove any form of sideloading and have just one single Google approved store because security.
> A related approach might be mandatory developer registration for certain extremely sensitive permissions, like intercepting notifications/SMSes...? O
It doesn't work like that. What they mean with "mandatory developer registration" is what Google already does if you want to start as a developer in Play Store. Pay 25$ one-time fee with a credit card and upload your passport copy to some (3rd-party?) ID verification service. [1] In contrast with F-Droid where you just need a GitLab user to open a merge request in the fdroid-data repository and submit your app, which they scan for malware and compile from source in their build server.
[1] but I guess there are plenty of ways to fool Google anyway even with that, if you are a real scammer.
Just like they went after Samsung for adding friction to the sideload workflow to warn people against scams.
https://www.macrumors.com/2024/09/30/epic-games-sues-samsung...
You can also cut yourself with a kitchen knife but nobody proposes banning kitchen knives. Google and the state are not your nannies.
oh nice, i love this game.
you cant carry a kitchen knife that is too long, you cant carry your kitchen knife into a school, you cant brandish your kitchen knife at police, you cant let a small child run around with a kitchen knife...
literally most of what "the state" does is be a "nanny"
(not agreeing or disagreeing with google here, i have no horse in this particular race. but this little knife quip is silly when you think about it for more than 5 seconds)
What?
although, i would imagine at some length, it becomes a "sword" (even if marketed as a knife) and falls under some other "nanny"-ing. i have not googled that.
So, having been given the proverbial inch (or centimeter), those obsessed with banning potentially-dangerous tools are trying to take the next mile (or kilometer): https://theconversation.com/why-stopping-knife-crime-needs-t...
There is a point at which people have to think critically about what they are doing. We, as a society, should do our best to protect the vulnerable (elderly, mentally disabled, etc) but we must draw the line somewhere.
It’s the same thing in the outside world too - otherwise we could make compelling arguments about removing the right to drive cars, for example, due to all the traffic accidents (instead we add measures like seatbelts as a compromise, knowing it will never totally solve the issue).
Manually installing an app might be close to the limit of what grandma can be coached through by an impatient scammer.
Multiple steps over adb, challenges that can't be copy and pasted in a script, etc. It can be done but it won't provide as much control over end user devices.
Because I hope you realize that clamping down on “sideloading” (read: installing unsigned software) on PCs is the next logical step. TPMs are already present on a large chunk of consumer PCs - they just need to be used.
They are saying that claiming the underlying problem is not real or not big enough to need addressing is an ineffective way to argue.
The problem lies in (technical) literacy, to some extent people's natural tendency to trust what others are telling them, the incompetence of investigative powers, and the unwillingness of certain countries to shut down scam farms and human trafficking.
My bank's app refuses to operate when I'm on the phone. It also refuses to operate when anything is remotely controlling the phone. There's nothing a banking app can do against vulnerable phones rooted by malware (other than force to operate when phones are too vulnerable according to whatever threshold you decide on so there's nothing to root) but I feel like the countries where banks and police are putting the blame on Google are taking the easy way out.
Scammers will find a way around these restrictions in days and everyone else is left worse off.
Well, in that case, Google has an easy escalation path that they already use for Google Business Listings: They send you a physical card, in the mail, with a code, to the address listed. If this turns out to be a real problem at scale, the patch is barely an inconvenience.
Now they'll need to pay off a local mailman to give them all of Google's letters with an address in an area they control so they can register a town's worth of addresses, big whoop. It'll cost them a bit more than the registration fee, but I doubt it'll be enough to solve the problem.
You can go a softer route of requiring some complicated mechanism of "unlocking" your phone before you can install unverified apps - but by definition that mechanism needs to be more complicated then even a guided (by a scammer) normal non-technical user can manage. So you've essentially made it impossible for normies to install non-playstore apps and thus also made all other app stores irrelevant for the most part.
The scamming issue is real, but the proposed solutions seem worse then the disease, at least to me.
The next step is simply that the scammer modifies the official bank app, adds a backdoor to it, and convinces the victim to install that app and login with it. No hardware-bound credentials are going to help you with that, the only fix is attestation, which brings you back to the aformentioned issue of blessed apps.
OK, so instead of educating stupid (or overly naive) people, we implement "protections" to limit any and all people to do useful things with their devices? And as a "side effect" force them to use "our" app store only? Something doesn't smell that good here …
How about a less drastic measure, like imposing a serious delay for "side loading" … let's say I'd to tell my phone that I want to install F-Droid and then would have to wait for some hours before the installation is possible? While using the device as usual, of course.
The count down could be combined with optional tutorials to teach people to contact their bank by phone meanwhile. Or whatever small printed tips might appear suitable.
Why would the community give a different response? Everything is fine as it is. Life is not safe, nor can it be made safe without taking away freedom. That is a fundamental truth of the world. At some point you need to treat people as adults, which includes letting them make very bad decisions if they insist on doing so.
Someone being gullible and willing to do things that a scammer tells them to do over the phone is not an "attack vector". It is people making a bad decision with their freedom. And that is not sufficient reason to disallow installing applications on the devices they own, any more than it would be acceptable for a bank to tell an alcoholic "we aren't going to let you withdraw your money because we know you're just spending it at the liquor store".
That's right, it's your decision to use Android. If you choose to do so, that's on you.
The world does not consist of all rational actors, and this opens the door to all kinds of exploitation. The attacks today are very sophisticated, and I don't trust my 80-yr old dad to be able to detect them, nor many of my non-tech-savvy friends.
> any more than it would be acceptable for a bank to tell an alcoholic "we aren't going to let you withdraw your money because we know you're just spending it at the liquor store".
This is a false equivalence.
But for regular people, that is not really the world they want. If the bank app wrongly shows they’re paying a legitimate payee, such as the bank, themselves or the tax authority, people politically want the bank to reimburse.
Then the question becomes not if the user trusts the phone’s software, but if the bank trusts the software on the user’s phone. Should the bank not be able to trust the environment that can approve transfers, then the bank would be in the right to no longer offer such transfers.
The community does not need to do that. Installing software on my device should not require identification to be uploaded to a third party beforehand.
We're getting into dystopian levels of compliance here because grandma and grandpa are incapable of detecting a scam. I sympathize, not everyone is in their peak mental state at all times, but this seems like a problem for the bank to solve, not Android.
"I am responsible for my own actions" mode.
You click that, the phone switches into a separate user space. Securenet is disabled, which is what most financial apps rely on.
Then you can install all the fun stuff you want.
This is really a matter of Google not sandboxing stuff right. Why the hell does App A need access to data or notifications from App B.
Aren't we supposed to have sandboxing to prevent this kind of thing? If the malware relies on exploiting n-days on unpatched OSes, they could bypass the sideloading restrictions too.
Alternatively reading notifications could be opt in per app, so the reading app needs to have permission to read your SMS message app notifications, or your bank notifications, that would not be as full proof as that requires some tech literacy to understand.
For example, the "Restricted Settings"¹ feature (introduced in Android 13 and expanded in Android 14) addresses the specific scam technique of coaching someone over the phone to allow the installation of a downloaded APK. "Enhanced Confirmation Mode"², introduced in Android 15, adds furthers protection against potentially malicious apps modifying system settings. These were all designed and rolled out with specified threat models in mind, and all evidence points to them working fairly well.
For Google to suddenly abandon these iterative security improvements and unilaterally decide to lock-down Android wholesale is a jarring disconnect from their work to date. Malware has always been with us, and always will both: both inside the Play Store and outside it. Google has presented no evidence to indicate that something has suddenly changed to justify this extreme measure. That's what we mean by "Existing Measures Are Sufficient".
[^1]: https://support.google.com/android/answer/12623953
[^2]: https://android.googlesource.com/platform/prebuilts/fullsdk/...
Google will not change their minds, they're too busy buying goodwill from governments by playing along. There aren't any real alternatives to Android that are less closed off and they know it.
Concretely, my original plan was to provide an .apk for manual installation first and tackle all this app store madness later. I already have enough on my plate dealing with macOS, Windows, and Linux distribution. With the change, delaying this is no longer viable, so Android is not only one among five platforms with their own requirements, signing, uploading, rules, reviews, and what not, it is one more platform I need to deal with right from the start because users expect software to be multiplatform nowadays.
Quite frankly, it appears to me as if dealing with app stores and arbitrary and ever changing corporate requirements takes away more time than developing the actual software, to the detriment of the end users.
It's sad to watch the decline of personal computing.
The result is unwarranted trust from users in stores that are full of scams.
Apple and Google effectively built malware pipelines under the guise of security.
Linux based phones are starting to become viable as daily drivers. [0] They are even coming with VM Android in case an application is needed that does not have a Linux equivalent.
I am interested in how Google's gatekeeper tactics are going to affect Android like platforms such as /e/os and GrapheneOS. [1]
I'm kind of hoping Qualcomm's open sourcing work will also affect the ability to run mainline Linux on Android devices, but it's looking like a Linux OS that covers the bare basics seems to be a decade away.
In the time it took you to read this comment, 200 phones were sold.
Scammers will use stolen identities or shell companies. They already do this on the Play Store itself. The $25 fee and passport upload haven't prevented the flood of scam apps there.
Meanwhile F-Droid's model (build from source, scan for trackers/malware) actually provides stronger guarantees about what the app does. No identity check needed because the code speaks for itself.
The permission-based approach someone mentioned above makes way more sense. If your app wants to read SMS or intercept notifications, sure, require extra scrutiny. But a simple calculator app or a notes tool? That's just adding friction for no security benefit.
No permission system can work as well as a proper solution (such as banks and governments getting their shit together and investing in basic digital skills for their citizens).
This conflates identity verification with criminal deterrence, they're not the same thing.
It would not be unsurprising for a government to tell Google they must block any VPN apps from being installed on devices, and Google using the developer requirements to carry out the ban.
Don't they already have that power?
I have an APK I would like you to install on your personal phones. No, I won't tell you who I am.
Please let me know when you are comfortable with this.
If you want to make the decision to install Hay Day, the user should be able to know that it is the Hay Day from Supercell or from Sketchy McMalwareson.
99.9% of apps should have no issue with their name being associated with their work. If you genuinely need to use an anonymously published app, you will still be able to do that as a user.
pmdr•1h ago
OutOfHere•24m ago