Android may soon restrict on-device ADB • Hacker News Board

Re: Android may soon restrict on-device ADB

#421

Post by Cider9986 » Sat, Jul 25, 2026, 10:05 PM UTC

matheusmoreira wrote: post #406

bayindirh wrote: post #157

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.

Android became a lost cause the second they introduced hardware remote attestation. Even if there was a way to install your own software, there's no point in doing so. You're "tampering" with the device. Fail attestation and you're untrusted. You get banned from everything. If you hack, you're ostracized from digital society. You're a second class citizen. Can't communicate. Can't bank. Can't stream. Can't play video…

Agreed, GrapheneOS is underrated.

Re: Android may soon restrict on-device ADB

#422

Post by bpavuk » Sat, Jul 25, 2026, 10:13 PM UTC

TeMPOraL wrote: post #139

bpavuk wrote: post #77

Earlier quoted context omitted.

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

Yes, really. The obvious answer that security maximallists deny even exists is, who is doing it and why. In LLM case, users are doing it themselves to allow a way of computing they want and find useful, in spite of platform locks designed to deny users just that.

I mean, go tell Anthropic to prompt Claude to make it adopt Landlock in Claude Code instead of regex-based filtering. actually adopt it, not how Codex did, but with controls on the level of some third-party harnesses and Pi plugins.

Re: Android may soon restrict on-device ADB

#423

Post by bluebarbet » Sat, Jul 25, 2026, 10:28 PM UTC

matheusmoreira wrote: post #407

zaptheimpaler wrote: post #325

Earlier quoted context omitted.

"Security" is just a scourge on software at this point. It means 2FA on every trivial site, being logged out every few hours for no good reason, having to fuck with settings and type "disable sandbox" to run an agent in YOLO mode which still won't work over mobile, being unable to install an unsigned extension at all in firefox (not behind a setting, literally impossible - you have to get Firefox Developer Edition),…

All this boils down to governments wanting security from their citizens and corporations wanting security from their customers. It's not going to stop, ever .

Taking this attitude, it's guaranteed.

Re: Android may soon restrict on-device ADB

#424

Post by bluebarbet » Sat, Jul 25, 2026, 10:32 PM UTC

Cider9986 wrote: post #419

asveikau wrote: post #352

Earlier quoted context omitted.

In the post iPhone era, a lot of what gets sold as security features is actually just removing functionality from the device. In early days of this, I honestly think it was rooted in the famous Steve Jobs paranoia, the one that shipped without an app store and told users to use Safari, the same Steve Jobs that was said to not want certain medical devices during cancer treatment to touch him because they weren't beaut…

Hard disagree. iPhones are some of the most secure devices available. They are much more secure than desktop computers. This is a good thing because it protects users private data. With how much personal data phones, it seems reasonable to secure them extensively. That's why I use GrapheneOS.

>iPhones are some of the most secure devices available

How do you know? We're not allowed to see the source code.

Re: Android may soon restrict on-device ADB

#425

Post by caminante » Sat, Jul 25, 2026, 10:59 PM UTC

zaptheimpaler wrote: post #325

microtonal wrote: post #30

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 o…

"Security" is just a scourge on software at this point. It means 2FA on every trivial site, being logged out every few hours for no good reason, having to fuck with settings and type "disable sandbox" to run an agent in YOLO mode which still won't work over mobile, being unable to install an unsigned extension at all in firefox (not behind a setting, literally impossible - you have to get Firefox Developer Edition),…

You forgot your $3 payout from the class action lawsuit when the company STILL gets hacked and the exec bonus pool increases because the settlement wasn't "that" bad.

Re: Android may soon restrict on-device ADB

#426

Post by PunchyHamster » Sat, Jul 25, 2026, 11:16 PM UTC

miroljub wrote: post #188

PunchyHamster wrote: post #98

Earlier quoted context omitted.

It's not because of security. It's to slowly close any avenues for side-loading stuff

It's not side loading. Word you are looking for is called "installing".

Not on android https://www.reddit.com/r/explainlikeimfive/comments/1k824n8/...

Re: Android may soon restrict on-device ADB

#427

Post by 1saadcodes » Sat, Jul 25, 2026, 11:24 PM UTC

I'd be interested to see whether this comes with a replacement for legitimate use cases. Removing a capability without offering an alternative tends to push developers toward even more fragile or in some cases "rule breaking" workarounds

Re: Android may soon restrict on-device ADB

#428

Post by paulnpace » Sat, Jul 25, 2026, 11:40 PM UTC

zaptheimpaler wrote: post #325

microtonal wrote: post #30

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 o…

"Security" is just a scourge on software at this point. It means 2FA on every trivial site, being logged out every few hours for no good reason, having to fuck with settings and type "disable sandbox" to run an agent in YOLO mode which still won't work over mobile, being unable to install an unsigned extension at all in firefox (not behind a setting, literally impossible - you have to get Firefox Developer Edition),…

It will be "so convenient" when we finally have digital ID so we won't have to deal with all that stuff.

Re: Android may soon restrict on-device ADB

#429

Post by bigbuppo » Sun, Jul 26, 2026, 12:08 AM UTC

zaptheimpaler wrote: post #325

microtonal wrote: post #30

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 o…

"Security" is just a scourge on software at this point. It means 2FA on every trivial site, being logged out every few hours for no good reason, having to fuck with settings and type "disable sandbox" to run an agent in YOLO mode which still won't work over mobile, being unable to install an unsigned extension at all in firefox (not behind a setting, literally impossible - you have to get Firefox Developer Edition),…

Wait until you figure out just how much trust is required to make Zero Trust work.

Re: Android may soon restrict on-device ADB

#430

Post by bigbuppo » Sun, Jul 26, 2026, 12:10 AM UTC

jck86 wrote: post #367

zaptheimpaler wrote: post #325

Earlier quoted context omitted.

"Security" is just a scourge on software at this point. It means 2FA on every trivial site, being logged out every few hours for no good reason, having to fuck with settings and type "disable sandbox" to run an agent in YOLO mode which still won't work over mobile, being unable to install an unsigned extension at all in firefox (not behind a setting, literally impossible - you have to get Firefox Developer Edition),…

> 2FA on every trivial site But it helps against account sharing, err I mean they make database leaks irrelevant except for private info of the customer, err I mean that we can now send more mail to the customer about new AI features without risking they think it is phishing, err I mean this is the easiest measure for the auditor findings so since we implemented this we don't need to fix all the crappy internal api a…

Except for Microsoft, who just sort of scale back MFA (unless you pay for Microsoft 365 Pro Gold Deluxe Plus Platinum Millenium Edition E5 to set the policy that used to be free) because of reasons.