> 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...?
> 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".
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"
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?
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.
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.
> 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".
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.
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.
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.
I am the author of the letter and the coordinator of the signatories. We aren't saying "nuh uh, everything's fine as it is." Rather, we are pointing out that Android has progressively been enhanced over the years to make it more secure and to address emerging new threat models.
For example, the "Restricted Settings"¹ feature (introduced in Android 13 and expanded in Android 14) addresses the specific scam technique of coaching someone over the phone to allow the installation of a downloaded APK. "Enhanced Confirmation Mode"², 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".
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."
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?
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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?
>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.
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.
> 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.
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.
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.
I'm not sure if you understand what makes passkeys phishing-resistant?
The backdoored version of the app would need to have a different app ID, since the attacker does not have the legitimate publisher's signing keys. So the OS shouldn't let it access the legitimate app's credentials.
Correction: nothing prevents the attacker from using the app's legit package ID other than requiring the uninstall of the existing app.
The spoofed app can't request passkeys for the legit app because the legit app's domain is associated with the legit app's signing key fingerprint via .well-known/assetlinks.json, and the CredentialManager service checks that association.
> 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.
>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)
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
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.
> 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.
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).
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.
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.
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.
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.
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?
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.
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.
The problem with mandatory developer registration, is that it gives Google and Governments the ability to veto apps.
It would not be unsurprising for a government to tell Google they must block any VPN apps from being installed on devices, and Google using the developer requirements to carry out the ban.
It's worse than that. Google will be able to track who's using a particular app because it has to be installed the official way. This means for example that anyone who has installed an ICE Tracking app will be reported to the government and perhaps added to a terrorist list.
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.
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.
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.
Isn't the obvious solution to use an AOSP fork that does not have to comply with the registration requirements? Distributions like Graphene and Lineage are completely unaffected.
No, because many apps refuse to run on third-party distros due to misguided notions of them being insecure. It's easy to say "just don't use those apps" but in reality, people are rightly unwilling to put up with any friction and so will simply continue to use Google's version of the OS.
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.
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.
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.
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.
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.
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.
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.
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.
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]
> 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.
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.
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.
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.
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.
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!
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.
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.
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.
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?
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 that decision was.
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...?
> 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".
What if we asked users if they want extra protection? I think that would be nice..
This is the status quo. APK installation is disabled by default, and there is a warning when you go to enable it.
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"
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?
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.
> 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.
If there was a choice to a non-walled garden. It has been taken away, how can you bank without one of the two?
You're right, all Android users who are upset about this change are free to switch to iOS.
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.
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.
> 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.
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.
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.
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.
I'm a "regular" person, as are all the signatories, and you don't speak for us.
I am the author of the letter and the coordinator of the signatories. We aren't saying "nuh uh, everything's fine as it is." Rather, we are pointing out that Android has progressively been enhanced over the years to make it more secure and to address emerging new threat models.
For example, the "Restricted Settings"¹ feature (introduced in Android 13 and expanded in Android 14) addresses the specific scam technique of coaching someone over the phone to allow the installation of a downloaded APK. "Enhanced Confirmation Mode"², 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/...
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?
Would you say that iOS ecosystem suffers the same rate of malware as Android?
Of course not.
In other news, a new study shows that cutting off your feet is 100% effective against athlete's foot.
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?
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.
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.
> 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.
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.
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.
> 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.
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?".
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.
the main issue is the bank using sms and OTP apps instead of something like passkeys and mandatory in bank setup.
One of my banks uses a card reader and pin to log in, seems more secure.
> The bank will NEVER ask you for this code!
> Please enter the code we sent you in the app.
lol, lmao even
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
Obviously I disagree completely. But it is still sad to see this kind of reasoning on HN of all places :(
If you want a picture of the future, imagine a boot stamping on a human face — for $29.95/month.
Show HN: O'Brien (YC S29), new AI-powered Boot as a Service provider
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.
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?
>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.
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.
> 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.
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.
We know how to do hardware-bound phishing-resistant credentials now, it is a solved problem.
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.
SMS 2FA is neither hardware-bound nor phishing resistant, I'm referring to hardware-bound phishing-resistant 2FA methods like passkeys.
Read my previous comment again. Passkeys are nice, but they don't solve the problem that's being discussed here.
I'm not sure if you understand what makes passkeys phishing-resistant?
The backdoored version of the app would need to have a different app ID, since the attacker does not have the legitimate publisher's signing keys. So the OS shouldn't let it access the legitimate app's credentials.
Correction: nothing prevents the attacker from using the app's legit package ID other than requiring the uninstall of the existing app.
The spoofed app can't request passkeys for the legit app because the legit app's domain is associated with the legit app's signing key fingerprint via .well-known/assetlinks.json, and the CredentialManager service checks that association.
> 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.
> 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.
>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)
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.
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.
All of these rules, and yet people still cut themselves and others.
you cant buy a kitchen knife that is too long
What?
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.
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”.
Doesn’t editing require a karma threshold?
it does not (thankfully!)
Apostrophe's don't have a karma threshold, either. ;-)
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...
Long knives in the UK are like full auto guns in the rest of the world.
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.
> 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.
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.
> 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.
The new "Terminal" app might eventually evolve into something like that.
> 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.
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.
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.
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.
> 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.
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.
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).
> 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.
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.
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?
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.
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.
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?
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?
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...
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.
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.
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.
> 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?
You can download any APK you like on the internet and run it without google/gov getting in the way
No, that is one reason why they are pushing for these changes.
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.
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.
Registration just creates friction for legitimate developers (thousands) while bad actors simply rotate shell companies and fake/stolen IDs.
This conflates identity verification with criminal deterrence, they're not the same thing.
Friction does matter. Yes, criminals will create fake accounts with stolen IDs and stolen credit cards. But creating 1,000s of these is hard. Creating polymorphic banking trojans is simple.
I don't know if this trade off is worth it, but the idea that it won't affect this abuse at all is false.
Yeah, Google is terrible at validating developers are non-malicious on google play. plenty of fake/malicious/garbage apps make it through the filter.
The undersigned are basically a list of entities Google would like to see disappear.
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.
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.
Google are also destroying that path by delaying the releases more and more.
No bank in my country has an app that works with those, so it's not an option for me anymore.
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.
why anyone thinks "open letters" and petitions to a trillion-dollar company will get them to change their mind is beyond me
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.
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.
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.
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.
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.
Wrong approach. Vote with your wallet instead. My next mobile phone will not have OS from Google (not from Apple).
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.
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).
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.
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.
Good luck with that.
No luck needed.
Linux based phones are starting to become viable as daily drivers. [0] They are even coming with VM Android in case an application is needed that does not have a Linux equivalent.
I am interested in how Google's gatekeeper tactics are going to affect Android like platforms such as /e/os and GrapheneOS. [1]
[0] http://furilabs.com/
[1] https://murena.com/america/products/smartphones/
> > 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.
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.
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.
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.
Works for me.
When do we think PWA and WebRTC will be attacked and degraded as insecure?
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/
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!
Does anyone know if this will affect Lineage OS with root?
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.
Uh, is having Aurora Store as a signatory a good idea? It's literally a Google Play Store bypassing tool.
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.
I personally see an unmoderated app store as more detrimental to the end users. The harm happens at scale.
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.
Why do you expect another app store to be different? At what scales do the dynamics of what you have described change?
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?
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.
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.
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).
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.
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
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.
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.
> 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
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.
sure, point me to the fdroid page for it
No.
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.
Who says that Google is the one to decide what open source software I can install on my mobile Android computing device?
Wym? Google says it’s the one to decide. They are doing this because side loading causes fraud. There is pressure and lobbying (like this open letter) to stop them from locking it down.
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.
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?
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.