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

221–230 of 392 posts

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

#221

Post by array_key_first »

UncleMeat wrote: post #156
rm30 wrote: 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.

Friction does matter. Yes, criminals will create fake accounts with stolen IDs and stolen credit cards. But creating 1,000s of these is hard. Creating polymorphic banking trojans is simple. I don't know if this trade off is worth it, but the idea that it won't affect this abuse at all is false.

If you can convince someone over the phone to install malware thru a million "don't do this" screens, you can convince them to just give you their login credentials. Which is both easier, cheaper, and, I imagine, more effective.

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

#222

Post by jrm4 »

dvh wrote: post #14

Wrong approach. Vote with your wallet instead. My next mobile phone will not have OS from Google (not from Apple).

It's emphatically not "the wrong approach," and it's exceedingly weird when everyone makes things like this an "either/or."

Do BOTH, when possible.

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

#223

Post by NewsaHackO »

bigstrat2003 wrote: post #193
NewsaHackO wrote: post #174

Earlier quoted context omitted.

Maybe not, but I think that overextending any idea like that in the opposite direction of whatever point you are trying to make at least devolves into a "slippery slope" argument. For instance, is your point that all security on phones that impede freedom of the user (for instance, HTTPS, forced password on initial startup, not allowing apps to access certain parts of the phone without user permissions, verifying boo…

No, that's not my point at all. Measures such as that are a tool which is in the hands of the user. There is a default restriction which is good enough for most cases, but the user has the ability to open things up further if he needs. What Google is proposing takes control out of the user's hands and makes Google the sole arbiter of what is and is not allowed on the device.

None of the measures I mentioned are changeable by the user, except possibly sideloading an HTTPS certificate. That's the only way any of those measures even work; if it wasn't set as invariants by the OS, they would be bypassable.

>There is a default restriction which is good enough for most cases, but the user has the ability to open things up further if he needs.

But this is what the other guy's point is. You are defining "good enough for most cases" in a way that he is not, then making the argument that what he says is equivalent to not allowing an alcoholic to buy beer. Why can you set what level is an acceptable amount of restriction, but he can't?

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

#224

Post by mormegil »

hbn wrote: post #154
kovek wrote: post #104

Earlier quoted context omitted.

What if we asked users if they want extra protection? I think that would be nice..

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.

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

#225

Post by array_key_first »

arjie wrote: post #166
jamesnorden wrote: post #125

Earlier quoted context omitted.

No bank in my country has an app that works with those, so it's not an option for me anymore.

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.

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

#227

Post by microtonal »

mirekrusin wrote: post #126
marcprux wrote: post #91

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?

There could be many other factors, like abysmal patch policies. Many vendors still only do Android Security Bulletins (which are only vulnerabilities marked as high and critical), do them late (despite a three month embargo for patches), very delayed device firmware updates, and sometimes only for two or three years.

Many Android phones still do not have a separate secure element.

Also, the Play Store itself regularly contains malware.

In the end it is mostly about control, dressed up as protecting users. If it was about security, Google would support GrapheneOS remote attestation for Google Pay (for being the most secure Android variant) and cut off many existing phones with deplorable security.

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

#228

Post by NewsaHackO »

jrm4 wrote: post #210
sheiyei wrote: post #182

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…

None of these things requires "locking down phones." Every single thing you've mentioned can be done in a smarter way that doesn't involve "individuals aren't allowed to modify the devices they purchase."

You can't make a statement like that and provide no examples. What are some of your ideas for doing that?

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

#229

Post by drnick1 »

jamesnorden wrote: post #125
drnick1 wrote: 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 bank in my country has an app that works with those, so it's not an option for me anymore.

Is using a cheap Android device (the cheapest Android phones are less than $100 on Amazon) an option? The idea is to use that phone for 2FA or whatever is app is necessary for, and use a degoogled device for your other day-to-day activities. It's not ideal because you need to spend some extra money, but it buys you a lot of privacy.

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

#230

Post by mwwaters »

tadfisher wrote: post #157
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.

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.
Post reply on HN