Live data from Hacker News

Open Letter to Google on Mandatory Developer Registration for App Distribution

keepandroidopen.org

251–260 of 392 posts

Re: Open Letter to Google on Mandatory Developer Registration for App Distribution

#251

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.

So no access to SMS for apps distributed on F-Droid?

Re: Open Letter to Google on Mandatory Developer Registration for App Distribution

#252

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

> Wow, that a major claim. What apps are malware, exactly?

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

#253

The 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?

> 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

#254
post #28

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

The thing that everyone here ignores is that the friction isn't just for safety. It's by design. For some reason, everyone is giving Google as much benefit of the doubt as possible. But no, they want to drive out small developers in general, and this is just one piece of the puzzle. Google has already put up unrelated barriers to publishing apps on Google Play, required every app developer to dox themselves to every user (meanwhile Apple is far more permissive and allows an opt-out for non-commercial apps), they downrank apps by small developers, use alternate UX that disincentivizes installing lesser known apps, put up big scary warnings like "This app isn't installed often" or "Fewer people engage with this app" on the pages of those apps. The only explanation is that they want more money and less upkeep and moderation with the pesky small developers, and the real money-makers are the big corporate apps. They're recreating "the rich get richer" in their microcosm.

Re: Open Letter to Google on Mandatory Developer Registration for App Distribution

#255

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

> Someone will manufacture and sell bulk identities

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

#256
post #104

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

The point is "a warning" is not enough to communicate to people the gravity of what they are doing.

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

#257

Earlier 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?

Not OP, but my experience was most of the malware-like apps on App Store were top ads of apps with names similar to the original ones: such as Whatsapp or Office.

Re: Open Letter to Google on Mandatory Developer Registration for App Distribution

#258

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

But the proposal here, requiring developers to register their identities, doesn't actually impact consumers at all. They still have the ability to make the decision about whether or not to trust someone.

Re: Open Letter to Google on Mandatory Developer Registration for App Distribution

#259

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

yeah the thing is, if someone can social engineer you on the phone and make you do their bidding, you've lost no matter what

Re: Open Letter to Google on Mandatory Developer Registration for App Distribution

#260
post #187

Earlier 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…

> do not control the signing key which is ultimately used to associate app domain passkey, and they do not control the system credentials service which checks this association.

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.

Post reply on HN