I am generally in favor of security improvements, but I do not really see much of a benefit here. This attack vector requires both that the user enabled developer settings and that they have remote adb enabled. So, this does not seem to be a realistic attack vector for 99.9% of the users and most of the other 0.1% probably know what they are doing.
The other proposed change (to restrict access to certain interfaces or IP addresses) seems good, but why not allow developers to restrict access localhost?
It reeks of trying to block Shizuku, Canta, etc. using a way that only makes it look like a side-effect.
Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?
> Spamming the thread will only cause Google developers to lock the issue, ignore valuable community feedback, or stop sharing public updates about this change entirely.
So nothing would change (they can also lock away your "valuable community feedback" because what bothers them is the criticism itself), thus feel free to express your approval
The implication in the blog post that Google developers somehow “overlooked” or “misunderstood” important use cases here, and if only they were informed about them they would reconsider, is frankly insulting.
Of course this was bound to happen, next you're telling me people will be surprised that the 24 hour limit for side loading will turn into some indefinite time period.
It can and will most probably turn to indefinite time depending on the answer to the question "will we have a viable alternative to jump ship before that happens ?".
We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.
Many alternative AOSP-based systems work fine today and do not have the new Android Developer Verifier (wow, already rolled out to 500M+ devices [1], though still dormant).
To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick your phone, etc.
Wait till you hear that your OEM can remotely rollout full OS updates with full access to all your data and drivers... carrying Google software and most of it Google code.
It's almost like the Davos-and-other-secret-club attending Epstein-class insane sociopaths have a plan for the direction of our economy. Insane people who think they are royalty are steering 8 billion people. They don't have crowns, or righteousness, or even outstanding intellects. They just have money.
Elon musk likes to say he's good at games. I could demolish him at every game he ever claimed to be good at. I would also beat him in boxing or MMA. The guy is a loser obsessed with status. I prefer to just be good at things and enjoy friendly competition. Elon musk couldn't beat me at a single thing other than impregnating women with kids he didn't know how to raise.
I am worried that this might happen to websites soon.
If you want your website to be openable on Apple devices, you would have to pay Apple a fee each month. If you want your website to be openable on Android devices, you would have to pay Google a fee ecah month, etc.
We need Linux on phones. Bank apps not needed as long as I can use browser. But do need some things like wireless cards, popular apps like Sonos and Spotify working.
This assumes user is the only person with physical access to unlocked phone.
All sorts of goverment agencies, airport security, even teachers now have access. And such attacks can be trivially automated, so even low paid worker can do it.
Step back to the other issue (referenced in the page*), that Google would pushing on devices something that blocks applications that do not come from play.google.com . Was it not established that Google can only push that update on devices with a google account?
This is about control, not security. As in, Google's control over your device, your experience, your features and choices. This and Google just isn't interested in supporting an open OS anymore. Maybe they think it makes them liable.
Either way the writing is on the wall, and has been for a while.
Sometimes it's truly useful featutes, but having no toggle in settings making it terrible.
Like iPhone idle auto-reboot every 3 days. After a while they added "Allow Idle Reboot" flag but it only accessible via MDM and require device wipe and for switching it to be a managed device.
They dont care about security; only about control.
There are hundreds of millions of outdated Android devices that all Google attestation systems consider secure even though they all running Linux kernel that was never ever updated and can be rooted by anything.
Now try to install your own firmware on them without said outdated kernel... How dare you.
It's not even "max security". We are talking about those big tech corps which are infamous for sharing all of your private information with the government, and analyzing it so as to manipulate you in to buying things, and possibly for other obscure commercial purpuses.
No one's requested the config switch from A to B with a restriction that's acceptable to those seeking B. Idealism doesn't tend to offer compromises, and so Idealism tends to lose when it doesn't make a convincing case to regulators. Here's a simple and easy to implement example compromise that could be offered today:
"Changing between A and B requires a device reset."
Most people are going to flat out refuse to wipe their device for a phisher, especially since it'll log them out of everything and trigger all sorts of "new device on your account" warnings everywhere if it's done without their knowledge.
Sure, this is mildly annoying for the 1% that have good reason for A — but it's annoying once per device rather than losing A for good as is happening now. Sure, Google will deny service to A. They're doing that no matter what, either b/c they remove A or b/c they deny A, but this forces them to construct and defend a case for why users who went through the hassle of wiping their device to switch to A ought to be denied access to the app store, and that's a critically absent case in regulatory circles right now. (See also Graphene vs. the EU age check app.)
That's all it would take to protect B from A, but no one asks for it, and no one presses Google publicly for it, and so of course Google isn't doing it. No megacorp will help you walk off the Golden Path without some sort of extrinsic pressure. I see a great deal of clamor around wanting A, but absolutely none of the 'here's a mild annoyance that we came up with as a valid and safe compromise' clamor that would make them look incompetent in the public eye, provide further leverage for EU antitrust steps regarding Android itself, and give them a way to continue to protect users who need B for safety, while allowing those of us who want A to pursue it.
Perhaps other styles of compromise exist, too? As far as I can determine, no one else is thinking about this in terms of "what compromises will developers offer that continue to protect non-developers?", and so I have no other examples to offer. I'd sure love to see more ideas, more effort invested into offering serious and real compromises rather than inflexible resistance of every real safety improvement.
adb connecting a device to itself is just bad design and a hack. Either the capabilities should just be granted directly to the app or it should all be blocked.
Same can be said about loopback device in general. Why do you need to use networking when you are literally on the same device and can use binder/dbus and friends with native apps?
Shizuku uses Binder AFAICS[^1]. Looking deeper it seems that Shizuku does not connect to the device itself per se, but rather it has a privileged server launched manually through adb. Never used Shizuku, so can't say for sure.
That seems rather unlikely given the the ways of the fruit factory. They don't stand to gain anything from loosening their stranglehold on their flock while they could lose substantially if someone were to open the gate and let the sheep escape. Nope, keeping them penned in is the best way to reliably fleece them.
I am generally in favor of security improvements, but I do not really see much of a benefit here. This attack vector requires both that the user enabled developer settings and that they have remote adb enabled. So, this does not seem to be a realistic attack vector for 99.9% of the users and most of the other 0.1% probably know what they are doing.
The other proposed change (to restrict access to certain interfaces or IP addresses) seems good, but why not allow developers to restrict access localhost?
It reeks of trying to block Shizuku, Canta, etc. using a way that only makes it look like a side-effect.
Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?
The bug literally describes how they're avoiding OS security restictions by going through the debug port.
This is a CVE by any definition and you'd be screaming your head off if any other OS would allow this kind of permission bypass.
But sure, Google evil.
> Spamming the thread will only cause Google developers to lock the issue, ignore valuable community feedback, or stop sharing public updates about this change entirely.
So nothing would change (they can also lock away your "valuable community feedback" because what bothers them is the criticism itself), thus feel free to express your approval
The implication in the blog post that Google developers somehow “overlooked” or “misunderstood” important use cases here, and if only they were informed about them they would reconsider, is frankly insulting.
Of course this was bound to happen, next you're telling me people will be surprised that the 24 hour limit for side loading will turn into some indefinite time period.
It can and will most probably turn to indefinite time depending on the answer to the question "will we have a viable alternative to jump ship before that happens ?".
We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.
Many alternative AOSP-based systems work fine today and do not have the new Android Developer Verifier (wow, already rolled out to 500M+ devices [1], though still dormant).
To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick your phone, etc.
[1] https://play.google.com/store/apps/details?id=com.google.and...
Wait till you hear that your OEM can remotely rollout full OS updates with full access to all your data and drivers... carrying Google software and most of it Google code.
It's almost like the Davos-and-other-secret-club attending Epstein-class insane sociopaths have a plan for the direction of our economy. Insane people who think they are royalty are steering 8 billion people. They don't have crowns, or righteousness, or even outstanding intellects. They just have money.
Elon musk likes to say he's good at games. I could demolish him at every game he ever claimed to be good at. I would also beat him in boxing or MMA. The guy is a loser obsessed with status. I prefer to just be good at things and enjoy friendly competition. Elon musk couldn't beat me at a single thing other than impregnating women with kids he didn't know how to raise.
I am worried that this might happen to websites soon.
If you want your website to be openable on Apple devices, you would have to pay Apple a fee each month. If you want your website to be openable on Android devices, you would have to pay Google a fee ecah month, etc.
finally my children will be secure and my bank account impenetrable!
/s
We need Linux on phones. Bank apps not needed as long as I can use browser. But do need some things like wireless cards, popular apps like Sonos and Spotify working.
https://archive.ph/gla4i
In case it is made private.
This assumes user is the only person with physical access to unlocked phone.
All sorts of goverment agencies, airport security, even teachers now have access. And such attacks can be trivially automated, so even low paid worker can do it.
This is solvable by adding big huge warning that ADB is running. Not by removing feature.
Just use opensource phone os!
Step back to the other issue (referenced in the page*), that Google would pushing on devices something that blocks applications that do not come from play.google.com . Was it not established that Google can only push that update on devices with a google account?
* https://keepandroidopen.org/
goodbye shizuku i guess, and maybe termux
This is about control, not security. As in, Google's control over your device, your experience, your features and choices. This and Google just isn't interested in supporting an open OS anymore. Maybe they think it makes them liable.
Either way the writing is on the wall, and has been for a while.
What I find most annoying aspect of all software from 2010s onwards is this stupid discourse and associated results:
- some people want A, or A might even be already in use
- A is problematic for $MODERATE_OR_MILD_REASON
- B is introduced and made default
- a config switch between A and B is never considered
So, so tiring. If I want to bind ADB to localhost, _let me_. It's my device and my problem, ffs.
Toxic max security.
Not everyone has the same threat model as you, $BIGTECHCORP.
Isn't security just an excuse to push user hostile features?
Like, if security was a concern we would have simpler systems and still use 2fa devices for banks etc.
Sometimes it's truly useful featutes, but having no toggle in settings making it terrible.
Like iPhone idle auto-reboot every 3 days. After a while they added "Allow Idle Reboot" flag but it only accessible via MDM and require device wipe and for switching it to be a managed device.
They dont care about security; only about control.
There are hundreds of millions of outdated Android devices that all Google attestation systems consider secure even though they all running Linux kernel that was never ever updated and can be rooted by anything.
Now try to install your own firmware on them without said outdated kernel... How dare you.
It's not even "max security". We are talking about those big tech corps which are infamous for sharing all of your private information with the government, and analyzing it so as to manipulate you in to buying things, and possibly for other obscure commercial purpuses.
Ask Jeeves toolbar disagrees.
No one's requested the config switch from A to B with a restriction that's acceptable to those seeking B. Idealism doesn't tend to offer compromises, and so Idealism tends to lose when it doesn't make a convincing case to regulators. Here's a simple and easy to implement example compromise that could be offered today:
"Changing between A and B requires a device reset."
Most people are going to flat out refuse to wipe their device for a phisher, especially since it'll log them out of everything and trigger all sorts of "new device on your account" warnings everywhere if it's done without their knowledge.
Sure, this is mildly annoying for the 1% that have good reason for A — but it's annoying once per device rather than losing A for good as is happening now. Sure, Google will deny service to A. They're doing that no matter what, either b/c they remove A or b/c they deny A, but this forces them to construct and defend a case for why users who went through the hassle of wiping their device to switch to A ought to be denied access to the app store, and that's a critically absent case in regulatory circles right now. (See also Graphene vs. the EU age check app.)
That's all it would take to protect B from A, but no one asks for it, and no one presses Google publicly for it, and so of course Google isn't doing it. No megacorp will help you walk off the Golden Path without some sort of extrinsic pressure. I see a great deal of clamor around wanting A, but absolutely none of the 'here's a mild annoyance that we came up with as a valid and safe compromise' clamor that would make them look incompetent in the public eye, provide further leverage for EU antitrust steps regarding Android itself, and give them a way to continue to protect users who need B for safety, while allowing those of us who want A to pursue it.
Perhaps other styles of compromise exist, too? As far as I can determine, no one else is thinking about this in terms of "what compromises will developers offer that continue to protect non-developers?", and so I have no other examples to offer. I'd sure love to see more ideas, more effort invested into offering serious and real compromises rather than inflexible resistance of every real safety improvement.
Google doesn't want you to be able to skip YouTube ads. It's as simple as that.
>a config switch between A and B is never considered
And why should modern corpo maintain additional complexity to pander to 1% of privacy-aware tech-savvy users?
adb connecting a device to itself is just bad design and a hack. Either the capabilities should just be granted directly to the app or it should all be blocked.
Same can be said about loopback device in general. Why do you need to use networking when you are literally on the same device and can use binder/dbus and friends with native apps?
Shizuku uses Binder AFAICS[^1]. Looking deeper it seems that Shizuku does not connect to the device itself per se, but rather it has a privileged server launched manually through adb. Never used Shizuku, so can't say for sure.
[1]: https://github.com/rikkaapps/shizuku#how-does-shizuku-work
bullish on google stock
revenue must go up
RIP phones
that seems pretty reasonable actually
To only use ADB through a WLAN? No, it is not that reasonable
or over USB, from another device? this is about maybe restricting the wireless variant to only work on wlan0
To iPhone users, perhaps.
I'm afraid in a few years iOS will actually (not as a joke) be the more open and customizable option
That seems rather unlikely given the the ways of the fruit factory. They don't stand to gain anything from loosening their stranglehold on their flock while they could lose substantially if someone were to open the gate and let the sheep escape. Nope, keeping them penned in is the best way to reliably fleece them.
i'm running graphene