The problem with mandatory developer registration, is that it gives Google and Governments the ability to veto apps. 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.
It's worse than that. Google will be able to track who's using a particular app because it has to be installed the official way. This means for example that anyone who has installed an ICE Tracking app will be reported to the government and perhaps added to a terrorist list.
Open Letter to Google on Mandatory Developer Registration for App Distribution
111–120 of 392 posts
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#112The 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…
Make the warning a full screen overlay with a button to call local police then.
(Seriously)
"but local police won't treat that seriously..." "the victim will be coached to ignore even that..." well no shit then you have a bigger problem which isn't for google to fix.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#113Also, I’m going to coin a new term for the recurring names that I see promoting this kind of thing here: “safety fascists.” Safety fascists won’t sleep until there is a camera watching every home, a government bug in every phone, a 24/7 minder for every citizen. For your safety, of course.
I think I may hate safety fascists more than I hate garden variety fascists. That’s an accomplishment!
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#114Earlier quoted context omitted.
Of course it extends to PCs. It'd suck for us, but end users, software vendors, content providers, and service providers all benefit from a more restricted platform that can provide certain guarantees against malware, fraud, piracy, and so forth. It's pathologically programmer-brained to assume that the good old days of being able to run arbitrary code on a networked computing device would last forever. That freedom…
Obviously I disagree completely. But it is still sad to see this kind of reasoning on HN of all places :(
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#115The 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.
Passkeys are also an active area to defeat phishing as long as the device is not compromised. To the extent there is attestation, passkeys also create very critical posts about locking down devices.
Given what I see in scams, I think too much is put on the user as it is. The anti-phishing training and such try to blame somebody downward in the hierarchy instead of fixing the systems. For example, spear-phishing scams of home down payments or business accounts work through banks in the US not tying account numbers to payee identity. The real issue is that the US payment system is utterly backward without confirmation of payee (I.e. giving the human readable actual name of recipient account in the banking app). For wire transfers or ACH Credit in the US, commercial customers are basically expected to play detective to make sure new account numbers are legit.
As I understand it, sideloading apps can overcome that payee legal name display in other countries. So the question for both sideloading and passkeys is if we want banks liable for correctly showing the actual payee for such transfers. To the extent they are liable, they will need to trust the app’s environment and the passkey.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#116Earlier quoted context omitted.
> 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…
There is some world where somebody scammed through sideloading loses their life savings, and every country is politically fine with the customer, not the bank, taking the losses. 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 quest…
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#117Earlier quoted context omitted.
I'm going to assume you're referring to auth codes, especially the ones sent via SMS? In which case yes, banks should definitely stop using those but that alone doesn't solve the overarching issue. 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,…
SMS 2FA is neither hardware-bound nor phishing resistant, I'm referring to hardware-bound phishing-resistant 2FA methods like passkeys.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#118Earlier quoted context omitted.
Obviously I disagree completely. But it is still sad to see this kind of reasoning on HN of all places :(
If you want a picture of the future, imagine a boot stamping on a human face — for $29.95/month.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#119Earlier quoted context omitted.
Good luck with that.
No luck needed. 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] [0] http://furilabs.com/ [1] https://murena.com/america/products/smartphones/
> No luck needed. Linux based phones are starting to become viable as daily drivers.
Then please tell me, which non-Android Linux-based phone can I buy here in Brazil (one of the first places where Android would have these new restrictions)? I'd love to know (not sarcasm, I'm being sincere). Keep in mind that only phones with ANATEL certification can be imported, non-certified phones will be stopped by customs and sent back.
Re: Open Letter to Google on Mandatory Developer Registration for App Distribution
#120The 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…