Remix.run Logo
kube-system 2 days ago

> Starting September 2026, a silent update, nonconsensually pushed by Google, will block every Android app whose developer hasn't registered with Google, signed their contract, paid up, and handed over government ID.

This is false. Google will provide two other flows for app distribution that are different than this.

> Every app and every device, worldwide, with no opt-out.

Again, false. There is an opt-out called the "advanced flow".

https://android-developers.googleblog.com/2026/03/android-de...

luke-stanley 2 days ago | parent | next [-]

But the "opt-out" will not prevent ecosystem effects caused by the default shutdown of convenient app installs due to the policy. Not even for GrapheneOS users. It's a global policy by a body we never voted for. You can't opt-out of that different world by waiting 24-hours, the ecosystem could have permanent effects. This is coming from a company that doesn't even bother to expose a permission to disable Internet access per app. It's there underneath, but they just ... don't expose the choice.

kube-system 2 days ago | parent [-]

Is it really going to have ecosystem effects? Surely the small portion of power-users who are bothering to intentionally sideload apps can click a couple of buttons. Or just load via ADB and avoid the entire thing.

The entire point here is to prevent scam actors from using a false sense of urgency to defraud people. That is a serious vulnerability that needs to be addressed somehow, and I think this is a good compromise that doesn't impact people's ability to sideload.

I say this as someone who sideloads apps literally every day.

luke-stanley 17 hours ago | parent | next [-]

`Is it really going to have ecosystem effects?`

Will mandatory ID gatekeeping of developers have ecosystem effects? Surely the only question is how much? You may install apps over ADB every day, but APK installing is much more convenient and open-source F-Droid developers currently don't have to do a thing to be "allowed" to ship APKs.

`The entire point here is to prevent scam actors from using a false sense of urgency to defraud people.` The proposed architecture is a general developer gate, it is not a proportionate response to the problem - it isn't even proposing to gate specific app permissions, it's being able to install the apps from APKs at all under a regime they administer, with users forced to have this change with no prior consent, only opt-out, and distribution limiting work-arounds (that harm reach).

If Android were to ask the user if they wanted to disable installing downloaded apps from developers who haven't shown Google IDs for their own safety, and let end users give informed consent about what self-protection behaviour level they want for their system, at the point of roll-out, or device setup, that would be quite different.

Why should Google be trusted to gate what apps can be easily shared, when stock Android won't even allow users to toggle Internet access per-app? It isn't proportionate compared to other permissions they could mediate, and worse, it's a centralised architecture vulnerable to authoritarian pressure, and afterwards they will be well positioned to lock it down more.

Zak 2 days ago | parent | prev [-]

> The entire point here is to prevent scam actors from using a false sense of urgency to defraud people. That is a serious vulnerability that needs to be addressed somehow

Does it, and if it does, does it need to be addressed by an OS vendor creating a mechanism to ban developers for most users? I'm not convinced of the former, and I'm certain the latter is bad. I predict within ten years, we will see this used against something that is not malware.

kube-system a day ago | parent [-]

What do you mean "ban developers for most users"? Most users get their apps through the play store, which will still exist here. Some users sideload apks, which is also a functionality that will still exist.

> we will see this used against something that is not malware.

See what exactly used against something that is not malware? The Play Store already has requirements other than "don't be malware". If you're talking about the sideloading requirements, all of these requirements apply to every app, not just malware.

Zak a day ago | parent [-]

Recently, both Apple and Google banned apps for reporting immigration raids in the USA from their respective stores. Android users can still trivially download such apps from other sources. After the verification requirement, nothing changes as long as the developer has a permission slip from Google. If they don't, users have a waiting period that could be a critical delay in an emergency like a crackdown by an oppressive government.

Google has stated that it will only withhold such permission from developers who distribute malware. I imagine they'll stick to that promise at first, but long-term I think they won't. Once it's possible for them to impose partial bans on developers, governments have every incentive to pressure them to do it.

varispeed a day ago | parent | prev | next [-]

People like you are the problem. Nitpicking and hand waving the bigger picture.

monooso 2 days ago | parent | prev [-]

You deliberately took the second quote out of context, in order to (attempt to) refute it. Here's the quote, with context:

> Starting September 2026, a silent update, nonconsensually pushed by Google, will block every Android app whose developer hasn't registered with Google, signed their contract, paid up, and handed over government ID. Every app and every device, worldwide, with no opt-out.

That is not false, it's completely accurate. You don't have to take my word for it, though, the Android developer docs have a helpful page detailing the plan [1].

As for the "advanced flow", the article discusses it in detail.

[1]: https://developer.android.com/developer-verification

kube-system 2 days ago | parent [-]

??? We literally quoted the exact same text.

The plan does not outline what that quote does. You only have to do all of the things the quote claims you do in one of the three possible deployment flows. In "advanced flow" you don't have to do any of them.

monooso a day ago | parent [-]

No, you quoted some of the text. Hence my statement that you removed the context. If you read the full quote, it's clearly stating that you cannot opt-out of the update.

kube-system a day ago | parent | next [-]

Please read it again. We quoted exactly the same thing, to the character.

Also, you can certainly opt to not install android updates, if that's your preferred reading here -- so that is also false.

catcowcostume a day ago | parent | prev [-]

He broke the quote in 2 ffs, can't you read?