Comment by luke-stanley
1 day ago
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.
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.
`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.
> 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.
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.
1 reply →