Live data from Hacker News

Open Letter to Google on Mandatory Developer Registration for App Distribution

keepandroidopen.org

241–250 of 392 posts

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

#241
post #140
post #92

Earlier quoted context omitted.

Who says that Google is the one to decide what open source software I can install on my mobile Android computing device?

Wym? Google says it’s the one to decide. They are doing this because side loading causes fraud. There is pressure and lobbying (like this open letter) to stop them from locking it down.

It was a catchy rethorical question. Desired emphasis on the fact that a smartphone is a computing device.

If you like to not be able to run whatever software you want on your computer, and the one your family owns, that's your thing.

Its another pretense, like disabling full disk encryption, where people came with these ideas (instead of other options), because its convenient to them to pretend its the right thing.

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

#242
post #166

Earlier quoted context omitted.

Does the web app for the bank actually selectively block mobile phones? I just checked and Chase here in the US lets me log in on Brave Mobile on iOS. Perhaps your bank lets you log on in the browser.

My understanding (I'm in the US too) is that apps in many other countries don't even have a web app equivalent. If you want your money, you need an authentic android phone and a closed-source app. Or, you can buy a plane ticket somewhere else.

Most banking in for example Europe work fine with GrapheneOS, as long as you relock the bootloader. See e.g.: https://privsec.dev/posts/android/banking-applications-compa...

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

#243
post #19

Earlier quoted context omitted.

Installing an app that silently intercepts SMS/MMS data is a persistent technical compromise. Once the app is there, the attacker has ongoing access. In contrast, convincing someone to read an OTP over the phone is a one-time manual bypass. To use your logic.. A insalled app - Like a hidden camera in a room. Social engineering over phone - Like convincing someone to leave the door unlocked once.

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.

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

#244

Earlier quoted context omitted.

Correction: nothing prevents the attacker from using the app's legit package ID other than requiring the uninstall of the existing app. The spoofed app can't request passkeys for the legit app because the legit app's domain is associated with the legit app's signing key fingerprint via .well-known/assetlinks.json, and the CredentialManager service checks that association.

If the side loaded app does not have permission to use the passkeys and cannot somehow get the user to approve passkey access of the new app, that would be a good alternative to still allow custom apps.

I don't think you understand. This exists _today_, regardless of how you install apps, because attackers can't spoof app signatures. If I don't have Bank of America's private signing key, I cannot make an app that requests passkeys for bankofamerica.com, because bankofamerica.com publishes a file [0] that says "only apps signed with this key fingerprint are allowed to request passkeys for bankofamerica.com" and Android's credential service checks that file.

No need for locking down the app ecosystem, no need to verify developers. Just don't use phishable credentials and you are not vulnerable to malware trying to phish credentials.

0: https://www.bankofamerica.com/.well-known/assetlinks.json

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

#245
post #77
post #8

Isn't the obvious solution to use an AOSP fork that does not have to comply with the registration requirements? Distributions like Graphene and Lineage are completely unaffected.

No, because many apps refuse to run on third-party distros due to misguided notions of them being insecure. It's easy to say "just don't use those apps" but in reality, people are rightly unwilling to put up with any friction and so will simply continue to use Google's version of the OS.

Many banking apps work as long as you relock the bootloader. E.g. on GrapheneOS:

https://privsec.dev/posts/android/banking-applications-compa...

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

#246
If I may advocate for the non HN partisan position here.

Let's consider that Google's Android was and is a huge improvement in security in terms of OS design (even if inspired by iOS) over the previous incumbent (let's call Windows that). That difference in security still exists today (probably due to Window's Backwards Compatibility prioritization, and its later positioning in the market as a cheap powertool (cheap compared to iOS, powertool compared to android).

That security advantage, by the way, was not just the result of initial design, but it required a lot of maintenance, in the form of the 'Play Store' App Store equivalent (at no cost to the user no less).

All this to say that let's consider this context, and consider what alternatives are proposed.

1- The windows 'install whatever you want model' (Now with OS approved certificates): As mentioned, worse, with almost no sandboxing. 2- Linux package managers + install whatever you want: Valid model for powerusers and programmers, not really relevant for massive personal computing. 3- Keeping the old Android system: This would imply simply ignoring the problem of growing professional and untouchable malicious actors that seem to be growing in power with the advent of anonymous financial tech. Is this the actual proposal? Do nothing about the problem? Pretend there is no problem? I don't think the problem is necessarily malware, but to take a specific example, suppose a Casino from Isle of Man is allowing underaged and users from jurisdictions where it is illegal. Regardless of whether you think this is ok, or debatable or it depends on the circumstances. Isn't the ask to identify the developer rather trivial? Just a little bit of paperwork, you want to be a developer? Install code that someone else will use? Put your name in it, have skin in the game.

I think there's also a contradiction between the need for developer privacy and user privacy. Most HN users are privacy-sensitive. Well I propose there's a tradeoff between the privacy of the consumer and the producer. In order to provide privacy and rights to the user, the producer needs to come forward. There's no way to have the cake and eat it too, if both producer and consumer are shy, they will never find each other, if both producer and consumer stay anonymous, they won't trust each other, if both producer and consumer stay anonymous, they don't give any guarantees to the other party that they won't go rogue.

You know this if you've tried to start a business, you can either put your face, your name, register with the state, put your actual address. Or you can use an anonymous brand, a Registered Agent Address, etc... The latter is a harder sell than the former, and you only don't notice it if you are completely absorbed in your own world and cannot put yourself in the shoes of your customer.

tl;dr: Google has an impeccable data security track record. And User/Developer privacy is a tradeoff. Google is right to protect user privacy and not developer privacy.

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

#247

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…

This is a terrible response as a Software Developer by the way. You can just use this to ignore any security concern.

It signals that you don't care much about security, and that you don't care about non-technical users, and don't even have the capacity to see how they view a system.

Sure, you can analyze domain names effectively, you can distinguish between an organic post and an ad, you know the difference between Read and Write permissions to system files, etc...

But can you put yourself on the shoes of a user that doesn't? If not, you are rightfully not in a position as a steward of such users, and Google is.

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

#248
post #65

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." OK, so instead of educating stupid (or overly naive) people, we implement "protections" to limit any and all people to do useful things with their devices? And as a "side effect" force them to use "our" app store only? Something doesn't sme…

How would that solve scammer-driven installs? The scammer is not in a rush, they already have the victim listening and following their instructions.

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

#249

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…

> In Google's announcement in Nov 2025, they articulated a pretty clear attack vector.

If you can be convinced by this, you can be convinced by anything. What if the scammer uses "fear and urgency" to make the person log onto their bank account and transfer the funds to the scammer?

If you can convince people to install new apps through "fear and urgency," especially with how annoying it often is to do outside of the blessed google-owned flow (and they're free to make it more annoying without taking this step), that person can be convinced of anything.

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

There's no other "solution" other than control by an authority that you totally trust if your "threat" is that a user will be able to install arbitrary apps.

The manufacturer, service provider, and google, of course, won't be held to any standard or regulations; they just get trusted because they own your device and its OS and you're already getting covertly screwed and surveilled by them. Google is a scammer constantly trying to exfiltrate information from my phone and my life in order to make money. The funny thing is that they are only pretending to defend me from their competition - they're not threatened by those small-timers - they're actually "defending" me from apps that I can use to replace their own backdoors. Their threat is that they might not know my location at all times, or all of my contacts, or be able to tax anyone who wants access to me.

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

#250
post #172

Earlier quoted context omitted.

Something like 7 iOS phones are sold every second of the day and there are even more Android phones sold. The number of people who care about this issue is far too few for any kind of boycott to be noticed by the handset makers. The only option is to appeal to Google's sense of what's right. In the time it took you to read this comment, 200 phones were sold.

Highly technically knowledgeable people are more influential in this sphere than the average consumer. If developers hate your device and love your competitor, that's a real problem.

It's not clear to me what the net outcome is.

I've mostly owned Android devices but for my family I've always recommended iOS devices because they are more locked down.

Post reply on HN