[HN Gopher] Open Letter to Google on Mandatory Developer Registr...
___________________________________________________________________
Open Letter to Google on Mandatory Developer Registration for App
Distribution
Author : kaplun
Score : 329 points
Date : 2026-02-24 17:21 UTC (5 hours ago)
(HTM) web link (keepandroidopen.org)
(TXT) w3m dump (keepandroidopen.org)
| pmdr wrote:
| The undersigned are basically a list of entities Google would
| like to see disappear.
| OutOfHere wrote:
| Precisely! Google doesn't care one bit about civil society; it
| cares about power to itself even if this means punching freedom
| and liberty in the face. Personally I think it'll be a good
| thing if this restriction finally wakes up people to seek
| alternatives to Google.
| dfabulich wrote:
| 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 fear and
| urgency to direct them to sideload a "verification app" to secure
| their funds, often coaching them to ignore standard security
| warnings. Once installed, this app -- actually malware --
| intercepts the victim's notifications. When the user logs into
| their real banking app, the malware captures their two-factor
| authentication codes, giving the scammer everything they need to
| drain the account._
|
| > _While we have advanced safeguards and protections to detect
| and take down bad apps, without verification, bad actors can spin
| up new harmful apps instantly. It becomes an endless game of
| whack-a-mole. Verification changes the math by forcing them to
| use a real identity to distribute malware, making attacks
| significantly harder and more costly to scale._
|
| 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."
|
| 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...?
| verdverm wrote:
| Agree with this middle path you point out. On one hand, I do
| not want some apps to be distributed anonymously, I need to
| know who is behind it in order to trust the app. On the other
| hand, many apps are benign.
|
| Permissions are a great way to distinguish.
| amiga386 wrote:
| Do you need _Google_ to compel the author to start a business
| relationship with them, which they can cut off at any time?
|
| Or would you be OK knowing that Thunderbird you downloaded
| from https://thunderbird.net/ is signed by the
| thunderbird.net certificate owner?
| verdverm wrote:
| Something like Thunderbird _might_ be an exception, but
| also domain confusion exists, so in the general case, most
| likely not because most users are susceptible to this.
| jyoung8607 wrote:
| Typo squatting is a thing, and so are Unicode homographs.
|
| The permissions approach isn't bad. I may trust Thunderbird
| for some things, but permission to read SMS and
| notifications is permission to bypass SMS 2FA for every
| _other_ account using that phone number. It deserves a
| special gate that 's very hard for a scammer to pass. The
| exact nature of the gate can be reasonably debated.
| joshuamorton wrote:
| should I be confident that thunderbird.net is the real one,
| or could it be hosted at thunderbird.org, thunderbird.com,
| or thunderbird.mozilla.org?
| JoshTriplett wrote:
| 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.
| harikb wrote:
| 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.
| JoshTriplett wrote:
| > Installing an app that silently intercepts SMS/MMS data
| is a persistent technical compromise. Once the app is
| there, the attacker has ongoing access.
|
| The motivating example as described involves "giving the
| scammer everything they need to drain the account". Once
| they've drained the account, they don't need ongoing
| access.
| jyoung8607 wrote:
| Persistence allows the scammer free license to attempt
| password recoveries for every account the victim could
| possibly have. Other banks, retirement accounts, the
| victim's email account.
| sdenton4 wrote:
| When the victim's relatives send them money because they
| need to eat and pay rent after handing everything over to
| the scammer, the persistent backdoor lets that money be
| drained as well... You're underestimating the persistence
| and ruthlessness of the scammers.
| hulitu wrote:
| > Installing an app that silently intercepts SMS/MMS data
| is a persistent technical compromise.
|
| Why would an app silently intercepts SMS/MMS data ? Why
| does an app needs network access ?
|
| Running untrusted code in your browser is also "a
| persistent technical compromise" but nobody seems to care.
| array_key_first wrote:
| 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 money.
|
| One of the fundamentals of security is that applications
| should use the minimum data and access they need to
| operate. Apple and Google break this with every piece of
| software they make. The disease is spreading from the
| inside out. Putting a shitty lotion on top won't fix this.
| NewsaHackO wrote:
| >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.
| array_key_first wrote:
| > Wow, that a major claim. What apps are malware,
| exactly?
|
| I don't understand how this is a major claim at all, it
| should be obvious. All repositories of large enough sizes
| contain malware because malware doesn't declare itself as
| malware.
|
| This is exacerbated by the fact the Google Play Store and
| Apple App Store allow closed-source applications. It's
| much easier to validate behavior on things like the
| Debian repos, where maintainers can, and do, audit the
| source code.
|
| Google does not have a magic "is this malware" algorithm,
| that doesn't exist. They rely on heuristics and things
| like asking the authors "hey is this malware". As you can
| imagine, this isn't very effective. They don't even
| install and test the apps fully. Not that it matters
| much, obviously malware can easily change it's behavior
| to not be detectable from the end-user just running the
| app.
|
| > Requiring signed apps solves the issue though, as it
| provides identification of whoever is running the scam
| and a method for remuneration or prosecution.
|
| It doesn't, for three reasons:
|
| 1. Identifying an app doesn't magically make it not
| malware. I can tell you "hey I made this app" and you
| still have zero idea if it's malware. This is still a
| post mitigation. Meaning, if we somehow know an app is
| malware, we can find out who wrote it. It doesn't do the
| "is this malware" part of the mitigation, which is the
| most important part.
|
| 2. Bad actors typically have little allegiance to ethics,
| meaning they typically will not be honest about their
| identity. There are criminal organizations which operate
| in meatspace and fake their identities, which is 1000x
| harder than doing it online. Most malware will not have a
| legitimate identity tacked to it.
|
| 3. Bad actors typically come from countries which don't
| prosecute them as hard. So, even if you find out if
| something is malware, and then find out the actual people
| behind it, you typically can't prosecute them. Even large
| online services like the Silk Road lasted for a long
| time, and most likely still do exist, even despite the
| literal US federal government trying to stop them.
| nine_k wrote:
| The 2-factor SMS messages usually say: "Do not give this code
| to anyone! The bank will NEVER ask you for this code!".
|
| The sideloading warning is much much milder, something like
| "are you sure you want to install this?".
| thefounder wrote:
| the main issue is the bank using sms and OTP apps instead
| of something like passkeys and mandatory in bank setup.
| RobotToaster wrote:
| One of my banks uses a card reader and pin to log in,
| seems more secure.
| microtonal wrote:
| 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.
| JoshTriplett wrote:
| You'll then get _more_ warnings if you want to give the
| sideloaded app additional permissions. And if they want to
| make the sideloading warnings more dire, that wouldn 't be
| nearly as unreasonable.
| hollow-moe wrote:
| > The bank will NEVER ask you for this code!
|
| > Please enter the code we sent you in the app.
|
| lol, lmao even
| instagib wrote:
| Never ending worm approach is to get remote control via
| methods on android or apple. Then scam other contacts. It's
| built into FaceTime. Need 3rd party apps for android.
| mwwaters wrote:
| The phisher's app or login would be from a completely new
| device though.
|
| 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.
| thousand_nights wrote:
| yeah the thing is, if someone can social engineer you on the
| phone and make you do their bidding, you've lost no matter
| what
| darkwater wrote:
| > In Google's announcement in Nov 2025, they articulated a
| pretty clear attack vector. https://android-
| developers.googleblog.com/2025/11/android-de...
|
| This reeks of "think of the children^Wscammed". I mean,
| following this principle the only solution is to completely
| remove any form of sideloading and have just one single Google
| approved store because security.
|
| > A related approach might be mandatory developer registration
| for certain extremely sensitive permissions, like intercepting
| notifications/SMSes...? O
|
| It doesn't work like that. What they mean with "mandatory
| developer registration" is what Google already does if you want
| to start as a developer in Play Store. Pay 25$ one-time fee
| with a credit card and upload your passport copy to some (3rd-
| party?) ID verification service. [1] In contrast with F-Droid
| where you just need a GitLab user to open a merge request in
| the fdroid-data repository and submit your app, which they scan
| for malware and compile from source in their build server.
|
| [1] but I guess there are plenty of ways to fool Google anyway
| even with that, if you are a real scammer.
| kotaKat wrote:
| You can't even win with adding more scare screens because as
| soon as Epic isn't allowed to bypass the scare screens, they'll
| sue you.
|
| Just like they went after Samsung for adding friction to the
| sideload workflow to warn people against scams.
|
| https://www.macrumors.com/2024/09/30/epic-games-sues-samsung...
| daveidol wrote:
| I agree with Epic. It should be like on windows or macOS
| where you can register, get notarized, and then distribute
| without scare screens. I don't see why phones are inherently
| different than computers.
| cherryteastain wrote:
| > community needs a better response to this problem than "nuh
| uh, everything's fine as it is."
|
| You can also cut yourself with a kitchen knife but nobody
| proposes banning kitchen knives. Google and the state are not
| your nannies.
| john_strinlai wrote:
| > _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 google here, i have no
| horse in this particular race. but this little knife quip is
| silly when you think about it for more than 5 seconds)
| CamperBob2 wrote:
| _you cant buy a kitchen knife that is too long_
|
| What?
| john_strinlai wrote:
| sorry, should say "carry", not "buy". most states have a
| maximum length you can carry (4-5.5 inches is common).
|
| although, i would imagine at some length, it becomes a
| "sword" (even if marketed as a knife) and falls under
| some other "nanny"-ing. i have not googled that.
| mikestew wrote:
| You still have an hour or two to edit your comment. Look
| in that line of text where you see your user name, click
| "Edit".
| CamperBob2 wrote:
| As kevin_thibedeau points out elsewhere in the thread,
| he's not necessarily wrong. In many states and foreign
| countries it's illegal to carry a large knife in public
| without a reason and I'm sure purchases are restricted in
| some places as well. Most people are more or less OK with
| that, it seems, so there historically hasn't been a lot
| of pushback.
|
| So, having been given the proverbial inch (or
| centimeter), those obsessed with banning potentially-
| dangerous tools are trying to take the next mile (or
| kilometer): https://theconversation.com/why-stopping-
| knife-crime-needs-t...
| Cyph0n wrote:
| Doesn't editing require a karma threshold?
| john_strinlai wrote:
| it does not (thankfully!)
| mikestew wrote:
| Apostrophe's don't have a karma threshold, either. ;-)
| kevin_thibedeau wrote:
| Long knives in the UK are like full auto guns in the rest
| of the world.
| InsideOutSanta wrote:
| All of these rules, and yet people still cut themselves and
| others.
| aclindsa wrote:
| I think it's important to consider the intent of those
| laws, too. They are primarily or even exclusively to
| prevent you from hurting others with knives. They are not
| really intended to protect you from cutting yourself in
| your own home. So I think the parent's comment still holds
| weight.
| plorg wrote:
| 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.
| john_strinlai wrote:
| 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.
| daveidol wrote:
| I don't want to be too flippant, but I think there is a real
| trade off across many aspects of life between "freedom" and
| "safety".
|
| There is a point at which people have to think critically about
| what they are doing. We, as a society, should do our best to
| protect the vulnerable (elderly, mentally disabled, etc) but we
| must draw the line somewhere.
|
| It's the same thing in the outside world too - otherwise we
| could make compelling arguments about removing the right to
| drive cars, for example, due to all the traffic accidents
| (instead we add measures like seatbelts as a compromise,
| knowing it will never totally solve the issue).
| MSFT_Edging wrote:
| I think there's room to raise the bar of required tech
| competency without registration.
|
| Manually installing an app might be close to the limit of what
| grandma can be coached through by an impatient scammer.
|
| Multiple steps over adb, challenges that can't be copy and
| pasted in a script, etc. It can be done but it won't provide as
| much control over end user devices.
| snowhale wrote:
| the whack-a-mole problem is real but mandatory registration
| doesn't actually fix it for sophisticated actors -- they'll
| just use burner entities or buy aged developer accounts. it
| mostly raises costs for hobbyists and side projects. the
| permission-gating approach dfabulich mentions (require
| registration only for notification/SMS interception APIs) seems
| more targeted.
| Cyph0n wrote:
| Does your logic extend to PCs? If not, why?
|
| Because I hope you realize that clamping down on "sideloading"
| (read: installing unsigned software) on PCs is the next logical
| step. TPMs are already present on a large chunk of consumer PCs
| - they just need to be used.
| bitwize wrote:
| 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
| must be balanced against the interests of the rest of society
| to avoid risk from certain kinds of harm which can easily
| proliferate in an environment where any program can run with
| the full authority of the owner and malware spreads willy-
| nilly.
| Cyph0n wrote:
| Obviously I disagree completely. But it is still sad to see
| this kind of reasoning on HN of all places :(
| kps wrote:
| If you want a picture of the future, imagine a boot
| stamping on a human face -- for $29.95/month.
| bitwize wrote:
| Show HN: O'Brien (YC S29), new AI-powered Boot as a
| Service provider
| eikenberry wrote:
| The "programmer-brained" assumption is that I will be able
| to write any program and run it on my machine and that this
| ability isn't reserved for only me or some limited class of
| people and that I can share what I write with others. One
| big plus of the current stye of AI will be that "end users"
| will be able to write simple programs and will value this
| ability. Thus helping protect general purpose computing
| from this bit of evil for a while longer.
| iamnothere wrote:
| Exactly. I own a few dozen computers, if you count some
| low powered SBCs. But even those can run lightweight
| Linux.
|
| That's enough for me to distribute a few freedom devices
| to friends and neighbors, and still have extras to
| account for normal failures.
|
| I also hoard source code, and will happily distribute
| that with the computers! Maybe that's "programmer
| brained," if so then fine by me!
| RandomGerm4n wrote:
| Users get way more out of it when the device is free. Even
| if they don't use this option, it makes it easier to set up
| competing services. This includes ones that would never be
| allowed in an official store because they're DRM-free
| alternatives to big streaming services but still offer all
| the same content. The existence of such alternatives, if
| they are easy to use, can force the big services to become
| more user-friendly. Just as happened back then with
| Napster.
|
| Also every user is free to simply not use the option of
| installing things outside of the store.
| bitwize wrote:
| > This includes ones that would never be allowed in an
| official store because they're DRM-free alternatives to
| big streaming services but still offer all the same
| content.
|
| Do you know _anyone_ who works in a professional creative
| field that doesn 't involve writing code? If so, ask them
| how they'd feel about their work bring out there on the
| internet free to all takers. What the implications would
| be for their ability to feed their children and pay their
| mortgage doing the things they love.
|
| This is what I mean by "programmer-brained." Of all
| creative workers, only programmers seem okay with
| abolishing IP laws, I guess because they figure they'll
| be okay living out of an office at MIT, or even worse out
| of an office at some YC startup that turns the user into
| the product. But artists, musicians, writers, filmmakers,
| etc. all put food on the table because of those IP laws
| programmers hate so much. Taking that protection for the
| fruit of your labor away would be at least as disruptive
| as AI has been.
| nmeagent wrote:
| > That freedom must be balanced against the interests of
| the rest of society to avoid risk from certain kinds of
| harm which can easily proliferate in an environment where
| any program can run with the full authority of the owner
| and malware spreads willy-nilly.
|
| No, no, a thousand times no. This is an argument for
| authoritarian clampdown on general computing and must be
| opposed by all means necessary. I have the right to run
| whatever code I wish on my own damn property without the
| permission of arbitrary authorities or whatever subset of
| _society_ you favor, and if you or they have a problem with
| this, you or they can proceed to pound sand.
| iamnothere wrote:
| Safety fascists won't stop until every human interaction
| requires permission.
|
| It's a good time to buy a pallet of old SFF computers,
| just in case.
| tzs wrote:
| You missed their point. They are not saying that what Google
| is doing is a good way to address the underlying problem
| Google says it is addressing.
|
| They are saying that claiming the underlying problem is not
| real or not big enough to need addressing is an ineffective
| way to argue.
| Cyph0n wrote:
| Right, but this same problem (scamming) exists on PCs.
|
| Would it make sense to then argue that _enforcing_ TPM-
| backed measured boot and binary signature verification is a
| legitimate way to address the problem?
| tzs wrote:
| Their point, applied to that situation, would be that
| _if_ someone does argue for enforcing TPM-backed measured
| boot yadda yadda to address scamming, trying to counter
| it by dismissing scamming as not a real problem is
| useless.
| Cyph0n wrote:
| I get it dude, but my wider point is that we need to
| question where this line of argumentation leads to.
|
| Are we saying that, because scamming exists and we
| haven't proposed an alternative, it means that clamping
| down on software installation methods is a legitimate
| solution to the problem?
| jeroenhd wrote:
| Developer registration doesn't prevent this problem. Stolen ID
| can be found for a lot less money than what a day in a scam
| farm's operation will bring in. A criminal with access to
| Google can sign and deploy a new version of their scam app
| every hour of the day if they wish.
|
| The problem lies in (technical) literacy, to some extent
| people's natural tendency to trust what others are telling
| them, the incompetence of investigative powers, and the
| unwillingness of certain countries to shut down scam farms and
| human trafficking.
|
| My bank's app refuses to operate when I'm on the phone. It also
| refuses to operate when anything is remotely controlling the
| phone. There's nothing a banking app can do against vulnerable
| phones rooted by malware (other than force to operate when
| phones are too vulnerable according to whatever threshold you
| decide on so there's nothing to root) but I feel like the
| countries where banks and police are putting the blame on
| Google are taking the easy way out.
|
| Scammers will find a way around these restrictions in days and
| everyone else is left worse off.
| gjsman-1000 wrote:
| > Stolen ID can be found for a lot less money than what a day
| in a scam farm's operation will bring in.
|
| Well, in that case, Google has an easy escalation path that
| they already use for Google Business Listings: They send you
| a physical card, in the mail, with a code, to the address
| listed. If this turns out to be a real problem at scale, the
| patch is barely an inconvenience.
| jeroenhd wrote:
| 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 bit more than the registration
| fee, but I doubt it'll be enough to solve the problem.
| joshuamorton wrote:
| > 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.
| iamnothere wrote:
| 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.
| joshuamorton wrote:
| > 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.
| iamnothere wrote:
| 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.
| joshuamorton wrote:
| 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.
| kodebach wrote:
| My guess is that Android 17 will show the registered name of
| the developer of the app you're trying to install. With
| stolen IDs you can only get accounts for individual
| developers not for organisations.
|
| When a scammer pretending to be your bank tells you to
| install an app for verification and it says "This app was
| created by John Smith" even grandma will get suspicious and
| ask why it doesn't show the bank's name.
| Tharre wrote:
| 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
| their own devices.
|
| You can go a softer route of requiring some complicated
| mechanism of "unlocking" your phone before you can install
| unverified apps - but by definition that mechanism needs to be
| _more_ complicated then even a guided (by a scammer) normal
| non-technical user can manage. So you 've essentially made it
| impossible for normies to install non-playstore apps and thus
| also made all other app stores irrelevant for the most part.
|
| The scamming issue is real, but the proposed solutions seem
| worse then the disease, at least to me.
| Retr0id wrote:
| We know how to do hardware-bound phishing-resistant
| credentials now, it _is_ a solved problem.
| Tharre wrote:
| 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, the only
| fix is attestation, which brings you back to the
| aformentioned issue of blessed apps.
| Retr0id wrote:
| SMS 2FA is neither hardware-bound nor phishing resistant,
| I'm referring to hardware-bound phishing-resistant 2FA
| methods like passkeys.
| Tharre wrote:
| Read my previous comment again. Passkeys are nice, but
| they don't solve the problem that's being discussed here.
| Retr0id wrote:
| 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.
| tadfisher wrote:
| 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.
| mwwaters wrote:
| 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.
| tadfisher wrote:
| 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
| Tharre wrote:
| 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 they need to act now to secure it. The scammer tells
| the victim, that their account got compromised because
| they're using and outdated version of the banking app
| that's no longer suppported. 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.
|
| You can prevent this with attestation of course,
| essentially giving the bank's backend the ability to
| verify that the credentials are actually tied to their
| app, and not some backdoored version. But now you have a
| "blessed" key that's in the hands of Google or Apple or
| whomever, and everyone who wants to run other operating
| systems or even just patched versions of official apps is
| out of luck.
| microtonal wrote:
| _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.
| tadfisher wrote:
| > 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.
| Tharre wrote:
| > 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 banks side would have no way
| of telling where the passkey came from.
| tadfisher wrote:
| How did the service authenticate the user in order to
| create the new credential within the attacker-controlled
| app?
| RandomGerm4n wrote:
| 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.
| jrm4 wrote:
| This should be voted higher, it _quite literally_ is this
| simple.
| Tharre wrote:
| 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.
| singpolyma3 wrote:
| > 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.
|
| This is also true if they can only install verified apps,
| because no company on earth has the resources to have an
| actually functional verification process and stuff gets
| through every day.
| iamnothere wrote:
| > This is also true if they can only install verified apps,
| because no company on earth has the resources to have an
| actually functional verification process and stuff gets
| through every day.
|
| This is true, but if this goes through, I imagine that the
| next step for safety fascists will be to require developer
| licensing and insurance like general contractors have. And
| after that, expensive audits, etc, until independent
| developers are shut out completely.
| jcynix wrote:
| >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 smell that
| good here ...
|
| How about a less drastic measure, like imposing a serious delay
| for "side loading" ... let's say I'd to tell my phone that I
| want to install F-Droid and then would have to wait for some
| hours before the installation is possible? While using the
| device as usual, of course.
|
| The count down could be combined with optional tutorials to
| teach people to contact their bank by phone meanwhile. Or
| whatever small printed tips might appear suitable.
| warkdarrior wrote:
| How would that solve scammer-driven installs? The scammer is
| not in a rush, they already have the victim listening and
| following their instructions.
| bigstrat2003 wrote:
| > 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 adults, which
| includes letting them make very bad decisions if they insist on
| doing so.
|
| Someone being gullible and willing to do things that a scammer
| tells them to do over the phone is not an "attack vector". It
| is people making a bad decision with their freedom. And that is
| not sufficient reason to disallow installing applications on
| the devices they own, any more than it would be acceptable for
| a bank to tell an alcoholic "we aren't going to let you
| withdraw your money because we know you're just spending it at
| the liquor store".
| gretch wrote:
| > At some point you need to treat people as adults, which
| includes letting them make very bad decisions if they insist
| on doing so.
|
| That's right, it's your decision to use Android. If you
| choose to do so, that's on you.
| zarzavat wrote:
| You're right, all Android users who are upset about this
| change are free to switch to iOS.
| raw_anon_1111 wrote:
| Right like someone who can only afford a $100 phone can
| buy the cheapest iPhone which is 5x more expensive.
|
| This is about like the geeks who hate the idea of ad
| supported services and think that everyone should just
| pay for every service they use.
|
| FWIW: I do exclusively buy Apple devices, pay for
| streaming services ad free tier, the Stratechery podcast
| bundle, ATP and the Downstream podcasts and Slate. I also
| pay for ChatGPT and refuse to use any ad supported app or
| game.
| jmholla wrote:
| I think that OP's point was that the alternative is even
| more locked down. There is no option for people who don't
| want to be nannied.
| sschueller wrote:
| If there was a choice to a non-walled garden. It has been
| taken away, how can you bank without one of the two?
| zeroxfe wrote:
| > At some point you need to treat people as adults, which
| includes letting them make very bad decisions if they insist
| on doing so.
|
| The world does not consist of all rational actors, and this
| opens the door to all kinds of exploitation. The attacks
| today are very sophisticated, and I don't trust my 80-yr old
| dad to be able to detect them, nor many of my non-tech-savvy
| friends.
|
| > any more than it would be acceptable for a bank to tell an
| alcoholic "we aren't going to let you withdraw your money
| because we know you're just spending it at the liquor store".
|
| This is a false equivalence.
| bigstrat2003 wrote:
| It's not a false equivalence at all. Both situations are
| taking away someone's control of something that they own,
| borne from a paternalistic desire to protect that person
| from themselves. If one is acceptable, the other should be.
| Conversely if one is unacceptable, the other should be
| unacceptable as well. Either paternalistic refusal to let
| people do as they wish is ok, or it isn't.
| NewsaHackO wrote:
| 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 boot image signatures) should be
| removed as well?
| bigstrat2003 wrote:
| 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.
| NewsaHackO wrote:
| 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?
| array_key_first wrote:
| But it's not a slippery slope, because it's not taking it
| to the next level. It's the same level, just a different
| thing.
| sheiyei wrote:
| 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? Not to mention the
| situations where the scammers can use literally the same
| method of first contact as the real thing (eg. spoofed).
| ...And the fact that for example email clients do their
| best to help them by obscuring the email address and only
| showing the display name, because that's obviously a good
| idea.
| bigstrat2003 wrote:
| > Protecting from scams isn't protection from the victim
| themselves.
|
| That is where we differ. It is, ultimately, the victim of
| a scam who makes the choice of "yes, this person is
| trustworthy and I will do what they say". The only way to
| prevent that is to block the user from having the power
| to make that decision, which is to say protecting them
| from themselves.
| joshuamorton wrote:
| But the proposal here, requiring _developers_ to register
| their identities, doesn 't actually impact consumers at
| all. They still have the ability to make the decision
| about whether or not to trust someone.
| jrm4 wrote:
| _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."
| NewsaHackO wrote:
| You can't make a statement like that and provide no
| examples. What are some of your ideas for doing that?
| h3lp wrote:
| The alcoholic knows the bad outcomes, and chooses to
| ignore them. The hapless Android user does not understand
| the negative consequences of sideloading. I think this
| makes for a substantial differerence between those two.
| mwwaters wrote:
| 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 question becomes not if the user trusts the phone's
| software, but if the _bank_ trusts the software on the user's
| phone. Should the bank not be able to trust the environment
| that can approve transfers, then the bank would be in the
| right to no longer offer such transfers.
| jibal wrote:
| I'm a "regular" person, as are all the signatories, and you
| don't speak for us.
| Hizonner wrote:
| 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.
| mwwaters wrote:
| 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.
| jasonjayr wrote:
| 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 is more or less how people expect things to work today
| ....
| mwwaters wrote:
| 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 different fiat currency or
| crypto), putting the ultimate link completely out of
| reach of the originating country.
|
| If intermediary banks are deputized and become liable in
| a no-fault sense, then legitimate transfers out become
| very difficult. How does a bank prove a negative for
| where the funds come from? De-banking has already been a
| problem for a process-based AML regime.
| jrm4 wrote:
| Keeeep going.
|
| Are banks POWERFUL? Do they have lots of money and/or
| connections to those who do? Do they have a vested interest
| in getting transactions right?
|
| Absolutely!
|
| Now, with all that money and power -- they -- whoever THEY
| are, need to come up with smart ways to verify transactions
| that don't involve me giving them all the keys to all my
| devices.
|
| We have protections like this elsewhere - even when they
| have some "ownership." The bank kinda owns my house, but
| they still can't come in whenever they want.
| kovek wrote:
| What if we asked users if they want extra protection? I think
| that would be nice..
| post-it wrote:
| This is the status quo. APK installation is disabled by
| default, and there is a warning when you go to enable it.
| scoofy wrote:
| 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 expect society to try to protect them at
| some level.
| progbits wrote:
| 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.
| hbn wrote:
| 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"
| pas wrote:
| then make the unlock cost money
|
| relatively easy for devs, but hard to scale for scammers
| giancarlostoro wrote:
| It's either that or as suggested, hard require developer
| validation for specific API permissions.
| mormegil wrote:
| 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.
| pmontra wrote:
| 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.)
| altruios wrote:
| 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.
| gmueckl wrote:
| 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. Android devices are the only category that is
| both widely available and affordable.
|
| Education is also not that effective. Spreading warnings
| about scams is hard and warnings don't reach many people for
| a whole laundry list of reasons.
|
| The status quo is decidedly not fine. Society must act to
| protect those that can't protect themselves. The only
| remaining question is the how.
|
| Google has an approach that would work, but at a high cost.
| Is there an alternative change that has the same effects on
| scammers, but with fewer issues for other scenarios?
| bigstrat2003 wrote:
| 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.
| philistine wrote:
| > The status quo may not be perfect but it is the best we
| can do.
|
| Nope. We could, for example, ask developers to register
| with their legal identity to release apps.
| bigstrat2003 wrote:
| That would be worse than the status quo.
| pas wrote:
| the open source community should ask for their own
| install key and that's it
|
| Play store can be fast and verification based and the
| F/OSS stores can be slower, reputation and review based.
|
| ...
|
| But fundamentally the easiest thing is to ask people to
| pay to unlock the phone's security barriers, this makes
| it harder and costlier for scammers.
| gmueckl wrote:
| 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.
| crazygringo wrote:
| > _Life is not safe, nor can it be made safe without taking
| away freedom._
|
| So... no food and safety regulations, because life is not
| safe, and people should have the freedom to poison food with
| cheaper, lethal ingredients because their freedom matters
| more?
|
| You're right that things can't be made more safe without
| taking away the freedom to harm people. Which is why even the
| most freedom-loving countries on earth _strike a balance_.
| They actually have _tons_ and _tons_ of safety regulations
| that save _tons_ and _tons_ of lives, even you from your
| point of view that means not "treating people as adults".
| You have to wear a seatbelt, even if you feel like you're not
| being treated like an adult. Because it's also not just your
| own life you're putting at risk, but your passengers' as
| well.
|
| You're taking the most extreme libertarian stance possible.
| Thank goodness that's an extremely minority view, and that
| the vast, vast majority of voters do actually think safety is
| important.
| iamnothere wrote:
| Thank goodness there are FOSS options, even for mobile
| phones, and none of us are required to accept proprietary
| junk.
|
| If they make FOSS illegal, guess I'll be a criminal. Come
| and take it.
| bigstrat2003 wrote:
| Your post is addressing a strawman, not what I said. But to
| answer the words you so ungraciously put in my mouth:
|
| > So... no food and safety regulations, because life is not
| safe, and people should have the freedom to poison food
| with cheaper, lethal ingredients because their freedom
| matters more?
|
| This is harm to others and is very obviously something we
| should enforce. There are unreasonable laws about food
| (banning the sale of raw milk cheese for example, which
| most of the world enjoys with perfect safety), but by and
| large they are unobjectionable.
|
| > You're right that things can't be made more safe without
| taking away the freedom to harm people. Which is why even
| the most freedom-loving countries on earth strike a
| balance.
|
| I never said I was opposed to striking a balance. Of course
| we can strike a balance. Indeed we already have when it
| comes to installing apps on Android. But these measures are
| being advanced as if safety were the only consideration,
| which it isn't.
|
| > You're taking the most extreme libertarian stance
| possible.
|
| No, that is what you have projected onto me. That's not
| actually what my stance is.
| jrm4 wrote:
| Your analogy is _terrible_ because it doesn 't do a proper
| accounting of "harm" and "risk."
|
| Food and seatbelts, that's literal health and life-and-
| death; very immediate and visible.
|
| "Cybersecurity" rarely is; and even when it is, the problem
| is that the centralized established authorities (like
| google) aren't at all provably good at this.
| pas wrote:
| If those bad decisions have a lot of higher order effects and
| they turn out to be very costly for society, then limiting
| freedom seems worth it.
|
| And it seems Google thinks society is beginning to unravel in
| SEA due to scammers. Trust breaks down, people stop using
| phones to do important things, GDP can shrink, banks go back
| to cheques, trees will be cut down!!
|
| It's bad to let people go and catch the zombie virus and the
| come back and spread it, right?
|
| ...
|
| I don't like it, but the obvious decision is to set up a
| parallel authority that can issue certificates to developers
| (for side loading), so we don't have to trust Google. Let the
| developer community manage this. And if we can't then Google
| can revoke the intermediary CA. And of course Google and
| other manufacturers could sell development devices that are
| unlocked, etc.
| TZubiri wrote:
| 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.
| danpalmer wrote:
| 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.
| TeMPOraL wrote:
| OTOH the controlling way modern software behaves is an US
| artifact, so the differences are not necessarily clear-cut
| like this.
|
| I grew up and live in Europe. I support the general idea of
| "regulation to make everyone safer" being an acceptable
| choice. At the same time, I vehemently oppose third-party
| interests reaching into _my computing device_ and dictating
| what I can vs. cannot do with it.
|
| But as you say, "global platforms with global impact and
| reach" - and so I can't set up my phone to conditionally
| read out text and voice messages aloud, because somewhere
| on the other side of the world, someone might get scammed
| into installing malware, therefore _let 's lock everything
| down and add remote attestation on top_.
|
| Unfortunately, the problem is political, not technological,
| and this here is but one facet of it. Ultimately, what SaaS
| does is give away all leverage: as users, it doesn't matter
| if we fully own the endpoints, or have a user-friendly
| vendor: any SaaS can ultimately decide _not to serve_ a
| client that doesn 't give the service a user-proof
| beachhead.
| hypeatei wrote:
| > but I think the community needs a better response
|
| The community _does not_ need to do that. Installing software
| on my device should not require identification to be uploaded
| to a third party beforehand.
|
| We're getting into dystopian levels of compliance here because
| grandma and grandpa are incapable of detecting a scam. I
| sympathize, not everyone is in their peak mental state at all
| times, but this seems like a problem for the bank to solve, not
| Android.
| iamnothere wrote:
| These people would try to ban _talking_ if the scams moved to
| in-person conversations. At some point individual
| responsibility has to come into play.
| 999900000999 wrote:
| How about.
|
| "I am responsible for my own actions" mode.
|
| You click that, the phone switches into a separate user space.
| Securenet is disabled, which is what most financial apps rely
| on.
|
| Then you can install all the fun stuff you want.
|
| This is really a matter of Google not sandboxing stuff right.
| Why the hell does App A need access to data or notifications
| from App B.
| AAAAaccountAAAA wrote:
| The new "Terminal" app might eventually evolve into something
| like that.
| thewebguyd wrote:
| > Why the hell does App A need access to data or
| notifications from App B.
|
| Advertising networks. Just like how you see crap like a
| metronome app have a laundry list of permissions that it
| doesn't need. Some cases they are just scammy data
| harvesters, but in other cases it's the ad networks that are
| actually demanding those permissions.
|
| Google won't sandbox properly because it's against their
| direct business interest for them to do so. Google's Android
| is adware, and that is the fundamental problem.
| renewiltord wrote:
| This mode already exists. It's called "Install LineageOS".
| Retr0id wrote:
| > the malware captures their two-factor authentication codes
|
| Aren't we supposed to have sandboxing to prevent this kind of
| thing? If the malware relies on exploiting n-days on unpatched
| OSes, they could bypass the sideloading restrictions too.
| UncleMeat wrote:
| Codes arrive via SMS, which is available to all apps with the
| READ_SMS permission. This isn't an OS vuln. It is a property
| of the fact that SMS messages are delivered to a phone number
| and not an app.
|
| On the Play store there is a bunch of annoying checking for
| apps that request READ_SMS to prevent this very thing. Off
| Play such defense is impossible.
| Retr0id wrote:
| If they restricted sideloaded apps from sniffing SMS then I
| wouldn't mind all that much.
| warkdarrior wrote:
| So no access to SMS for apps distributed on F-Droid?
| hahn-kev wrote:
| I like the idea of requiring extra work to get notification
| access. But really what all these scams pray on are time
| sensitivity, take that away and you solve the problem in many
| ways. For example, your bank shouldn't let you drain your
| account without either being in person or having a mandatory
| 24hr waiting period. Same could be done with side loaded apps
| getting notifications, if it's side loaded and wants to read
| notifications, then it needs to wait 24 hrs. Mostly it won't
| ever matter.
|
| Alternatively reading notifications could be opt in per app, so
| the reading app needs to have permission to read your SMS
| message app notifications, or your bank notifications, that
| would not be as full proof as that requires some tech literacy
| to understand.
| marcprux wrote:
| 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"1 feature (introduced in
| Android 13 and expanded in Android 14) addresses the specific
| scam technique of coaching someone over the phone to allow the
| installation of a downloaded APK. "Enhanced Confirmation
| Mode"2, introduced in Android 15, adds furthers protection
| against potentially malicious apps modifying system settings.
| These were all designed and rolled out with specified threat
| models in mind, and all evidence points to them working fairly
| well.
|
| For Google to suddenly abandon these iterative security
| improvements and unilaterally decide to lock-down Android
| wholesale is a jarring disconnect from their work to date.
| Malware has always been with us, and always will be: both
| inside the Play Store and outside it. Google has presented no
| evidence to indicate that something has suddenly changed to
| justify this extreme measure. That's what we mean by "Existing
| Measures Are Sufficient".
|
| [^1]: https://support.google.com/android/answer/12623953
|
| [^2]:
| https://android.googlesource.com/platform/prebuilts/fullsdk/...
| mirekrusin wrote:
| Would you say that iOS ecosystem suffers the same rate of
| malware as Android?
| tadfisher wrote:
| Of course not.
|
| In other news, a new study shows that cutting off your feet
| is 100% effective against athlete's foot.
| mirekrusin wrote:
| Haven't seen that one but I've seen working medication,
| it does exist on the market and does work, why not
| switching to use it?
| array_key_first wrote:
| The app store does contain malware, although arguably less
| than the play store. Apple devices would be much more
| secure without the app store. Apple should remove the app
| store.
| microtonal wrote:
| 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.
| workfromspace wrote:
| Not OP, but my experience was most of the malware-like apps
| on App Store were top ads of apps with names similar to the
| original ones: such as Whatsapp or Office.
| dfabulich wrote:
| I guess it's too late now, but I think "sufficient" is much
| too strong a word to use for that position, and puts Google
| in a position where they can disregard you because they
| "know" that existing measures aren't "sufficient."
|
| "Existing measures are working," perhaps?
| kodebach wrote:
| 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 "Existing Measures Are Sufficient." your
| letter also mentions
|
| > Developer signing certificates that establish software
| provenance
|
| without any explanation of how that would be the case. With
| the current system, yes, every app has to be signed. But
| that's it. There's no certificate chain required, no CA-
| checks are performed and self-signed certificates are
| accepted without issue. How is that supposed to establish any
| form of provenance?
|
| If you really think there is a better solution to this, I
| would suggest you propose some viable alternative. So far all
| I've heard for the opponents of this change is, either
| "everything is fine" or "this is not the way", while
| conveniently ignoring the fact that there is an actual
| problem that needs a solution.
|
| That said, I _do_ generally agree, with you that mandatory
| verification for *all* apps would be overkill. But that is
| not what Google has announced in their latest blog posts.
| Yes, the flow to disable verification and the exemptions for
| hobbyists and students are just vague promises for now. But
| the public timeline (https://developer.android.com/developer-
| verification#timelin...) states developer verification will
| be generally available in March 2026. Why publish this letter
| now and not wait a few weeks so we can see what Google
| actually is planning before getting everybody outraged about
| it?
| Dusseldorf wrote:
| 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.
| renewiltord wrote:
| > _all evidence points to them working fairly well._
|
| What is this evidence? Please share it.
| realusername wrote:
| Google's announcement is just trolling, there's an order of
| magnitude more scams on the Play store and they don't call for
| its closure.
|
| Right now when I search for "ChatGPT", the top app is a
| counterfeit app with a fake logo, is it really this store which
| is supposed to help us fight scams?
| warkdarrior wrote:
| > Right now when I search for "ChatGPT", the top app is a
| counterfeit app with a fake logo, is it really this store
| which is supposed to help us fight scams?
|
| Just did Play search for "ChatGPT" and the top-2 results were
| for OpenAI's app (one result was sponsored by OpenAI one
| result was from Google's search). So anecdotally your results
| may vary.
| raincole wrote:
| > standard security warnings
|
| 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.
| a456463 wrote:
| Maybe we should take away peoples' phone calls, ability to use
| knives, walking on the street, swimming in water, drinking
| liquids of any kinds, alcohol, trains, while we are at it.
| GeekyBear wrote:
| > I think the community needs a better response to this problem
| than "nuh uh, everything's fine as it is."
|
| People choosing between the smartphone ecosystems already have
| a choice between the safety of a walled garden and the freedom
| to do anything you like, including shooting yourself in the
| foot.
|
| You don't spend a decade driving other "user freedom" focused
| ecosystems out of the marketplace, only to yank those supposed
| freedoms away from the userbase that intentionally chose
| freedom over safety.
| chopin wrote:
| The main problem here is the banks relying on an untrusted
| device as second factor.
|
| Only immutable devices should be allowed as second factor.
| RHSeeger wrote:
| There will _always_ be a need to balance between safety and the
| cost of adding more safety. There is no point at which safety
| is complete; there is always more that can be done, but the
| cost gets higher and higher.
|
| So yes, "its fine the way it is" _is_ valid; but the meaning it
| "we're at a good point in the balance, any more cost is too
| much given the gains it generates"
| shaky-carrousel wrote:
| 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.
| microtonal wrote:
| 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.
| glenstein wrote:
| >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.
| pessimizer wrote:
| > 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.
| rogerallen wrote:
| 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.
| miloignis wrote:
| I have a radical solution - it should not be possible to
| contact someone unsolicited.
|
| All phone calls, SMS, emails, and instant messages should be
| blocked unless the other party is in my contacts or I have
| reached out to them first (plus opt-in contact from contacts of
| contacts, etc). Ideally, cryptographically verified.
|
| I would argue this is the real solution to spam and scamming -
| why on earth are random people allowed to contact me without my
| consent? Phone numbers or email addresses being all you need to
| contact me should be an artifact of an earlier time, just like
| treating social security numbers as secret.
|
| I realize this isn't super practical to transition existing
| systems to (though spam warnings on email and calls helps, I
| suppose, and maybe it could be made opt-in). I dearly hope the
| _next_ major form of communication works this way, and we
| eventually leave behind the old methods.
|
| Also, SMS shouldn't be used for 2FA anyway.
| kelp6063 wrote:
| why anyone thinks "open letters" and petitions to a trillion-
| dollar company will get them to change their mind is beyond me
| gleenn wrote:
| It matters to me because I'm reading it now and feel more
| informed about this problem. Throwing the towel in and saying
| it's all pointless isn't helpful.
| shimman wrote:
| It's not throwing in the towel, it's about doing things that
| we the people can actually do.
|
| One thing, we the people can do, is pressure our politicians
| to break up Google along with the rest of big tech.
|
| There are many primary challengers this cycle that are
| running anti-monopoly platforms. Help their cause, signing
| pointless petitions is just West Wing style fantasy that is
| extremely childish.
| jeroenhd wrote:
| It's something apps that will soon break can point their users
| to so they know to blame Google and a bunch of incompetent
| governments.
|
| Google will not change their minds, they're too busy buying
| goodwill from governments by playing along. There aren't any
| real alternatives to Android that are less closed off and they
| know it.
| Retr0id wrote:
| Because the company either has to address it, or stop
| pretending it's "listening to concerns" or whatever. Even if it
| doesn't change the outcome, it makes it clearer that the
| company is engaging in bad faith.
| jonathanstrange wrote:
| For me this change is a problem not just because of the ID upload
| to Google but mainly because it's another nail in the coffin of
| native software solutions. It increases friction and anything
| that increases friction is bad.
|
| Concretely, my original plan was to provide an .apk for manual
| installation first and tackle all this app store madness later. I
| already have enough on my plate dealing with macOS, Windows, and
| Linux distribution. With the change, delaying this is no longer
| viable, so Android is not only one among five platforms with
| their own requirements, signing, uploading, rules, reviews, and
| what not, it is one more platform I need to deal with _right from
| the start_ because users expect software to be multiplatform
| nowadays.
|
| Quite frankly, it appears to me as if dealing with app stores and
| arbitrary and ever changing corporate requirements takes away
| more time than developing the actual software, to the detriment
| of the end users.
|
| It's sad to watch the decline of personal computing.
| verdverm wrote:
| I personally see an unmoderated app store as more detrimental
| to the end users. The harm happens at scale.
| jonathanstrange wrote:
| When there were many different app stores to choose from,
| nobody would be forced to use an unmoderated app store. What
| happened to individual freedom and responsibility?
| verdverm wrote:
| I would need to see a widely used and trusted 3rd party
| store before leaving Google Play became a consideration.
| I'm interested, but not an early adopter. It's also unclear
| if any store that reaches this point doesn't institute
| similar moderation techniques. Scale incentivizes bad
| actors, which in turn requires good moderation.
| InsideOutSanta wrote:
| That's the status quo, though. Apple's App Store and Google's
| Play Store are essentially unmoderated. The sheer scale of
| them and both platforms' technical architectures prohibits
| either company from properly validating their stores'
| contents - they can't even catch the easy cases, like all the
| apps that impersonate ChatGPT. The main thing they manage to
| do is inconvenience innocent indie devs once in a while.
|
| The result is unwarranted trust from users in stores that are
| full of scams.
|
| Apple and Google effectively built malware pipelines under
| the guise of security.
| verdverm wrote:
| Why do you expect another app store to be different? At
| what scales do the dynamics of what you have described
| change?
| boje wrote:
| Uh, is having Aurora Store as a signatory a good idea? It's
| literally a Google Play Store bypassing tool.
| drnick1 wrote:
| 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.
| turblety wrote:
| Google are also destroying that path by delaying the releases
| more and more.
| wackget wrote:
| 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.
| microtonal wrote:
| Many banking apps work as long as you relock the bootloader.
| E.g. on GrapheneOS:
|
| https://privsec.dev/posts/android/banking-applications-
| compa...
| jamesnorden wrote:
| No bank in my country has an app that works with those, so it's
| not an option for me anymore.
| arjie wrote:
| 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.
| array_key_first wrote:
| 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.
| microtonal wrote:
| 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...
| drnick1 wrote:
| 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.
| dvh wrote:
| Wrong approach. Vote with your wallet instead. My next mobile
| phone will not have OS from Google (not from Apple).
| hollandheese wrote:
| Good luck with that.
| fsflover wrote:
| Works for me.
| yndoendo wrote:
| 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/
| cesarb wrote:
| > > Good luck with that.
|
| > 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.
| iamnothere wrote:
| My condolences, that sucks that you're stuck in such an
| authoritarian country. If you look at the PostmarketOS
| site, you may be able to find a legal phone (weird to
| type that phrase) that can be reflashed. Or you could buy
| one while on vacation, my guess is they don't check
| models at the border if it looks like a personal device.
| bitwize wrote:
| Illegal in Brazil per the Digital Child and Adolescent
| Statute. Operating systems are legally required to
| provide age verification functionality in a manner
| approved by the government.
| iamnothere wrote:
| Do they do inspections?
|
| Edit: apparently if it isn't a "marketable product" then
| the law may not apply. So far they haven't enforced it
| against Linux distros, likely because of this exception.
| However, IANAL (and definitely not a Brazilian lawyer).
| bitwize wrote:
| Indeed, and since Brazil now has mandatory age checking
| in the OS, it's illegal to own or operate such phones in
| the country, thus they will never be certified by ANATEL.
| thayne wrote:
| I would if there was a viable mobile phone OS I could switch
| to. iOS isn't any better. Linux phones, sadly, aren't very
| practical for daily use. AOSP based projects also have many
| limitations, and are still dependent on Google.
| jeroenhd wrote:
| What phone are you considering? Sailfish still doesn't seem
| very successful and mobile Linux barely boots on anything that
| performs better than a fifteen year old budget device.
|
| I'm kind of hoping Qualcomm's open sourcing work will also
| affect the ability to run mainline Linux on Android devices,
| but it's looking like a Linux OS that covers the bare basics
| seems to be a decade away.
| criddell wrote:
| 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.
| sdsd wrote:
| 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.
| criddell wrote:
| 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.
| shimman wrote:
| Oh yes, let me an individual out vote a trillion dollar
| corporation. That will surely work this time!
|
| I'm sorry but people that think this way tend to also think
| having money is some morality signal and not one of a massive
| personality defect (greed).
| jrm4 wrote:
| 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.
| octoclaw wrote:
| The real issue is that mandatory registration doesn't actually
| stop scammers. It stops hobbyist developers and small open source
| projects.
|
| Scammers will use stolen identities or shell companies. They
| already do this on the Play Store itself. The $25 fee and
| passport upload haven't prevented the flood of scam apps there.
|
| Meanwhile F-Droid's model (build from source, scan for
| trackers/malware) actually provides stronger guarantees about
| what the app does. No identity check needed because the code
| speaks for itself.
|
| The permission-based approach someone mentioned above makes way
| more sense. If your app wants to read SMS or intercept
| notifications, sure, require extra scrutiny. But a simple
| calculator app or a notes tool? That's just adding friction for
| no security benefit.
| jeroenhd wrote:
| The permission problem also affects normal apps. Things like
| KDE Connect quickly become useless without advanced
| permissions, for instance.
|
| No permission system can work as well as a proper solution
| (such as banks and governments getting their shit together and
| investing in basic digital skills for their citizens).
| rm30 wrote:
| 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.
| nickorlow wrote:
| Yeah, Google is terrible at validating developers are non-
| malicious on google play. plenty of fake/malicious/garbage apps
| make it through the filter.
| UncleMeat wrote:
| 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.
| array_key_first wrote:
| 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.
| tavavex wrote:
| The thing that everyone here ignores is that the friction isn't
| just for safety. It's by design. For some reason, everyone is
| giving Google as much benefit of the doubt as possible. But no,
| they want to drive out small developers in general, and this is
| just one piece of the puzzle. Google has already put up
| unrelated barriers to publishing apps on Google Play, required
| every app developer to dox themselves to every user (meanwhile
| Apple is far more permissive and allows an opt-out for non-
| commercial apps), they downrank apps by small developers, use
| alternate UX that disincentivizes installing lesser known apps,
| put up big scary warnings like "This app isn't installed often"
| or "Fewer people engage with this app" on the pages of those
| apps. The only explanation is that they want more money and
| less upkeep and moderation with the pesky small developers, and
| the real money-makers are the big corporate apps. They're
| recreating "the rich get richer" in their microcosm.
| EmbarrassedHelp wrote:
| 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.
| criddell wrote:
| > The problem with mandatory developer registration, is that it
| gives Google and Governments the ability to veto apps.
|
| Don't they already have that power?
| nickorlow wrote:
| You can download any APK you like on the internet and run it
| without google/gov getting in the way
| mhitza wrote:
| No, that is one reason why they are pushing for these
| changes.
| aftergibson wrote:
| No judgement whatsoever, but for almost everyone they too
| will think, no big deal you only install software through
| stores right? Nothing changes for them, in fact they can't
| conceive of an alternative anymore.
| criddell wrote:
| That's true.
|
| How can you judge if Google's plan is a good one? Add up
| the harms caused by the new rules and weigh that against
| the reduction in harm and see where the balance is?
|
| I have a hard time believing the net outcome for the
| overall Android community would be negative.
| OutOfHere wrote:
| 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.
| sunaookami wrote:
| No you can still install APKs offline but they have to be
| signed (likely enforced by Google Play Services). Not to
| mention you can still install unisgned APKs like before with
| adb. Which doesn't make this any better of course.
| dsl wrote:
| Dear Undersigned,
|
| I have an APK I would like you to install on your personal
| phones. No, I won't tell you who I am.
|
| Please let me know when you are comfortable with this.
| bigstrat2003 wrote:
| Nice strawman. People want the ability to decide for themselves
| whether or not to install some APK, they are not saying every
| APK under the sun is trustworthy.
| dsl wrote:
| It is a simplification, not a strawman.
|
| If you want to make the decision to install Hay Day, the user
| should be able to know that it is the Hay Day from Supercell
| or from Sketchy McMalwareson.
|
| 99.9% of apps should have no issue with their name being
| associated with their work. If you genuinely need to use an
| anonymously published app, you will still be able to do that
| as a user.
| nickorlow wrote:
| > If you genuinely need to use an anonymously published
| app, you will still be able to do that as a user.
|
| I'm pretty sure the goal of Google's changes is to make it
| so you can't
| NicuCalcea wrote:
| Android already tells users when they're installing
| software from outside the Play Store and shows big scary
| warnings if Play Protect is turned off. What else do you
| want? If I want to install something from Sketchy
| McMalwareson after all that, that's my phone and my
| business.
| nickorlow wrote:
| If I want to run a piece of software on my phone, I shouldn't
| need to go ask google whether they're cool with it
| exe34 wrote:
| No.
| zem wrote:
| sure, point me to the fdroid page for it
| rprend wrote:
| Side loading is an interesting hobby horse for hackers. It causes
| material harm to a lot of people. But hackers want to keep it
| anyway for themselves for ideological and aesthetic reasons.
| TJTorola wrote:
| Ideological is carrying a lot of weight there. Perhaps you can
| be more specific about the ideological arguments you are
| hearing that are not worth it?
| rprend wrote:
| Walled gardens have less fraud and malware because it's less
| open. But developers prefer open source decentralized
| software. Of course, we are technologically literate enough
| to avoid the fraud. It's similar to drug decriminalization or
| the legalization of sports gambling.
| mhitza wrote:
| Who says that Google is the one to decide what open source
| software I can install on my mobile Android computing device?
| rprend wrote:
| 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.
| mhitza wrote:
| 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.
| hypeatei wrote:
| Okay, then every book, every email, every text message, every
| comment, and every letter should be signed by a third party
| that's verified your ID. After all, there's speech which can
| cause material harm and free speech is just an ideological
| thing. It'd be dangerous if we allowed unsigned messages to be
| sent between people.
| jrm4 wrote:
| Citation please; and remember your answer is incomplete without
| a comparison to the safety of NON sideloaded apps.
| exe34 wrote:
| Does anyone know if this will affect Lineage OS with root?
| jech wrote:
| As far as I know, it's implemented in the proprietary part of
| Android (Google Mobile Services, GMS), so it won't affect
| LineageOS users as long as they don't install the GMS.
| iamnothere wrote:
| Just here to register my disapproval of this, and to remind
| everyone that you should support Linux phones if you're against
| it. Or Graphene OS, at the very least, even though this still
| supports Google due to the requirement for a Pixel phone.
|
| Also, 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!
| btreesOfSpring wrote:
| Would rather a more robust and distributed app store system that
| figures out how to police these edge cases of fraud rather than
| one vendor (Apple or Google) whose monopolies push developers
| into subscriptionware across the board. Something more akin to
| how internic moved from one domain name registrar to what we have
| today, chock full of competition and new top level domains.
|
| It feels like independent development on devices has slowed in
| recent years. More stores appealing to different developer
| models/tools and monetization strategies please.
| pserwylo wrote:
| Many people online and in person telling me "Google backed down"
| or "Google has an advanced flow" are typically referring to these
| two statements from Google staff:
|
| > Based on this feedback and our ongoing conversations with the
| community, we are building a new advanced flow that allows
| experienced users to accept the risks of installing software that
| isn't verified. [0]
|
| > Advanced users will be able to"Install without verifying," but
| expect a high-friction flow designed to help users understand the
| risks. [1]
|
| Firstly - I am yet to see "ongoing conversations with the
| community" from Google. Either before this blog post or in the
| substantial time since this blog post. "The community" has no
| insight into whether any such "advanced flow" is fit for purpose.
|
| Secondly - I as an experienced engineer may be able to work
| around a "high-friction flow". But I am not fighting this fight
| for me, I am fighting it for the billions of humans for whom
| smart phones are an integral part of their daily lives. They
| deserve the right to be able to install software using free,
| open, transparent app stores that don't require signing up with
| Google/Samsung/Amazon for the privilege of: Installing software
| on a device they own.
|
| One example of a "high friction flow" which I would find
| unacceptable if implemented for app installation on Android is
| the way in which browsers treat invalid SSL certificates. If I as
| a web developer setup a valid cert, and then the client receives
| an invalid cert, this means that the browser (which is -
| typically - working on behalf of the customer) is unable to
| guarantee that it is talking to the right server. This is a
| specific and real threat model which the browser addresses by
| showing [2]:
|
| * "Your connection is not private"
|
| * "Attackers might be trying to steal your information (for
| example, passwords, messages or credit cards)"
|
| * "Advanced" button (not "Back to safety")
|
| * "Proceed (unsafe)" link
|
| * "Not secure" shown in address bar forever
|
| In this threat model, the web dev asked the browser to ensure
| communication is encrypted, and it is encrypted with their
| private key. The browser cannot confirm this to be the case, so
| there is a risk that a MITM attack is taking place.
|
| This is proportionate to the threat, and very "high friction". I
| don't know of many non-tech people who will click through these
| warnings.
|
| When the developer uses HSTS, it is even more "high friction".
| The user is presented all the warnings above, but _no advanced
| button_. Instead, on Chromium based browsers they need to type
| "thisisunsafe" - not into a text box, just randomly type it while
| viewing the page. On Firefox, _there is no recourse_. I know of
| very few software engineers who know how to bypass HSTS
| certificate issues when presented with them, e.g. in a non-prod
| environment with corporate certs where they still want to bypass
| it to test something.
|
| If these "high friction" flows were applied to certified Android
| devices each time a user wanted to install an app from F-Droid -
| it would kill F-Droid and similar projects for almost all non-
| tech users. All users, not just tech users, deserve the right to
| install software on their smart phone without having to sign up
| for an "app store" experience that games your attention and tries
| to get you to install scammy attention seeking games that harvest
| your personal information and flood you with advertisements
|
| Hence, I don't want to tell people "Just install [insert non-
| certified AOSP based project here]". I want Android to remain a
| viable alternative for billions of people.
|
| [0] - https://android-developers.googleblog.com/2025/11/android-
| de...
|
| [1] - https://x.com/matt_w_forsythe/status/2012293577854930948
|
| [2] - https://wrong.host.badssl.com/
| cyanydeez wrote:
| When do we think PWA and WebRTC will be attacked and degraded as
| insecure?
| tsoukase wrote:
| Banning apps installation outside PlayStore will be a disaster
| for power-ish users and will start a fight between Google and
| community. I abandoned rooting my devices because I could achieve
| all I wanted through apps (mostly ad- and nag-freedom, it's
| impossible to be online without ad blocking). But all these were
| downloaded as APKs. I cannot imagine how the first day without
| these will be.
| WarmWash wrote:
| The judge told Google that Apple is not anti-competitive because
| Apple has no competitors on it's platform (this all stemming from
| the Epic lawsuits).
|
| Google listened.
|
| Blame the judge for one of the worst legal calls in recent
| history. Google is a monopoly and Apple is not. Simple fix for
| Google...
|
| Same comment I made a few days ago, I feel it bears repeating as
| much as possible until it's really driven home how detrimental
| and uninformed that decision was.
| pas wrote:
| Sorry, which exact ruling are you referring to? How did the
| court arrived at this finding (that seems irrelevant, false)?
| kodebach wrote:
| It is a non-sensical ruling. But IIRC the reason was
| basically that while Apple and Google did basically the same
| shit, only Google kept a written record of their monopolistic
| behaviour, so only Google was found guilty.
|
| However, there is a relevant court case here. The one about
| Samsung's "Auto Blocker"
| (https://arstechnica.com/gadgets/2025/07/samsung-and-epic-
| gam...). Epic Games sued because Samsung made it too hard to
| install apps from "untrusted" sources. This may be a reason
| why Google is now trying to make the process more difficult
| on the developer side instead.
| andyferris wrote:
| There were parallel anti-competitive behavior cases brought
| against Apple and Google.
|
| Apple was deemed not to be anticompetitive in app stores
| because there was no existing market of app stores on iOS.
| Google was more open in allowing other app stores, but deemed
| anticompetitive by discouraging their use relative to the
| Play store.
|
| The irony is the more open player was deemed more
| anticompetitive. OP is saying Google is "fixing" their
| anticompetitive behavior by eliminating alternative app
| stores entirely.
| andyferris wrote:
| Like many things in the US, this should be settled by congress
| not judges.
|
| Things that everyone relies on for life are generally regulated
| by law. Telecom platforms for instance. I'd say the mandatory
| software platform I need for my bank, drivers license, daily
| communication, etc should be in this bucket.
|
| The EU declaring both Apple and Google gateway platforms is a
| much better approach. Congress is abdicating its responsibility
| to craft the legal frameworks for equal access in the modern
| age.
| thegrim33 wrote:
| "Like many things in the US, this should be settled by
| congress"
|
| The US government is by design supposed to be as minimal as
| possible, and the laws affecting you kept as local as
| possible. We're not supposed to have a "the government"
| that's the same as EU governments. "The federal government
| should make laws" should be an absolute last resort. When you
| say "congress is abdicating its responsibility", I'd like you
| to point to where in the constitution it says that congress
| has such responsibilities.
| arjie wrote:
| If I'm being honest, I suspect this
|
| > _Disproportionate impact on marginalized communities and
| controversial but legal applications_
|
| applies more to the elderly in third-world countries who are
| constantly scammed through fraudulent side-loaded apps than it
| does to hackers who want to install whatever software they want
| but do not want to use a non-Google AOSP distribution.
| jdlyga wrote:
| To be honest, if both Android and iOS were walled gardens, I'd
| choose iOS every time. I choose Android specifically because of
| its openness. But if that weren't the case, I'd prefer the
| smoother UX and stronger Apple ecosystem.
| singpolyma3 wrote:
| You're welcome to it I suppose. As someone forced to use iOS
| for the past year I'm still waiting to find any smooth UX or
| strong ecosystem...
| asim wrote:
| I think we're about to see an explosion in "mini apps". It's
| taken 10+ years for us to catch up to WeChat and China but this
| regulation and other issues are going to block a lot of
| innovation and we're better off surfacing tiny PWA or SPA like
| apps that get loaded in native apps or we just do away with that
| entirely. The time has come.
| TheJoeMan wrote:
| Elon's vision for the X "everything" app. It's great for them,
| now every single thing you do has the full gamut of privacy
| permissions. Playing a "mini-game"? Full accurate GPS
| coordinates available to it because you also have the ride-
| hailing "mini-app".
| TZubiri wrote:
| 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.
| atlgator wrote:
| "Don't be evil" - "Don't be evil without registering first and
| uploading your government ID."
|
| The most telling detail is the sequencing. Google spent years in
| court arguing Android is open to fend off antitrust regulators,
| won key battles on that basis, and is now quietly closing the
| door they swore under oath was permanently propped open. The
| antitrust defense was the product roadmap's cover story. And
| framing this as security is particularly rich from the company
| whose own Play Store routinely hosts malware that passes their
| review. The problem they're solving isn't "unverified developers
| distribute harmful apps" -- it's "unverified developers
| distribute apps we can't monetize or control."
___________________________________________________________________
(page generated 2026-02-24 23:00 UTC)