Earlier quoted context omitted.
Codes arrive via SMS, which is available to all apps with the READ_SMS permission. This isn't an OS vuln. It is a property of the fact that SMS messages are delivered to a phone number and not an app. On the Play store there is a bunch of annoying checking for apps that request READ_SMS to prevent this very thing. Off Play such defense is impossible.
If they restricted sideloaded apps from sniffing SMS then I wouldn't mind all that much.
Open Letter to Google on Mandatory Developer Registration for App Distribution
251–260 of 392 posts
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#252Earlier quoted context omitted.
This is still not a root cause solution, it's just a mitigation. Because you do not require side loading to install malware. The play store and apple app store both contain malware, as well as apps which can be used for nefarious purposes, such as remote desktop. A root cause solution is proper sandboxing. Google and apple will not do this, because they rely on applications have far too much access to make their mone…
>The play store and apple app store both contain malware Wow, that a major claim. What apps are malware, exactly? >This is still not a root cause solution, it's just a mitigation. Requiring signed apps solves the issue though, as it provides identification of whoever is running the scam and a method for remuneration or prosecution.
I don't understand how this is a major claim at all, it should be obvious. All repositories of large enough sizes contain malware because malware doesn't declare itself as malware.
This is exacerbated by the fact the Google Play Store and Apple App Store allow closed-source applications. It's much easier to validate behavior on things like the Debian repos, where maintainers can, and do, audit the source code.
Google does not have a magic "is this malware" algorithm, that doesn't exist. They rely on heuristics and things like asking the authors "hey is this malware". As you can imagine, this isn't very effective. They don't even install and test the apps fully. Not that it matters much, obviously malware can easily change it's behavior to not be detectable from the end-user just running the app.
> Requiring signed apps solves the issue though, as it provides identification of whoever is running the scam and a method for remuneration or prosecution.
It doesn't, for three reasons:
1. Identifying an app doesn't magically make it not malware. I can tell you "hey I made this app" and you still have zero idea if it's malware. This is still a post mitigation. Meaning, if we somehow know an app is malware, we can find out who wrote it. It doesn't do the "is this malware" part of the mitigation, which is the most important part.
2. Bad actors typically have little allegiance to ethics, meaning they typically will not be honest about their identity. There are criminal organizations which operate in meatspace and fake their identities, which is 1000x harder than doing it online. Most malware will not have a legitimate identity tacked to it.
3. Bad actors typically come from countries which don't prosecute them as hard. So, even if you find out if something is malware, and then find out the actual people behind it, you typically can't prosecute them. Even large online services like the Silk Road lasted for a long time, and most likely still do exist, even despite the literal US federal government trying to stop them.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#253The most controversial claim in this letter is in the section that "Existing Measures Are Sufficient." 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…
Google's announcement is just trolling, there's an order of magnitude more scams on the Play store and they don't call for its closure. Right now when I search for "ChatGPT", the top app is a counterfeit app with a fake logo, is it really this store which is supposed to help us fight scams?
Just did Play search for "ChatGPT" and the top-2 results were for OpenAI's app (one result was sponsored by OpenAI one result was from Google's search). So anecdotally your results may vary.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#254Registration just creates friction for legitimate developers (thousands) while bad actors simply rotate shell companies and fake/stolen IDs. This conflates identity verification with criminal deterrence, they're not the same thing.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#255Earlier quoted context omitted.
> 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. Yeah, this is a huge amount more work than, like, nothing.
All it will do is create a new low risk black market job. Someone will manufacture and sell bulk identities like they do fake social accounts.
How? You've now moved the level of sophistication required from "someone runs some bots on the facebook website" to "someone is now committing complex fraud against a government".
If the only people who can run scams are state sponsored, that's still vastly better than the status quo.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#256Earlier quoted context omitted.
What if we asked users if they want extra protection? I think that would be nice..
This is the status quo. APK installation is disabled by default, and there is a warning when you go to enable it.
It is not enough to write "be careful" on a bag you get from a pharmacy... certain medications require you to both have a prescription, and also to have a conversation with a pharmacist because of how dangerous the decisions the consumer makes can be.
Normal human beings can be very dumb. It's entirely reasonable to expect society to try to protect them at some level.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#257Earlier quoted context omitted.
I am the author of the letter and the coordinator of the signatories. We aren't saying "nuh uh, everything's fine as it is." Rather, we are pointing out that Android has progressively been enhanced over the years to make it more secure and to address emerging new threat models. For example, the "Restricted Settings"¹ feature (introduced in Android 13 and expanded in Android 14) addresses the specific scam technique o…
Would you say that iOS ecosystem suffers the same rate of malware as Android?
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#258Earlier quoted context omitted.
Protecting from scams isn't protection from the victim themselves. That should be obvious from the fact that very intelligent and technologically literate people too can fall for phishing attacks. Tell me for example, how many people in your life know how a bank would ACTUALLY contact you about a suspected hijacking and what the process should look like? And how about any of the dozens of other cover stories used? No…
> Protecting from scams isn't protection from the victim themselves. That is where we differ. It is, ultimately, the victim of a scam who makes the choice of "yes, this person is trustworthy and I will do what they say". The only way to prevent that is to block the user from having the power to make that decision, which is to say protecting them from themselves.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#259The most controversial claim in this letter is in the section that "Existing Measures Are Sufficient." 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…
If you can "coach someone to ignore standard security warnings", you can coach them to give you the two-factor authentication codes, or any number of other approaches to phishing.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#260Earlier quoted context omitted.
I understand how passkeys work. You don't need the legitimate app's credentials, we're talking about phishing attacks, you're trying to bring the victim to giving you access/control to their account without them realizing that that's what is happening. A simple scenario adapted from the one given in the android blog post: the attacker calls the victim and convinces them that their banking account is compromised, and…
> He then walks them through "updating" their app, effectively going through the "new device" workflow - except the new device is the same as the old one, just with the backdoored app. This is where the scheme breaks down: the new passkey credential can never be associated with the legitimate RP. The attacker will not be able to use the credential to sign in to the legitimate app/site and steal money. The attacker co…
You're assuming the attacker must go through the credential manager and the backing hardware, but that is only the case with attestation. Without it, the attacker can simply generate their own passkey in software, because the backend on the banks side would have no way of telling where the passkey came from.