全部文章0
Hacker Newsshscs911··访问 1

Android may soon restrict on-device ADB

原网页

Article URL: https://kitsumed.github.io/blog/posts/android-may-soon-restrict-on-device-adb/

Comments URL: https://news.ycombinator.com/item?id=49045159

Points: 890

# Comments: 430

Hacker News 讨论

893 points · 432 comments · 查看原帖

  1. microtonal

    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.

  2. 0x_rs

    Limiting ADB is the obvious next step. Even if this one specific feature request does not come to pass, Google has cornered everyone into relying on a developer interface for any normal personal computing tasks, whether running on-device or through USB/wireless. It's quite clear at some point in the future you will either be required to surrender your identity to them and pay a yearly fee or be severely limited to continue using it in any meaningful capacity, because Google does not want you to develop applications on Android outside their controlled channels -- and it's a developer bridge, the battle was already lost when they did not back down from the changes forbidding normal, legitimate ̶s̶i̶d̶e̶l̶o̶a̶d̶i̶n̶g̶ installation . >Don’t even get me started on OEMs that force an audio warning such as “This call is being recorded,” when it’s in places where it’s not legally required. This

  3. wolvoleo

    > This feature was proposed following a major security issue identified as CVE-2026-0073, which allowed the Wireless ADB authentication process to be fully bypassed. What is proposed in this issue is actually a nice idea. Clearly this is not an issue when the wireless authentication process works as intended. I see no need to change that at all. They just need to fix that bug. It's quite difficult to do this. You need to enable wireless debugging. Then pair to a random port with a random pairing code and then connect to yet another random port. When it works as intended it's more than secure enough. If they really want to restrict it, just let the user choose in the development settings what interface to listen to.

  4. eviks

    > 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

  5. bayindirh

    When Google first announced sideloading restrictions, somebody told “but we have ADB”, and who disagreed with them was criticized harshly. Now, I’m waiting for a workaround to enable ADB, so sideloading can be handled now, too. Android is not more open that iOS for a very long time now. The trend will continue. Again, this is not a technical problem (the mindset of Google), so technological solutions won’t help.

  6. satvikpendem

    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.

  7. jimrandomh

    As far as I can tell, this is a big overreaction to a misunderstanding. I'm a developer with remote adb enabled, using it in the normal intended way (to install new builds of an Android project I'm developing, retrieve log files related to it, etc). Currently, I access this via VPN (tailscale), but it's exposed to connections (and any pre-auth security vulnerability risks) on any random public wifi network I connect to. Adding the ability to restrict this to just tailscale will be an improvement, for me. The proposal at the top of the thread is that you specify which interface you want it to bind to, when you set up remote adb, rather than binding to every interface. Nothing in that proposal suggests that "localhost" would be rejected as a choice of interface. One person suggested binding only to "wlan0", but that was a short throwaway comment that is obviously wrong (wlan0 is less-trust

  8. Superblazer

    This is huge, Android getting locked down to such levels should be sounding alarm bells. They are slowly removing everything that makes Android good.