Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Letter to Google on Mandatory Developer Registration for App Distribution

keepandroidopen.org

Post reply on HN
Print view View original

231–240 of 392 posts

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

#231

Post by microtonal »

RobotToaster wrote: post #105
thefounder wrote: post #31

Earlier quoted context omitted.

the main issue is the bank using sms and OTP apps instead of something like passkeys and mandatory in bank setup.

One of my banks uses a card reader and pin to log in, seems more secure.

Pins can still be phished. Just make the phishing a live proxy resembling the real site.

A fundamental difference with e.g. FIDO2 (especially hardware-backed) is that the private credentials are keyed to the relying party ID, so it's not possible for a phising site to intercept the challenge-response.

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

#232

Post by john_strinlai »

plorg wrote: post #68
john_strinlai wrote: post #25

Earlier quoted context omitted.

> You can also cut yourself with a kitchen knife but nobody proposes banning kitchen knives. oh nice, i love this game. you cant carry a kitchen knife that is too long, you cant carry your kitchen knife into a school, you cant brandish your kitchen knife at police, you cant let a small child run around with a kitchen knife... literally most of what "the state" does is be a "nanny" (not agreeing or disagreeing with go…

In this example we still don't require you to register with anyone to buy a knife, get the blessing of some institution to sell knives, or, as in this case, get a certification before you can start making knives.

its crazy that different things, like knives and app stores, have different rules. maybe thats why the quip about the knife sounded super cool but fell apart as an analogy for this scenario when thought about for more than 5 seconds?

the point of my comment was that the state does implement a lot of rules (read: "is a nanny"), despite the claim otherwise.

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

#233

Post by microtonal »

shaky-carrousel wrote: post #219
dfabulich wrote: post #3

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…

That attack vector is just a symptom. It’s unfathomably foolish to use two-factor authentication via something as easy to intercept as SMS. Two-factor authentication should be done using a separate hardware token that generates time-based one-time codes. Anything else is basically security theater.

One time codes are still vulnerable to phishing by a site that proxies the bank's authentication challenge. You need something like FIDO2 where a challenge-response only works when the relying party ID is correct.

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

#234

Post by iamnothere »

joshuamorton wrote: post #180
jeroenhd wrote: post #66

Earlier quoted context omitted.

So they'll have a lead time building up a set of verified developers. These scams are pulled by organized crime syndicates, using human trafficking and beatings to keep their call centers manned with complicit workers. 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 b…

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

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

#235

Post by time2buybitcoin »

mwwaters wrote: post #208
jasonjayr wrote: post #170

Earlier quoted context omitted.

Why do banks go through all the know-your-customer (KYC) process if not to identify the beneficial owner of every account? If they receive a transfer via fraud, then they either get it clawed back, have to pay it back, and/or get identified to law enforcement. If the last bank in the chain doesn't want to play by the rules, then other banks shouldn't transfer into them, or that bank itself should be held liable. This…

In the case of some knowing or blindfully unknowing money mule in the chain or at the end of the chain, the intermediary or final banks may not be at fault. The bank could have followed KYC procedures in that somebody with that name actually existed who controlled the account. The money mule themselves is almost certainly insolvent to pay the damages. Currencies can also change by the money mule (either to a differen…

[dead]

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

#236

Post by microtonal »

Tharre wrote: post #187
Retr0id wrote: post #122

Earlier quoted context omitted.

I'm not sure if you understand what makes passkeys phishing-resistant? The backdoored version of the app would need to have a different app ID, since the attacker does not have the legitimate publisher's signing keys. So the OS shouldn't let it access the legitimate app's credentials.

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…

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.

That doesn't work, because the scammer's app will be signed with a different key, so the relying party ID is different and the secure element (or whatever hardware backing you use), refuses to do the challenge-response.

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

#237

Post by tadfisher »

Tharre wrote: post #187
Retr0id wrote: post #122

Earlier quoted context omitted.

I'm not sure if you understand what makes passkeys phishing-resistant? The backdoored version of the app would need to have a different app ID, since the attacker does not have the legitimate publisher's signing keys. So the OS shouldn't let it access the legitimate app's credentials.

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 controls the fake/backdoored app, but they 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 don't even need attestation to prevent this scenario.

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

#238

Post by glenstein »

dfabulich wrote: post #3

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…

>A related approach might be mandatory developer registration for certain extremely sensitive permissions, like intercepting notifications/SMSes...? Or requiring an expensive "extended validation" certificate for developers who choose not to register...?

I think my overriding concern is not nuking F-Droid. I actually think that's a great solution and, interestingly, F-Droid apps already don't use significant permissions (or often use any permissions!) so that might work. Also it would be good if perhaps F-Droid itself could earn a trusted distributor status if there's a way to do that.

Or a marriage of the two, F-Droid can jump through some hoops to be a trusted distributor of apps that don't use certain critical permissions.

I think there have to be ways of creatively addressing the issue that don't involve nuking a non-evil app distribution option.

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

#239

Post by gmueckl »

bigstrat2003 wrote: post #124
gmueckl wrote: post #109

Earlier quoted context omitted.

The reality in South East Asia doesn't support that. You're assuming that the potential victims are able to either use Android alternative or that they are willing and able to educate themselves about scams. The reality in these countries is that neither is the case in practice. Daily lives depend a lot on smartphones and they play a big role in cashless financial transactions. Networking effects play a big role here…

The status quo may not be perfect but it is the best we can do. We try to educate people about scams. We give them warnings that what they are doing can be dangerous if misused. If they choose to ignore those things and proceed anyway, the only further step society could take is to take away the person's freedom to choose. And that is an unacceptable solution.

Society takes away individual's freedom to choose all the time. You can't choose not to pay your taxes. You can't choose to board a passenger plane without passing a security check. You can't just get a loan without any guarantees to the bank etc.

Education isn't really working at this global scale. It doesn't reach people the way you seem to belive it does. Many, if not most people are generally disinterested in learning new things and this gets amplified when it involves technology.

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

#240

Post by mwwaters »

Hizonner wrote: post #121
mwwaters wrote: post #103

Earlier quoted context omitted.

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…

If the actual bank app does that, or is even easy to fool into doing that, then the bank should be responsible. That's the world "regular people" want and it's the world as it should be. If random malware the user chose to install does that, then that is not the bank's fault . The bank is no more involved than anybody else. And no, I don't think "regular people" want to make that the bank's fault.

The legal infrastructure for banking and securities ownership has long had defaults for liability assignment.

For securities, if I own stock outright, the company has to indemnify if they do a transfer for somebody else or if I lack legal capacity. So transfer agents require Medallion Signature Guarantees from a bank or broker. MSGs thereby require a lengthy banking relationship and probably showing up in person.

For broker to broker transfers, there is ACATS. The receiving broker is in fact liable in a strict, no-fault way.

As far as I know, these liabilities are never waived. Basically for the sizable transfers, there is relatively little faith in the user’s computers (including phones). To the extent there is faith, it has total liability on some capitalized party for fraud.

These defaults are probably unknown for most people, even those with large amounts of securities. The system is expected to work since it has been set up this way.

Clearly a large number of programmers have a bent to go the complete opposite direction from MSGs, where everything is private keys or caveat emptor no matter the technical sophistication of the customer. I, well, disagree with that sentiment. The regime where it’s possible for no capitalized entity to be liable for wrongful transfers (defined as when the customer believes they are transferring to a different human-readable payee than actually receiving funds) should not be the default.

Post reply on HN