It's not just the status quo, it's a nightmare to enable. Somehow between Google Play Advanced Protection and Google Account Advanced Protection I have to resort to several reboots and adb + USB debugging sideload to get an app loaded. @.@
The point is "a warning" is not enough to communicate to people the gravity of what they are doing.
It is not enough to write "be careful" on a bag you get from a pharmacy... certain medications require you to both have a prescription, and also to have a conversation with a pharmacist because of how dangerous the decisions the consumer makes can be.
Normal human beings can be very dumb. It's entirely reasonable to expect society to try to protect them at some level.
OK so make the warning more annoying. Have a security quiz. Cooldown period of one day to enable. Require unlock via adb connected to laptop.
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.
- 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!)
I do? It's a trivially comparable thing? I'm not even talking about ALL prescription drugs. I'm talking about the fact that some have interactions that can kill you. Having "life savings gone" consequences from a random app install is that level of danger.
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.
I have a hard time with this because it's the world we've lived in forever. Everyone knows installing an "app" installs an executable.
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?
this. just like how when you start playing a hard esoteric game like an RTS or MOBA, they ask you what your degree of comfort/experience with the genre is to avoid making a pro player go through the tutorial and vice versa.
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.
You can add 5 layers of "are you sure you want to do this unsafe thing" and it just adds 5 easy steps to the scam where they say "agree to the annoying popup"
You could even make this an installation-time option. If you want to enable the switch afterwards, you have to do a factory reset. Then, the attackers convincing the victims would get nothing.
Or make sideloading available only after 24 hours since enabling it. I would enable it on my new devices and wait 24 hours before installing F-Droid and other apps. Not a problem. Scammers might wait one day too but it decreases the chances of success because friends and family members can interfere.
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.)
> 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.
In the case of most of those business it's only because they must mark checkboxes on a regulation compliance sheet and/or deflect blame on someone else. The problem is that this is a never ending spiral of regulation after regulation and new ways to deflect blame so after device attestation will fail to solve all of their problems they'll end up pushing something else.
That's... brilliant. Enough work to not be able to talk it though over the phone to someone not technical. A sane default for people who don't know about security. And a simple enough procedure for the technically minded and brave.
It solves the 'smartest bear / dumbest human' overlap design concern in this situation.
They are already buying a locked down phone most of the time. And they already want this! (Unfortunately the bootloaders are locked, as far as I know.)
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.
