Honestly, if coerced sideloading is a real attack vector, then this seems to be a pretty fair compromise.

I just remain skeptical that this tactic is successful on modern Android, with all the settings and scare screens you need to go through in order to sideload an app and grant dangerous permissions.

I expect scammers will move to pre-packaged software with a bundled ADB client for Windows/Mac, then the flow is "enable developer options" -> "enable usb debugging" -> "install malware and grant permissions with one click over ADB". People with laptops are more lucrative targets anyway.

▲

dfabulich 14 hours ago | parent | next [-]

I predict that they're going to introduce further restrictions, but I think the restrictions will only apply to certain powerful Android permissions.

The use case they're trying to protect against is malware authors "coaching" users to install their app.

In November, they specifically called out anonymous malware apps with the permission to intercept text messages and phone calls (circumventing two-factor authentication). https://android-developers.googleblog.com/2025/11/android-de...

After today's announced policy goes into effect, it will be easier to coach users to install a Progressive Web App ("Installable Web Apps") than it will be to coach users to sideload a native Android app, even if the Android app has no permissions to do anything more than what an Installable Web App can do: make basic HTTPS requests and store some app-local data. (99% of apps need no more permissions than that!)

I think Google believes it should be easy to install a web app. It should be just as easy to sideload a native app with limited permissions. But it should be very hard/expensive for a malware author to anonymously distribute an app with the permission to intercept texts and calls.

▲

tadfisher 14 hours ago | parent | next [-]

I don't think Google has a strategy around what should be easy for users to do. PWAs still lack native capabilities and are obviously shortcuts to Chrome, and Google pushes developers to Trusted Web Activities which need to be published on the Play Store or sideloaded.

But these developer verification policies don't make any exceptions for permission-light apps, nor do they make it harder to sideload apps which request dangerous permissions, they just identify developers. I also suspect that making developer verification dependent on app manifest permissions opens up a bypass, as the package manager would need to check both on each update instead of just on first install.

▲

yjftsjthsd-h 14 hours ago | parent | prev [-]

> But it should be very hard/expensive for a malware author to anonymously distribute an app with the permission to intercept texts and calls.

And how hard/expensive should it be for the developer of a legitimate F/OSS app to intercept calls/texts?

▲

Tostino 14 hours ago | parent | next [-]

Yep, I have a legitimate use case for exactly this. It integrates directly with my application and gives it native phone capabilities that are unavailable if I were to use a VoIP provider of any kind.

▲

dfabulich 13 hours ago | parent [-]

As a legitimate developer developing an app with the power to take over the phone, I think it's appropriate to ask you to verify your identity. It should be an affordable one-time verification process.

This should not be required for apps that do HTTPS requests and store app-local data, like 99%+ of all apps, including 99% of F-Droid apps.

But, in my opinion, the benefit of anonymity to you is much smaller than the harm of anonymous malware authors coaching/coercing users to install phone-takeover apps.

(I'm sure you and I won't agree about this; I bet you have a principled stand that you should be able to anonymously distribute malware phone-takeover apps because "I own my device," and so everyone must be vulnerable to being coerced to install malware under that ethical principle. It's a reasonable stance, but I don't share it, and I don't think most people share it.)

	▲	Tostino 13 hours ago \| parent [-]
		I think you read a bit too much into my message. I agree, it's complicated, I don't want my parents and grandparents easily getting scammed. But yes they are my devices, and I should be able to do exactly what I want with them. If I'm forced to deal with other developers incredibly shitty decisions around how they treat VoIP numbers, guess who's going to have a stack of phones with cheap plans in the office instead of paying a VoIP provider... But no, I have no interest in actually distributing software like that further than than the phones sitting in my office.

▲

dfabulich 14 hours ago | parent | prev [-]

For a security-sensitive permission like intercepting texts and calls, I'm not sure it makes sense for that to be anonymous at all, not even for local development, not even for students/hobbyists.

Getting someone to verify their identity before they have the permission to completely takeover my phone feels pretty reasonable to me. It should be a cheap, one-time process to verify your identity and develop an app with that much power.

I can already hear the reply, "What a slippery slope! First Google will make you verify identity for complete phone takeovers, but soon enough they'll try to verify developer identity for all apps."

But if I'm forced to choose between "any malware author can anonymously intercept texts and calls" or "only identified developers can do that, and maybe someday Google will go too far with it," I'm definitely picking the latter.

▲

hrmtst93837 12 hours ago | parent | prev | next [-]

The scam only has to work on a tiny slice of users, and the people who fall for fake bank alerts or package texts will march through a pile of Android warnigns if the script is convincing enough. Once the operator gets them onto a PC, the whole thing gets easier because ADB turns it into a guided install instead of a phone-only sideload.

That's why I don't think the extra prompts matter much beyond raising attacker cost a bit. Google is patching the visible path while the scam just moves one hop sideways.

▲

msl 13 hours ago | parent | prev [-]

> Honestly, if coerced sideloading is a real attack vector, [...]

I don't believe that it is. I follow this "scene" pretty closely, and that means I read about successful scams all the time. They happen in huge numbers. Yet I have never encountered a reliable report of one that utilized a "sideloaded"[1] malicious app. Not once. Phishing email messages and web sites, sure. This change will not help counter those, though.

I don't even see what you could accomplish with a malicious app that you couldn't otherwise. I would certainly be interested to hear of any real world cases demonstrating the danger.

[1] When I was a kid, this was called "installing."

	▲	Stagnant 12 hours ago \| parent [-]
		This is the thing that bothers me the most about this. It is as if even the HN crowd is taking it as given that malware is this big problem for banking on Android but in reality there seems to be very little evidence to back this up. I regularly read local (Finnish) news stories about scams and they always seem to be about purely social engineering via whatsapp or the scammer calling their number and convincing the victim they are a banking official or police etc. That's why I'm inclined to believe Google is just using safety as an excuse to further leverage their monopoly.