11–20 of 392 posts
why anyone thinks "open letters" and petitions to a trillion-dollar company will get them to change their mind is beyond me
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…
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.
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.
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…
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...
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 Li…
I personally see an unmoderated app store as more detrimental to the end users. The harm happens at scale.
Wrong approach. Vote with your wallet instead. My next mobile phone will not have OS from Google (not from Apple).
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…
You can also cut yourself with a kitchen knife but nobody proposes banning kitchen knives. Google and the state are not your nannies.
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…
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.
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.
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.