WebAssembly Components aren't nearly enough to accomplish what this article offers to accomplish. Even once components are a thing, you'd then have to restandardize the entire Web API in their new IDL, WIT.

The WebIDL specifications have taken decades to standardize. It requires Apple, Mozilla, Google, and Microsoft to agree on everything. Getting all of them to agree to restandardize on a new IDL is not going to happen this decade.

I've actually tried to do that the past and got pretty far. https://github.com/wasi-gfx/webidl2wit

And here's the generated wit https://github.com/mendyberger/brow

Yes, electricity was useful. And it had hyperbolic articles talking about how transformative it would be. Like all prognostication, some of those articles were overblown, but, in some ways, they understated the transformative effect electricity would have on human history.

And cars? Did you somehow miss the influx of hyperbolic articles about how cars will change everything? Like, the whole 20th century?

What was your approach to researching the history of media hype? You somehow overlooked the hype around air travel, refrigeration, and antibiotics…?

200 years ago the was some hype around how electricity caused mussel contractions in dead flesh, but unless you consider Frankenstein part of the hype cycle it really doesn’t compare to how much people hyped social media etc etc.

Public street lights long predated light bulbs as did both indoor and outdoor Gas lighting 1802 vs 1880’s was just a long time. People were burn, grew up, had kids, and become old between the first electric lighting and the first practical electric bulb. People definitely appreciated the improvement to air quality etc, but the tech simply wasn’t that novel. Rural electrification was definitely promoted but not because what it did was some unknown frontier.

Similarly electric motors had a lot of competition, even today there’s people buying pneumatic shop tools.

It absolutely is. Frankenstein is a seminal work of science-fiction horror, and the mysterious power of electricity to change everything is what made it so chilling to its readers in the 19th century.

> it really doesn’t compare to how much people hyped social media

The media is considerably different now from in 1818, thanks, in significant part, to the power of electricity. I assure you, when the electrical telegraph came on the scene, people were hyped.

Of course, much of that hype was on paper printed on printing presses, so it was, in some sense, "incomparable" to the hype possible on cable television, or the hype that's now possible with online social media.

But if your argument is "Yeah, electricity was kinda hyped, but, you know, not all that hyped, so it proves my point that the more the hype, the less the impact," you have some more research to do. Please just Google "War of the Currents" for a minute.

It was published as Fiction. The vast majority of people didn’t think it was anymore realistic than Interstellar etc.

There’s plenty of stories where we cure cancer, but the 50% improvement in cancer treatments over the last 40 years just doesn’t get much hype because it’s so slow. It’s hard to get excited about the idea cancer may be gone in 200 years because while that will be awesome for people alive then it doesn’t do anything for the people I know.

> electric telegraph came online people where hyped.

Objectively it got way more of a meh reaction than you’d think simply based on the timelines involved.

France was happy to continue using its network of optical telegraphs long after the electrical telegraph became a practical thing. Transatlantic telegraphs got hyped up somewhat, but again the technology took so long from the first serious attempt to a practical working system people understood the limitations inherent to having such limited bandwidth between the contents.

Obviously new technology gets attention because it’s a net improvement, being able to send messages across the US much faster was useful. But hype is different, it’s focused on second order effects not what it does but what will change. The original iPhone isn’t just another cellphone that also takes pictures, it’s “the internet in your pocket.”

Technology can be quite useful directly and have significant second order effect, hype is about the second order effects being overblown. Second order effects are difficult to predict when something is actually novel, will LLM’s make programming obsolete is harder to answer in 2023 than 2063.

Home automation like dishwashers really did meaningfully impact how much effort was needed to keep a home livable, but we didn’t predict the kind of helicopter parenting that happened because of more free time especially after smaller families became common. Thus a great majority of incorrect predictions where just hype.

The faster new technology becomes widespread the harder it is to predict those second order effects and thus more hype you see.

Mmm..they didn't, at that time.

That we grew to be dependent on the computer in the pocket does not mean that it was a necessity at any point.

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

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

There are alternative solutions if the true goal is maintaining user freedom while protecting dumb users. But that is not the true goal of the upcoming changes.

Fine, just:

- Don't reset it every 5 days / 5 hours / 5dBm blip in Wi-Fi strength, because this pretty much defeats end-user automation, whether persistent or event-driven. This is the current situation with "Wireless Debugging", otherwise cool trick for "rootless root", if it only didn't require being connected to Wi-Fi (and not just a Wi-Fi, but the same AP, breaking when device roams in multi-AP networks).

- Don't announce the fact that this is on to everyone. Many commercial vendors, including those who shouldn't and those who have no business caring, are very interested in knowing whether your device is running with debugging features enabled, and if so, deny service.

Unfortunately, in a SaaS world it's the service providers that have all the leverage - if they don't like your device, they can always refuse service. Increasingly many do.

Prediction: Android will roll out a flow for “experienced users” that they promised in November with “in the coming months” (https://android-developers.googleblog.com/2025/11/android-de...), which will allow “experienced users to accept the risks of installing software that isn't verified”. And even then people will still complain Google is being too controlling by making the warnings too scary / the process too onerous, etc. (I don't expect installing apps from source via adb connected to laptop to go away!)

A non-trivial number of people should probably have to go see a specialist before being able to unlock sideloading in my opinion... which means we probably all would have to. It's annoying, but I actually care about other people.

Doesnt android require a specific permission to be user-accepted for an installed app to read notifications? I think it's separate from the post-notifications permission.

This seems to be an issue of user literacy. If so, doesn't it make more sense for a user to have the option to opt into "I'm tech illiterate, please protect me" than destroy open computing as we know it?

In an ideal world where governments and corporations weren't trying to lock us into a closed system for massive surveillance and control, during the installation/setup of a mobile phone should be a question about tech literacy and protection. Selecting any option that isn't "I'm tech illiterate, please protect me" should be very annoying. There should be many warnings in uppercase bold red letters telling the user it can be dangerous and listing those dangers. But if I'm a developer and want to patch my kernel or modify the system as I please, I should be able to do so. If i want to install a malware app in a burner phone to study its behavior (or just for fun) I should be able to do so.

There would probably be one or two grandmas that would still somehow choose the pro hacker mode and get scammed down the line, but I think that minuscule amount of harm done is very much preferable to closing out *literally everyone else* from using the devices THEY BOUGHT.

But I'm afraid that this is security theater and the true goal is to protect revenues by making it hard or impossible to install apps that impact Alfabet bottom line (eg third party YouTube clients.)

It's not just them. Every other SaaS, from banks to media providers to E2EE[0] chat clients to random apps whose makers feel insecure, or are obsessed with security [theater] best practices, just salivate at the thought of being able to check if you're a deviant running with root or debugging privileges, all because ${complex web of excuses that often sound plausible if you don't look too closely}. There's a huge demand for device attestation, remote or otherwise.

--

[0] - End-to-end Enshittified.

It solves the 'smartest bear / dumbest human' overlap design concern in this situation.

But I guess not reading the TOS is another wide problem, also fueled by companies like Google.

Developers want developer phones, non-developers want safe phones that are resistant to their and their shitty bank's goddamn fucking stupidity. (Because banks UX is so so so so bad that most of the time the phishing attack seems like just a normal part of the bank's UX.)

But it's hard to separate people on a webshop, if a shop runs out of non-developer phones they'll happily sell the developer phones to non-developers.

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.

-- C.S. Lewis

the correct solution is of course education, but education takes time. we can educate today's children so that they can protect themselves in the future. but that's the next generation. for the current generation that kind of education is to late.

the proposed solution is a stopgap measure. do you have a better idea how to solve the problem? (maybe putting more effort into persecution, but that costs money. or making banks responsible for covering the loss. but then you'll get banks demanding the protection. tyranny of the banks then? is that any better? that's actually happening in europe now.)

not doing anything will hurt a lot of people and make them unhappy. as a government you really don't want that either.

how does it do that? (i am not getting hung up on "intuitive", i just mean you argue that the currently used design fuels incompetence)

how is a UI designed that doesn't fuel incompetence?

i have a hard time imagining what design aspects matter here, and how to improve upon them.

I'm specifically talking about UX ("how a user interacts with and experiences a product, system, or service"), not necessarily UI.

> how does it do that? (i am not getting hung up on "intuitive", i just mean you argue that the currently used design fuels incompetence)

tl;dr We have a product, we want to make money, we need people to use the product. One of the things that stand in the way, is people not understanding how to use our product. We will make sure they can get started as fast as possible, and not mention how they may hurt themselves with the product, that would scare them away. Hurting yourself with our product is in the broad "don't do stupid things" category. We will never explain the "framework" (in case of an OS I mean apps, that apps can interact with each other and your data, how you can or cannot, control that), even in broad terms. Just click this button and get your solution.

It started with PCs and people not understanding how to not lose their documents. Now that every device is connected to the internet, the problem became worse.

You can now say that "sideloading" is stupid anyway, but this is not the only problem. Another thing that people still usually learn by painful experience is backups. There are fake apps, on both stores. Another thing, in-band signaling. You cannot trust email, phones, whatsapp, messenger... Even if your friend you often chat with is messaging you, they could've just been hacked. Try to explain that you also cannot trust websites and that even technical people don't have a good way of telling if an email of a website is real.

But at least enrollment is fast and adoption metrics are growing. Since we are already in "move fast and break things" mindset, we will think about fixing such issues when it actually becomes a problem.

To be clear, I'm not saying that making technology easy is always bad, that you should always expose the user to "the elements" and expect them pipe commands in the shell. But I think that often the focus is on only making enrollment fast. "Get started"

What if we actually expected people to understand something about technologies they want to use?

but that's what we have now, and it's not working.

the implied question is: what if we don't allow people to use technology unless they can demonstrate that they understand it?

is that really something we want to do? this sounds like gatekeeping, elitism, and anti-innovation because if if less people are going to use a technology, then there is less motivation to build it.

remember, i think it was someone at IBM that said that the potential for computers is some small number? and then it grew beyond anyone's wildest expectations?

do you think that would have happened if we had required understanding before we let anyone buy a home computer?

besides education, i don't know how to approach this issue.

My entire point is that education is the opposite of what we have now. That users are not expected to understand or know anything about IT technologies they use. Not the case with cars, recreational and prescription drugs...

> the implied question is: what if we don't allow people to use technology unless they can demonstrate that they understand it?

It's not exactly my point, but in extreme cases, maybe. I genuinely think that nobody has even tried to educate people about computers. Like, have you seen IT classes in schools? Assuming you are lucky enough for the classes to have any content, you will probably get some lessons in Word and Excel. Maybe some programming. Maybe Paint. But actually using the computer? Dangers of the internet, importance of backups, trusting websites, applications and emails? The concept of application and difference between applications and websites? And those technologies are not "developing" like they were 20 years ago, they are probably here to stay.

> is that really something we want to do? this sounds like gatekeeping, elitism, and anti-innovation because if if less people are going to use a technology, then there is less motivation to build it.

And the alternative Google and Apple present is giving them paternalizing control over the most popular computing device. The say over what people can do with their devices. After they made sure that these devices are embedded into our lives. I would much rather we slowed down with innovation for a second and resolved such issues first, because the way I see it, it's literally manipulation (also see: dark patterns).

As for the gatekeeping and etilism - Assuming we want a "computing license" (not necessarily what I'm arguing for), is "driving license" also gatekeeping and etilism? Or maybe some amount of gatekeeping is good?

As for anti-innovation - I genuinely think we might have had just enough innovation in the field and it may be time to slow down a little, take a step back and evaluate the results. And I honestly don't see much innovation in apps/computers/web space besides maybe AI, and governments are already working on regulating that.

> do you think that would have happened if we had required understanding before we let anyone buy a home computer?

Home computers were very harmless before the internet, but that's an aside. Assuming the tech is actually useful, not just slightly more convenient than "traditional" alternatives, then yes, I'm sure it would have still grown to sizes it has grown to today. Maybe a bit slower.

> besides education, i don't know how to approach this issue.

Same, I generally do think this whole situation needs more consideration.

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.

I grew up and live in Europe. I support the general idea of "regulation to make everyone safer" being an acceptable choice. At the same time, I vehemently oppose third-party interests reaching into my computing device and dictating what I can vs. cannot do with it.

But as you say, "global platforms with global impact and reach" - and so I can't set up my phone to conditionally read out text and voice messages aloud, because somewhere on the other side of the world, someone might get scammed into installing malware, therefore let's lock everything down and add remote attestation on top.

Unfortunately, the problem is political, not technological, and this here is but one facet of it. Ultimately, what SaaS does is give away all leverage: as users, it doesn't matter if we fully own the endpoints, or have a user-friendly vendor: any SaaS can ultimately decide not to serve a client that doesn't give the service a user-proof beachhead.

And it's also not actual regulation, just new TOS from a company many are basically forced to interact with.

I've heard much criticism of it being too heavy-handed, but I don't think I understand criticism that it won't improve security. Could you expand on that?

I actually totally agree! There is no external entity users can rely on to make sure apps they download are legitimate. I read the thread from root to this comment and I don't see it mentioned, so I'm not sure if you know this and are just arguing something else but...

There is actually nothing about testing or verifying apps themselves in the announcement made by Google. It's just about enforcing developer verification in some Google service and "registering the apps".

https://support.google.com/android-developer-console/answer/... https://android-developers.googleblog.com/2025/11/android-de...

EDIT: I checked your profile, and I now see that you actually work at Google, on Android... Is there something I misunderstood about these announcements?

> you could argue it's a false sense of security, but it's still more security

Well here I don't agree, I would much rather be aware of the dangers than think I'm safe when I'm actually not.

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.

For securities, if I own stock outright, the company has to indemnify if they do a transfer for somebody else or if I lack legal capacity. So transfer agents require Medallion Signature Guarantees from a bank or broker. MSGs thereby require a lengthy banking relationship and probably showing up in person.

For broker to broker transfers, there is ACATS. The receiving broker is in fact liable in a strict, no-fault way.

As far as I know, these liabilities are never waived. Basically for the sizable transfers, there is relatively little faith in the user’s computers (including phones). To the extent there is faith, it has total liability on some capitalized party for fraud.

These defaults are probably unknown for most people, even those with large amounts of securities. The system is expected to work since it has been set up this way.

Clearly a large number of programmers have a bent to go the complete opposite direction from MSGs, where everything is private keys or caveat emptor no matter the technical sophistication of the customer. I, well, disagree with that sentiment. The regime where it’s possible for no capitalized entity to be liable for wrongful transfers (defined as when the customer believes they are transferring to a different human-readable payee than actually receiving funds) should not be the default.

But that is expensive, so my impression is that for non-sizeable transfers, and beyond banking, for basically anything dealing with lots of regular people doing regular-people-sized operations, the default in the industry is to try and outsource as much liability onto end-users. So instead of treating user's computers as untrusted and make system secure on the back end, the trend is to treat them as trusted, and then deal with increased risk by a) legal means that make end-users liable in practice (keeping users uninformed about their rights helps), and b) technical means that make end-user devices less untrusted.

b) is how we end up with developer registries and remote attestation. And the sad thing is, it scales well - if device and OS vendors cooperate (like they do today), they can enable "endpoint security" for everyone who seeks to externalize liability.

Perhaps programmers have a clear idea of what's given up when you do things your way.

I'm not sure you do.

This is more or less how people expect things to work today ....

The money mule themselves is almost certainly insolvent to pay the damages. Currencies can also change by the money mule (either to a different fiat currency or crypto), putting the ultimate link completely out of reach of the originating country.

If intermediary banks are deputized and become liable in a no-fault sense, then legitimate transfers out become very difficult. How does a bank prove a negative for where the funds come from? De-banking has already been a problem for a process-based AML regime.

Are banks POWERFUL? Do they have lots of money and/or connections to those who do? Do they have a vested interest in getting transactions right?

Absolutely!

Now, with all that money and power -- they -- whoever THEY are, need to come up with smart ways to verify transactions that don't involve me giving them all the keys to all my devices.

We have protections like this elsewhere - even when they have some "ownership." The bank kinda owns my house, but they still can't come in whenever they want.

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

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

Then make sideloading disabled by default but enable it when the users tap 7 times on whatever settings item. At that time, explain those "negative consequences" to them, explain them real good, don't spare anything and if they still hit "Yes, continue to enable sideloading" you do that immediately in order to avoid increasing their haplessness with other made-up excuses.

Simple.

That is where we differ. It is, ultimately, the victim of a scam who makes the choice of "yes, this person is trustworthy and I will do what they say". The only way to prevent that is to block the user from having the power to make that decision, which is to say protecting them from themselves.

Google isn't approving apps though. A developer provides identity verification and a set of apps (apk names & keys) they are responsible for. There is no verification process or approval from google. The entire process as outlined in https://developer.android.com/developer-verification is that you prove you own signing keys for an apk name.

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?

Education isn't really working at this global scale. It doesn't reach people the way you seem to belive it does. Many, if not most people are generally disinterested in learning new things and this gets amplified when it involves technology.

Simple example: I have a foss VPN app running on my phone to avoid censorship and surveillance in some countries I visit. While using this app is no problem, non-anonymous development might carry consequences to the developer in some dictatorship jurisdictions (which are plenty of). I'm not sure all devs of such system would be willing to give their ids.

Another example is that this way US can cut out countries and people they don't like from mobile usage (which basically equals to modern social life). Look into sanctioned judges of international court because US protects war criminals.

Play store can be fast and verification based and the F/OSS stores can be slower, reputation and review based.

...

But fundamentally the easiest thing is to ask people to pay to unlock the phone's security barriers, this makes it harder and costlier for scammers.

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.

If they make FOSS illegal, guess I’ll be a criminal. Come and take it.

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

This is harm to others and is very obviously something we should enforce. There are unreasonable laws about food (banning the sale of raw milk cheese for example, which most of the world enjoys with perfect safety), but by and large they are unobjectionable.

> You're right that things can't be made more safe without taking away the freedom to harm people. Which is why even the most freedom-loving countries on earth strike a balance.

I never said I was opposed to striking a balance. Of course we can strike a balance. Indeed we already have when it comes to installing apps on Android. But these measures are being advanced as if safety were the only consideration, which it isn't.

> You're taking the most extreme libertarian stance possible.

No, that is what you have projected onto me. That's not actually what my stance is.

> Life is not safe, nor can it be made safe without taking away freedom. That is a fundamental truth of the world... 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.

That sounds pretty black and white extreme to me, when you talk about things like "life is not safe" and a "fundamental truth". I don't see any appreciation of balance there.

Maybe it's not what you meant to write, but your comment continues to absolutely come across as extremist and anti-balance to me. It seems like I was mischaracterizing what you actually believe (now that you've elaborated), but I don't think I mischaracterized what you wrote.

Then we will see how you will react.

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.

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

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

"Existing measures are working," perhaps?

What is this evidence? Please share it.

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

Also, the Play Store itself regularly contains malware.

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

In other news, a new study shows that cutting off your feet is 100% effective against athlete's foot.

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?

The exceptions for students/hobbyist were always promised, but the "advanced flow" came later based on this feedback. AFAICT Google has, so far, only made things better after the initial announcement. I don't see why we shouldn't give them the benefit of doubt, at least until we have some specifics.

Pushing this open letter out just days/weeks before Google promised the next major update just seems off.

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.

This trick only works if the general public is aware of what the app developer label does, what it is used for, what it protects against, and what it's supposed to say. However, if that's the case, you already have all the info you need to deduce that you shouldn't be installing APKs sent by a guy over the phone anyway.

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.

People are already effectively faking addresses for something as stupid as Amazon reviews. Apparently it's that cheap to fake an address, because those crapware spam stores that rotate their name/products/listings aren't exactly the size of the mob.

What this will probably do is raise the bar for scams a little so that dumb "mom-and-pop" criminals can no longer get started with a guide and a software kit they buy on Telegram, clearing the field for "professionals" while at the same time making identity fraud, address fraud, and (money) mules more lucrative.

All of that to shift away the blame from banks, public institutions, education, and to some extent people's personal financial responsibilities.

It's not really clear that this is money that needs to be laundered, it's often irreversible transfers that are legit.

> People are already effectively faking addresses for something as stupid as Amazon reviews. Apparently it's that cheap to fake an address, because those crapware spam stores that rotate their name/products/listings aren't exactly the size of the mob.

I already responded to this below. Those don't involve scammer controlled addresses. If I send you a piece of physical mail with an OTP code, you can't use a random faked address.

> clearing the field for "professionals" while at the same time making identity fraud, address fraud, and (money) mules more lucrative.

The majority of this kind of fraud is already organized. That's why raising the cost is impactful, see my comments below. It's a tool to raise the cost of revenues to an ideally unsustainable amount.

How? You've now moved the level of sophistication required from "someone runs some bots on the facebook website" to "someone is now committing complex fraud against a government".

If the only people who can run scams are state sponsored, that's still vastly better than the status quo.

> Amazon has a huge problem with packages being sent to fake people at different addresses.

This usually involves those people getting weird packages and not doing anything with them, it doesn't require attacker-controlled addresses.

This could work, but the issue here is that a lot of these scams rely on the "zero cost"-ness of turnup and use that as a asymmetry. If it costs you nothing to turn up new scam-accounts, and it costs me something to investigate and remove them, you win. If it costs you $10 to create new scam accounts then as long as I can get the EV of a scam account below $10, the scam isn't worthwhile.

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.

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.

A root cause solution is proper sandboxing. Google and apple will not do this, because they rely on applications have far too much access to make their money.

One of the fundamentals of security is that applications should use the minimum data and access they need to operate. Apple and Google break this with every piece of software they make. The disease is spreading from the inside out. Putting a shitty lotion on top won't fix this.

Oh they do this quite well. Thing is, these sandboxes are meant to protect apps from you, not the other way around. That's why some apps - not just platform vendor apps but also select third-party apps - get special access and elevated privileges, while you can't even see what data they store in `/storage/emulated/0/android/data` even with ADB trickery.

This has been going on for years, Google knows about it, and intentionally leaves it unfixed.

> Out of 47 Indian apps I randomly analyzed, 31 of them used the "ACTION_MAIN" filter - giving them access to see all the apps on your phone without any disclosure. That's 2 out of 3 apps.

Of course there's hundreds of other variants of malware, this is just one of the most prevalent.

That is not true, as those apps declare that they collect app activity data in their Play Store page though.

Let me know when you can provide a single specific name.

First Google search https://www.malwarebytes.com/blog/news/2025/08/77-malicious-...

Here's 77 found by researchers and then removed. Relying on researchers to find malware isn't a very good bet.

If I were a betting man, I would say there are thousands of apps on the play store that you can classify as malware.

We will never know the true number because one of the primary goals of malware is to be as difficult to detect as possible. They're not going to declare they're malware, duh.

If you know of some algorithm to detect malware, I'd love to hear it. Evidently even trillion dollar companies cannot come up with one. To this day, the best way to detect malware is source code analysis and thorough behavior testing.

Google and Apple do neither. Those are just the facts. Do with that what you will, I don't care.

>The core payload has been updated to incorporate a new keylogger variant of Anatsa. Additionally, the malware utilizes a well-known Android APK ZIP obfuscator for enhanced evasion. The DEX payload is concealed within a JSON file, which is dynamically dropped at runtime and promptly deleted after being loaded.

I wonder if there is anything that Google can do to prevent this specific attack. :)

What a quote. My word.

It's a big repository, it's a lot of code, and Google has read approximately 0% of it. Fucking obviously there's malware, it's not rocket science.

My biggest mistake is humoring people who either play stupid or are so stupid that they can barely function. Why do I do this? Is this a form of masochism? Is there a medicine for this? And, if so, is it in-network?

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 sideloading warning is much much milder, something like "are you sure you want to install this?".

A fundamental difference with e.g. FIDO2 (especially hardware-backed) is that the private credentials are keyed to the relying party ID, so it's not possible for a phising site to intercept the challenge-response.

> Please enter the code we sent you in the app.

lol, lmao even

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.

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.

They are saying that claiming the underlying problem is not real or not big enough to need addressing is an ineffective way to argue.

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?

Are we saying that, because scamming exists and we haven’t proposed an alternative, it means that clamping down on software installation methods is a legitimate solution to the problem?

Also every user is free to simply not use the option of installing things outside of the store.

Do you know anyone who works in a professional creative field that doesn't involve writing code? If so, ask them how they'd feel about their work bring out there on the internet free to all takers. What the implications would be for their ability to feed their children and pay their mortgage doing the things they love.

This is what I mean by "programmer-brained." Of all creative workers, only programmers seem okay with abolishing IP laws, I guess because they figure they'll be okay living out of an office at MIT, or even worse out of an office at some YC startup that turns the user into the product. But artists, musicians, writers, filmmakers, etc. all put food on the table because of those IP laws programmers hate so much. Taking that protection for the fruit of your labor away would be at least as disruptive as AI has been.

No, no, a thousand times no. This is an argument for authoritarian clampdown on general computing and must be opposed by all means necessary. I have the right to run whatever code I wish on my own damn property without the permission of arbitrary authorities or whatever subset of society you favor, and if you or they have a problem with this, you or they can proceed to pound sand.

It’s a good time to buy a pallet of old SFF computers, just in case.

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.

This is also true if they can only install verified apps, because no company on earth has the resources to have an actually functional verification process and stuff gets through every day.

This is true, but if this goes through, I imagine that the next step for safety fascists will be to require developer licensing and insurance like general contractors have. And after that, expensive audits, etc, until independent developers are shut out completely.

Why do drug companies deserve justice for developing and pushing heroin-analogues, but not tech companies?

Our work has real consequences.

The stakes aren't any lower for us.

If I write a trash library for a random project and someone else starts using it to run their nuke plant, that isn’t my fault. Read the license. NO WARRANTY.

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.

A simple scenario adapted from the one given in the android blog post: the attacker calls the victim and convinces them that their banking account is compromised, and they need to act now to secure it. The scammer tells the victim, that their account got compromised because they're using and outdated version of the banking app that's no longer suppported. He then walks them through "updating" their app, effectively going through the "new device" workflow - except the new device is the same as the old one, just with the backdoored app.

You can prevent this with attestation of course, essentially giving the bank's backend the ability to verify that the credentials are actually tied to their app, and not some backdoored version. But now you have a "blessed" key that's in the hands of Google or Apple or whomever, and everyone who wants to run other operating systems or even just patched versions of official apps is out of luck.

This is where the scheme breaks down: the new passkey credential can never be associated with the legitimate RP. The attacker will not be able to use the credential to sign in to the legitimate app/site and steal money.

The attacker controls the fake/backdoored app, but they do not control the signing key which is ultimately used to associate app <-> domain <-> passkey, and they do not control the system credentials service which checks this association. You don't even need attestation to prevent this scenario.

You're assuming the attacker must go through the credential manager and the backing hardware, but that is only the case with attestation. Without it, the attacker can simply generate their own passkey in software, because the backend on the banks side would have no way of telling where the passkey came from.

That doesn't work, because the scammer's app will be signed with a different key, so the relying party ID is different and the secure element (or whatever hardware backing you use), refuses to do the challenge-response.

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.

No need for locking down the app ecosystem, no need to verify developers. Just don't use phishable credentials and you are not vulnerable to malware trying to phish credentials.

0: https://www.bankofamerica.com/.well-known/assetlinks.json

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.

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.

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

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)

the point of my comment was that the state does implement a lot of rules (read: "is a nanny"), despite the claim otherwise.

What?

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.

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.

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.

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.

So maybe before talking about anything about direct installs, they could fix the big scams on the Play Store.

Permissions are a great way to distinguish.

Or would you be OK knowing that Thunderbird you downloaded from https://thunderbird.net/ is signed by the thunderbird.net certificate owner?

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.

It's therefore on their choice of search engine, or choice of app store, to lead them from "thunderbird" to "The app downloadable from https://thunderbird.net/", which can then be validated as signed by the verified owner of the same domain.

I'm not proposing changing the permissions system.