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?
Hadn't thought about that additional attack vector those proxies are enabling. In addition to "internet access from residental connection" privileges, the attacker also gets access to loopback on the device that does the proxying...
But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?
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 (or even if another app did it).
> 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.
Or perhaps they wouldn't? CVEs aren't holy scripture, and "security" isn't the most important consideration in computing. This theatre has gone too far IMO.
Can you provide a reasonable definition where an authentication bypass in ADB doesn't qualify as a vulnerability? Is there a use case for allowing anyone on your network to run adb commands without your approval?
There are 3 things which I feel like are being confused here:
1. There was a genuine authentication bypass vulnerability in ADB (bad)
2. Initial proposed change wants to add an option to limit the ADB server to certain IPs or network interfaces (good - it doesn't affect you)
3. Response to the original request, proposing that ADB shouldn't be allowed to listen on loopback interfaces (bad/nefarious - it breaks functionality)
"An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so.
"A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too.
Whether it matters or is something that should be addressed, is the depends part. Here we're talking about CVE that's at risk of trying to address a feature.
You are forgetting the most important questions of security, without which the whole discussion becomes pointless:
Who is securing what, and from who?
CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.
Because you know, the actual solution would be to have more granularity in authentication process than "allow whole device to attach to ADB", but that would be like, difficult... so they're not going to so that.
Right now any app on my PC connected to ADB could manipulate my phone then, and that's somehow not a CVE?
The original issue is proposing letting the user assign the debug service to a specific interface, one of which would presumably be loopback. This article is about the proposal from a developer that it should only ever be assigned to wlan0, which would break a lot of apps.
Letting applications bypass permissions with this feature is the exact usecase they don't want to lose. If anything, I don't see them being against the original proposal possibly restricting non-loopback access, which would enhance security.
"...avoiding OS security restictions by going through the debug port..." the user delibretry opened and paired to app with clear visual confirmation in order to use 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 moment an article like this hits HN or Reddit or any other such forum, any hope of changing anyone's mind is lost. The same happens to Github issues too. I haven't checked the isue myself, but seeing it here means it's probably already too late at this point, it'll probably get flooded.
Google does take feedback from app developers every now and then, but obviously their own teams' feelings on the subject are more important to them than some open source developers relying on a hack like in this article.
I think it should be quite obvious that the ADB daemon wasn't designed to enable call recording from an app initiating an adb session over a loopback address. https://xkcd.com/1172/ strikes again.
That doesn't mean the developer who wrote this is wrong to dislike the change: Google themselves have added call recording to their dialer a while ago so it's clearly a feature they stand behind. That doesn't mean the adb team shouldn't do a little security hardening, though.
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.
Every single time any story has the words "Google developers" in it, they're behaving like arrogant, disconnected, anti-consumer jerks. From constant GCP breakage, to not acknowledging obvious Android bugs, to intentionally braking Chrome. It's a stark contrast to behind the scenes interactions with them.
Yeah, my favorite one is how Chrome users are not smart enough to handle case-aware web-page search toggle. Although to be fair their Chrome team is very arrogant even by Google standards.
You keep spamming variations of this comment without explaining how could apps actually bypass security without several steps that the user needs to take in order for it to work. Are you just farming down votes for some weird reason or will you finally get to the technical details instead of one-sentence snarks?
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.
and now people install Remote Access Trojans just to let GPT and Claude think and work for them, granting them shell and a11y access. really? after seeing that, nothing surprises me
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.
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.
You would have the "new web" consisting of the top n major websites paying this fee.
And then you would have the "old web", accessible only to people still owning their own PCs with unrestricted browsers. And probably heavily scrapped by AI companies to reguritate to the masses through the new web.
So you won't be able to use your banking apps, your local transport app, public services apps, health services apps, etc.
But sure, you can do SMS (no RCS though), use the device calculator, and maybe browse the Web… until websites kick you out because your non Chrome/Safari browser isn't supported anymore. Even Signal won't work well due to the lack of FCM.
And I'm a GrapheneOS user happy with Obtainium and without Play Services installed in main user space.
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.
Unfortunately many banks in the UK no longer offer a web portal or physical branches.
I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly.
(I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)
Android had a tradeoff - less vertical integration and more annoyances, a bit worse software quality, for a more open, customisable and utility-like experience. I loved that.
Now, the tradeoff is - less vertical integration, double the integration layer trash (Google & OEM) and a much more locked down experience. But the quality of it hasn't improved, it just got worse.
Doesn't make sense anymore. They can now do 99% of the same things, but iOS has a better quality OS, better apps and better vertical integration.
Not even vertical integration, actually just any kind. FFS it's 2026 and the recommended android way to send a photo to your mac/PC is "upload to google photos and hope it decides to sync".
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.
Does anyone have any doubt left that we're headed for a future where you need a government ID to use any computing device, and only allowed to do government-approved tasks and view government-approved content?
Not a rhetorical tinfoil question: Does anyone still believe there's some hope for personal freedoms?
It's frankly amazing how many Google developers will associate their real identities and contact info with such hostility, believing they're invincible.
Perhaps they should be subjected to the full force of the First Amendment.
I'm so done with Android and iOS. I already carry around 2 phones because neither will give me exactly what I want, maybe it's time for a 3rd running Linux..?
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?
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.
Right, that too. But that's a reason to recommend regular reboots[0], not to force them, and "3 days of inactivity" is a suspiciously specific time that I also saw mentioned in Android settings somewhere the other day.
--
[0] - Which I find deeply ironic, in that merely a decade ago, people would laugh at Windows with its "reboot after installs, reboot in case of problems" approach, and now frequent reboots are seen as Standard Security and Stability Practice on *nix systems, both mobile and server-bound...
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.
Technically the security works, just for their threat model. An exploit would need root and root means you likely cannot pass attestation AFAIK. The fact that this same exploiter can download all your contacts photos and texts is immaterial to, say, Disney, who want attestation only to prevent ripping of their content.
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.
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.
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.
The article overlooks security implications from spyware, which is a huge problem not only for financial applications, but personal safety, too [0].
Per FTC, a stalkerware will: geo locate, read call list & record calls, read notifications, texts, & possibly emails, access gallery, camera, & files, and monitor network activity. [1]
You could do all of those with "on-device adb" (in some cases, with just the appropriate permissions), without root access. Stalkerware & financial fraud enabled merely due to the scale & reach of Android (half of humanity uses it!) and lack of basic security literacy warrants such protective measures, as (Thaler & Sunstein would like to remind us) defaults matter.
With conspiracies abound, we must not lose sight of tech safety and related issues, which almost exclusively affect the most vulnerable & the most disadvantaged.
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.
But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?
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 (or even if another app did it).
But sure, Google evil.
Or perhaps they wouldn't? CVEs aren't holy scripture, and "security" isn't the most important consideration in computing. This theatre has gone too far IMO.
There are 3 things which I feel like are being confused here:
1. There was a genuine authentication bypass vulnerability in ADB (bad)
2. Initial proposed change wants to add an option to limit the ADB server to certain IPs or network interfaces (good - it doesn't affect you)
3. Response to the original request, proposing that ADB shouldn't be allowed to listen on loopback interfaces (bad/nefarious - it breaks functionality)
I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.
"An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so.
"A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too.
Whether it matters or is something that should be addressed, is the depends part. Here we're talking about CVE that's at risk of trying to address a feature.
You are forgetting the most important questions of security, without which the whole discussion becomes pointless:
Who is securing what, and from who?
CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.
This is one of them
Right now any app on my PC connected to ADB could manipulate my phone then, and that's somehow not a CVE?
Letting applications bypass permissions with this feature is the exact usecase they don't want to lose. If anything, I don't see them being against the original proposal possibly restricting non-loopback access, which would enhance security.
It's like saying that the fact the user knows their own password is a vulnerability because they might enter it to log into their account.
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
Google does take feedback from app developers every now and then, but obviously their own teams' feelings on the subject are more important to them than some open source developers relying on a hack like in this article.
I think it should be quite obvious that the ADB daemon wasn't designed to enable call recording from an app initiating an adb session over a loopback address. https://xkcd.com/1172/ strikes again.
That doesn't mean the developer who wrote this is wrong to dislike the change: Google themselves have added call recording to their dialer a while ago so it's clearly a feature they stand behind. That doesn't mean the adb team shouldn't do a little security hardening, though.
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.
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...
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.
You would have the "new web" consisting of the top n major websites paying this fee.
And then you would have the "old web", accessible only to people still owning their own PCs with unrestricted browsers. And probably heavily scrapped by AI companies to reguritate to the masses through the new web.
edit: I not realizing that I been replying to wrong comment
So you won't be able to use your banking apps, your local transport app, public services apps, health services apps, etc.
But sure, you can do SMS (no RCS though), use the device calculator, and maybe browse the Web… until websites kick you out because your non Chrome/Safari browser isn't supported anymore. Even Signal won't work well due to the lack of FCM.
And I'm a GrapheneOS user happy with Obtainium and without Play Services installed in main user space.
I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly.
(I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)
Same in Norway.
In case it is made private.
Now, the tradeoff is - less vertical integration, double the integration layer trash (Google & OEM) and a much more locked down experience. But the quality of it hasn't improved, it just got worse.
Doesn't make sense anymore. They can now do 99% of the same things, but iOS has a better quality OS, better apps and better vertical integration.
Not even vertical integration, actually just any kind. FFS it's 2026 and the recommended android way to send a photo to your mac/PC is "upload to google photos and hope it decides to sync".
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.
Not a rhetorical tinfoil question: Does anyone still believe there's some hope for personal freedoms?
Perhaps they should be subjected to the full force of the First Amendment.
* https://keepandroidopen.org/
- 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.
Not everyone has the same threat model as you, $BIGTECHCORP.
Like, if security was a concern we would have simpler systems and still use 2fa devices for banks etc.
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.
--
[0] - Which I find deeply ironic, in that merely a decade ago, people would laugh at Windows with its "reboot after installs, reboot in case of problems" approach, and now frequent reboots are seen as Standard Security and Stability Practice on *nix systems, both mobile and server-bound...
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.
"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.
And why should modern corpo maintain additional complexity to pander to 1% of privacy-aware tech-savvy users?
Either way the writing is on the wall, and has been for a while.
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
Per FTC, a stalkerware will: geo locate, read call list & record calls, read notifications, texts, & possibly emails, access gallery, camera, & files, and monitor network activity. [1]
You could do all of those with "on-device adb" (in some cases, with just the appropriate permissions), without root access. Stalkerware & financial fraud enabled merely due to the scale & reach of Android (half of humanity uses it!) and lack of basic security literacy warrants such protective measures, as (Thaler & Sunstein would like to remind us) defaults matter.
With conspiracies abound, we must not lose sight of tech safety and related issues, which almost exclusively affect the most vulnerable & the most disadvantaged.
[0] https://www.techsafety.org/spyware-and-stalkerware-phone-sur...
[1] https://consumer.ftc.gov/articles/stalkerware-what-know
revenue must go up