[dfabulich]

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

[bigstrat2003]

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

[kovek]

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

[em-bee]

the problem is that in developing countries smart phones are a massive technology jump for people who lack the education to even have a clue whats going on. treating people as adults does not work if they don't have the education needed for that.

these people aren't gullible. they are ignorant (in the uneducated sense). they are not making bad decisions. they are not even aware that there is a decision to be made.

and worst of all, this problem affects the majority of those populations. if more than half of our population was alcoholic then we absolutely would restrict the access to alcohol through whatever means possible.

it's a pandemic. and we all know what restrictions that required.

[danpalmer]

Cars worked fine without seatbelts too. Just because the world goes on doesn't mean we can't do better.

Taking a step back though, I suspect there are cultural differences in approach here. Growing up in Europe, the idea of a regulation to make everyone safer is perfectly acceptable to me, whereas I get the impression that many folks who grew up in the US would feel differently. That's fine! But we also have to recognise these differences and recognise that the platforms in question here are global platforms with global impact and reach.

[mwwaters]

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.

[zeroxfe]

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

[gmueckl]

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?

[pas]

If those bad decisions have a lot of higher order effects and they turn out to be very costly for society, then limiting freedom seems worth it.

And it seems Google thinks society is beginning to unravel in SEA due to scammers. Trust breaks down, people stop using phones to do important things, GDP can shrink, banks go back to cheques, trees will be cut down!!

It's bad to let people go and catch the zombie virus and the come back and spread it, right?

...

I don't like it, but the obvious decision is to set up a parallel authority that can issue certificates to developers (for side loading), so we don't have to trust Google. Let the developer community manage this. And if we can't then Google can revoke the intermediary CA. And of course Google and other manufacturers could sell development devices that are unlocked, etc.

[crazygringo]

> Life is not safe, nor can it be made safe without taking away freedom.

So... no food and safety regulations, because life is not safe, and people should have the freedom to poison food with cheaper, lethal ingredients because their freedom matters more?

You're right that things can't be made more safe without taking away the freedom to harm people. Which is why even the most freedom-loving countries on earth strike a balance. They actually have tons and tons of safety regulations that save tons and tons of lives, even you from your point of view that means not "treating people as adults". You have to wear a seatbelt, even if you feel like you're not being treated like an adult. Because it's also not just your own life you're putting at risk, but your passengers' as well.

You're taking the most extreme libertarian stance possible. Thank goodness that's an extremely minority view, and that the vast, vast majority of voters do actually think safety is important.

[TZubiri]

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

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

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

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

[acac10]

You say that until it happens to your mother/father/bf/gf/grandparent/…

Then we will see how you will react.

[gretch]

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

[marcprux]

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

[svat]

This is what I was able to find with some quick searching:

- From Dec 2024 there's https://www.bangkokpost.com/business/general/2915570/state-g... and https://theinvestor.vn/thai-govt-collaborates-with-google-to... which list some efforts done in “collaboration between the Digital Economy and Society (DES) Ministry [of Thailand] and Google”. It mentions “The initiative started in April, providing the Google Play Protect feature”, which “blocked attempts by criminals to install apps more than 4.8 million times on more than 1 million Android devices”. And https://www.nationthailand.com/blogs/business/tech/40036973 is from earlier (Apr 2024), about the introduction of the Google Play Protect feature.

- From April 2025 there's https://blog.google/company-news/inside-google/around-the-gl... a blog post from a “VP, Government Affairs & Public Policy”, which mentions “people in Asia Pacific feel it acutely, having lost an estimated $688 billion in 2024” (I think this may be across all scams?) and ends with “Combatting evolving online fraud in Asia-Pacific is critical” after listing a bunch of random things (unrelated to Android) Google is/was doing. This suggests to me that Google was under some criticism/pressure from governments for enabling scams, and eager to say “see, we're doing something”.

- The developer verification announcement came four months later in August 2025: https://android-developers.googleblog.com/2025/08/elevating-...

> In early discussions about this initiative, we've been encouraged by the supportive initial feedback we've received. In Brazil, the Brazilian Federation of Banks (FEBRABAN) sees it as a “significant advancement in protecting users and encouraging accountability.” This support extends to governments as well, with Indonesia's Ministry of Communications and Digital Affairs praising it for providing a “balanced approach” that protects users while keeping Android open. Similarly, Thailand’s Ministry of Digital Economy and Society sees it as a “positive and proactive measure” that aligns with their national digital safety policies.

This shows that it was a negotiation with the governments/agencies in Brazil, Indonesia, Thailand that were breathing down on Google to do something.

- The fourth country where this developer verification is rolling out first is Singapore, and https://www.channelnewsasia.com/singapore/android-malware-sc... is from Sep 2023 while https://www.channelnewsasia.com/singapore/google-android-dev... is from Feb 2024 which mentions that a certain upgrade to Google Play Protect (blocking apps if they “demands suspicious permissions such as access to restricted data like SMSes and phone notifications”) was first rolling out in Singapore.

- And the most recent https://android-developers.googleblog.com/2025/11/android-de... from November 2025 (which promised the “students and hobbyists” account type and the “experienced users” flow “in the coming months”) also has a “Why verification is important” section that mentions the “consistently acted to keep our ecosystem safe” and “common attack we track in Southeast Asia” and “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”.

The overall picture I get is less of “Google to suddenly abandon these iterative security improvements” but more like: under pressure from governments to stop scams, Google has been doing various things like the things you mentioned, and scammers have also been evolving and finding new ways to carry out scams at scale (like “impersonating developers”), and the latest upcoming change requiring developer verification on “certified Android devices” is simply the next step of the iteration. It sucks and feels like a wholesale lock-down, yes, but it does not seem a jarring disconnect from the previous steps in the progression of locking things down.

[dfabulich]

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?

[renewiltord]

> all evidence points to them working fairly well.

What is this evidence? Please share it.

[mirekrusin]

Would you say that iOS ecosystem suffers the same rate of malware as Android?

[kodebach]

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?

[jeroenhd]

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.

[kodebach]

My guess is that Android 17 will show the registered name of the developer of the app you're trying to install. With stolen IDs you can only get accounts for individual developers not for organisations.

When a scammer pretending to be your bank tells you to install an app for verification and it says "This app was created by John Smith" even grandma will get suspicious and ask why it doesn't show the bank's name.

[gjsman-1000]

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

[JoshTriplett]

If you can "coach someone to ignore standard security warnings", you can coach them to give you the two-factor authentication codes, or any number of other approaches to phishing.

[harikb]

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.

[nine_k]

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

[thousand_nights]

yeah the thing is, if someone can social engineer you on the phone and make you do their bidding, you've lost no matter what

[mwwaters]

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.

[instagib]

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.

[Cyph0n]

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.

[tzs]

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.

[bitwize]

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.

[Tharre]

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.

[RandomGerm4n]

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.

[singpolyma3]

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

[Retr0id]

We know how to do hardware-bound phishing-resistant credentials now, it is a solved problem.

[pessimizer]

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

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

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

> I agree that mandatory developer registration feels too heavy handed, but I think the community needs a better response to this problem than "nuh uh, everything's fine as it is."

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

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

[hahn-kev]

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.

[cherryteastain]

> community needs a better response to this problem than "nuh uh, everything's fine as it is."

You can also cut yourself with a kitchen knife but nobody proposes banning kitchen knives. Google and the state are not your nannies.

[john_strinlai]

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

[ranger_danger]

Laws protect people from being hurt by others, keeping society safe and fair for everyone.

[darkwater]

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

[jcynix]

>I agree that mandatory developer registration feels too heavy handed, but I think the community needs a better response to this problem than "nuh uh, everything's fine as it is."

OK, so instead of educating stupid (or overly naive) people, we implement "protections" to limit any and all people to do useful things with their devices? And as a "side effect" force them to use "our" app store only? Something doesn't smell that good here …

How about a less drastic measure, like imposing a serious delay for "side loading" … let's say I'd to tell my phone that I want to install F-Droid and then would have to wait for some hours before the installation is possible? While using the device as usual, of course.

The count down could be combined with optional tutorials to teach people to contact their bank by phone meanwhile. Or whatever small printed tips might appear suitable.

[warkdarrior]

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

[shaky-carrousel]

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

[microtonal]

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

[realusername]

Google's announcement is just trolling, there's an order of magnitude more scams on the Play store and they don't call for its closure.

Right now when I search for "ChatGPT", the top app is a counterfeit app with a fake logo, is it really this store which is supposed to help us fight scams?

[warkdarrior]

> Right now when I search for "ChatGPT", the top app is a counterfeit app with a fake logo, is it really this store which is supposed to help us fight scams?

Just did Play search for "ChatGPT" and the top-2 results were for OpenAI's app (one result was sponsored by OpenAI one result was from Google's search). So anecdotally your results may vary.

[verdverm]

Agree with this middle path you point out. On one hand, I do not want some apps to be distributed anonymously, I need to know who is behind it in order to trust the app. On the other hand, many apps are benign.

Permissions are a great way to distinguish.

[amiga386]

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?

[Retr0id]

> the malware captures their two-factor authentication codes

Aren't we supposed to have sandboxing to prevent this kind of thing? If the malware relies on exploiting n-days on unpatched OSes, they could bypass the sideloading restrictions too.

[UncleMeat]

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.

[kotaKat]

You can’t even win with adding more scare screens because as soon as Epic isn’t allowed to bypass the scare screens, they’ll sue you.

Just like they went after Samsung for adding friction to the sideload workflow to warn people against scams.

https://www.macrumors.com/2024/09/30/epic-games-sues-samsung...

[daveidol]

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.

[chopin]

The main problem here is the banks relying on an untrusted device as second factor.

Only immutable devices should be allowed as second factor.

[glenstein]

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

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

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

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

[999900000999]

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.

[thewebguyd]

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

[AAAAaccountAAAA]

The new "Terminal" app might eventually evolve into something like that.

[renewiltord]

This mode already exists. It's called "Install LineageOS".

[hypeatei]

> but I think the community needs a better response

The community does not need to do that. Installing software on my device should not require identification to be uploaded to a third party beforehand.

We're getting into dystopian levels of compliance here because grandma and grandpa are incapable of detecting a scam. I sympathize, not everyone is in their peak mental state at all times, but this seems like a problem for the bank to solve, not Android.

[iamnothere]

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.

[GeekyBear]

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

[RHSeeger]

There will _always_ be a need to balance between safety and the cost of adding more safety. There is no point at which safety is complete; there is always more that can be done, but the cost gets higher and higher.

So yes, "its fine the way it is" _is_ valid; but the meaning it "we're at a good point in the balance, any more cost is too much given the gains it generates"

[rogerallen]

I wonder if putting this choice on the user would be most appropriate?

People fearful about being scammed should buy a phone with a hardware lock to prevent it from ever accepting sideloads--no option to go to dev mode, ever. You could even charge more for the extra security.

People who want the freedom to sideload can choose to buy a phone without the extra hardware security feature.

[MSFT_Edging]

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.

[daveidol]

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

[bonoboTP]

> protect the vulnerable (elderly, mentally disabled, etc)

Yes, one could imagine some kind of mental test and if you fail you don't get to use your bank online, you have to walk to the physical location to make transactions. But this can obviously be abused to shut out people from banking based on political and other aspects. Generally democracies are wary of declaring too broad sets of people as incapable of acting independently without some guardian. Obviously beyond a certain threshold of mental incapacitation, dementia etc. it kicks in, but just imagine declaring that you're too easy to influence and scam and we can't let you handle your money,... But somehow we can rely on you using sane judgment when voting in elections. Or should we strip election rights too?

We rely on polite fictions around the abilities of the average person. The contradictions sometimes surface but there is no simple way to resolve it without revising some assumptions.

[miloignis]

I have a radical solution - it should not be possible to contact someone unsolicited.

All phone calls, SMS, emails, and instant messages should be blocked unless the other party is in my contacts or I have reached out to them first (plus opt-in contact from contacts of contacts, etc). Ideally, cryptographically verified.

I would argue this is the real solution to spam and scamming - why on earth are random people allowed to contact me without my consent? Phone numbers or email addresses being all you need to contact me should be an artifact of an earlier time, just like treating social security numbers as secret.

I realize this isn't super practical to transition existing systems to (though spam warnings on email and calls helps, I suppose, and maybe it could be made opt-in). I dearly hope the next major form of communication works this way, and we eventually leave behind the old methods.

Also, SMS shouldn't be used for 2FA anyway.

[cjmoran]

I have an even more radical solution. The real root of the problem is that we use this "money" concept to represent value. If money didn't exist there wouldn't be any reason to steal, hack, or scam.

What do we replace it with? Haha, idk man. How about water? More difficult to hoard in ridiculous quantities, better spend it before it evaporates, and it occasionally falls from the sky (UBI). That's what I call a liquid asset!

[wilsonnb3]

How are you going to reach out to someone first if all communication is blocked because they don't already know you?

[a456463]

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.

[eviks]

Are you not aware of cases where marks physically went to the bank, withdrew all cash and dropped it off to the criminals, also taking out loans and yelling at bank employees when they were trying to stop them? No app involved.

You'll always find individual cases where people do extremely dumb stuff, but using that as a justification is also dumb. If you want to significantly curtail that freedoms of a large group, it's on you to come up with a good evaluation of tradeoffs, so

> the community needs a better response to this problem than "nuh uh, everything's fine as it is."

They already have, but you choose to use a fake simplification as a representative

[cyberrock]

Ah this explains why so many banks are making their own 2FA apps with warnings to never share the codes. Well a lot of people are very annoyed to install them because they perceive it as a technological downgrade when it's the opposite. I can only imagine asking them to use passkeys or hardware keys would be difficult, especially if there is some FUD (or truth?!) about how $boogeyman has your keys if you use them.

[raincole]

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