Live data from Hacker News

Open Letter to Google on Mandatory Developer Registration for App Distribution

keepandroidopen.org

261–270 of 392 posts

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

#261

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…

> 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." 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 adul…

Cars worked fine without seatbelts too. Just because the world goes on doesn't mean we can't do better.

Taking a step back though, I suspect there are cultural differences in approach here. Growing up in Europe, the idea of a regulation to make everyone safer is perfectly acceptable to me, whereas I get the impression that many folks who grew up in the US would feel differently. That's fine! But we also have to recognise these differences and recognise that the platforms in question here are global platforms with global impact and reach.

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

#262

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…

I wonder if putting this choice on the user would be most appropriate?

People fearful about being scammed should buy a phone with a hardware lock to prevent it from ever accepting sideloads--no option to go to dev mode, ever. You could even charge more for the extra security.

People who want the freedom to sideload can choose to buy a phone without the extra hardware security feature.

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

#263

Earlier quoted context omitted.

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.

Amazon has a huge problem with packages being sent to fake people at different addresses. It’s part of review scams. This won’t be much different. Just send the verification to empty houses and apartments.

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

#264
post #48

Earlier quoted context omitted.

There simply isn't a known solution to this problem. If you give users the ability to install unverified apps, then bad actors can trick them into installing bad ones that steal their auth codes and whatnot. If you want to disallow certain apps then you have to make decisions about what apps (stores) are "blessed" and what criteria are used to make those distinctions, necessarily restricting what users can do with th…

The solution would be a "noob mode" that disables sideloading and other security-critical features, which can be chosen when the device is first turned on and requires a factory reset to deactivate. People who still choose expert mode even though they are beginners would then only have themselves to blame.

This is just a variant of the "complicated unlocking mechanism" I was talking about. It still screws over everything not coming from the play store because the installation process for them essentially becomes a huge hassel, that even involves factory resetting their device, that most people won't want to deal with.

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

#265
post #256

Earlier quoted context omitted.

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

OK so make the warning more annoying. Have a security quiz. Cooldown period of one day to enable. Require unlock via adb connected to laptop.

There are alternative solutions if the true goal is maintaining user freedom while protecting dumb users. But that is not the true goal of the upcoming changes.

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

#266
post #154

Earlier quoted context omitted.

You can add 5 layers of "are you sure you want to do this unsafe thing" and it just adds 5 easy steps to the scam where they say "agree to the annoying popup"

You could even make this an installation-time option. If you want to enable the switch afterwards, you have to do a factory reset. Then, the attackers convincing the victims would get nothing.

Or make sideloading available only after 24 hours since enabling it. I would enable it on my new devices and wait 24 hours before installing F-Droid and other apps. Not a problem. Scammers might wait one day too but it decreases the chances of success because friends and family members can interfere.

But I'm afraid that this is security theater and the true goal is to protect revenues by making it hard or impossible to install apps that impact Alfabet bottom line (eg third party YouTube clients.)

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

#267
post #154

Earlier quoted context omitted.

You can add 5 layers of "are you sure you want to do this unsafe thing" and it just adds 5 easy steps to the scam where they say "agree to the annoying popup"

You could even make this an installation-time option. If you want to enable the switch afterwards, you have to do a factory reset. Then, the attackers convincing the victims would get nothing.

That's... brilliant. Enough work to not be able to talk it though over the phone to someone not technical. A sane default for people who don't know about security. And a simple enough procedure for the technically minded and brave.

It solves the 'smartest bear / dumbest human' overlap design concern in this situation.

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

#268

Earlier quoted context omitted.

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

Amazon has a huge problem with packages being sent to fake people at different addresses. It’s part of review scams. This won’t be much different. Just send the verification to empty houses and apartments.

You now need to have a variety of fake addresses you can use, since scammed addresses will get banned. You also need fake IDs. So again, the bar has now been raised from "run a bot to make fake Facebook accounts" to "I have a large number of physical addresses and the ability to create arbitrary fake government IDs".

> Amazon has a huge problem with packages being sent to fake people at different addresses.

This usually involves those people getting weird packages and not doing anything with them, it doesn't require attacker-controlled addresses.

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

#269

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…

Like you said, for years now they have added more and more restrictions to address various scams. So far none of them had any effect, other than annoying users of legitimate apps, because all the new restrictions were on the user side . This new approach restricts developers , but is actually a complete non-issue for most, since the vast majority of apps is distributed via Google Play already. In the section "Existin…

Because without this early resistance, there wouldn't even be vague promises of hobbyist/student exemptions. I think it's important to make community objection to the entire idea known loud and clear, especially when changes like these are absolutely ratcheting.

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

#270
post #260

Earlier quoted context omitted.

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

How did the service authenticate the user in order to create the new credential within the attacker-controlled app?
Post reply on HN