Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

Post reply on HN
Print view View original

451–460 of 536 posts

Re: Android may soon restrict on-device ADB

#451

Post by KludgeShySir »

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),…

I'm begging, please let me use password "asdfasdf" on throwaway accounts. I accept full responsibility for the fallout.

Seriously, many web admins need to hear this message: "Chill. Your site is not that important."

Re: Android may soon restrict on-device ADB

#453

Post by mayama »

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…

> and only because by some miracle there are companies out there who started trusting Graphene's attestation keys.

Are the bank apps trusting graphene keys or google them self? Isn't play attestation completely in the hands of google.

Re: Android may soon restrict on-device ADB

#454

Post by swat535 »

caminante wrote: post #425
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),…

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.

$3 payout? You're being generous, last time there was a major breach, I believe Equifax gifted the victims a year of "free subscription" for their service.

Accountability is nonexistent in our industry.

Re: Android may soon restrict on-device ADB

#455

Post by 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.

Re: Android may soon restrict on-device ADB

#456

Post by wolvoleo »

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),…

Exactly. At work I now have to MFA and type a random code every time I want to book a desk. It kills the session after 30 minutes. It's ridiculous. If an attacker ever got hold of it, they could... book a desk at that shitty office for me. Whoopty doo what horror.

The same with logging my hours in a different system. I only use those systems for those things, nothing else.

Security is important for things that actually hold value. Like when I connect to my admin account. Or even when I connect to our intranet. But they enforce the highest level even for stupid stuff.

Re: Android may soon restrict on-device ADB

#457

Post by wolvoleo »

hnlmorg wrote: post #384
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),…

IT has always been a spectrum with security at one end and convenience at the other. There is no recent trend that’s changed that. That’s just how life works.

Yes but the balance has shifted a lot.

I remember working at a major company where important systems had an admin password of "123". That was stupid. I asked to change it but the answer was no because too many people would have to be told the new password.

That was too much in favour of convenience and I'm surprised they never got pwned in the worst way.

These days the balance has swung way too much in favour of security though. Even when it concerns assets that have no value.

Re: Android may soon restrict on-device ADB

#458

Post by wolvoleo »

dotancohen wrote: post #432
KerrAvon wrote: post #386

Earlier quoted context omitted.

"Better things aren't possible" is a terrible outlook. There have been real improvements in this space, such as passkeys, and recognition that some of this stuff, like frequent password changes, is counterproductive.

In what way are Passkeys, as implemented (not theoretical benefits), better than passwords? Better: not in a single metric but rather as a complete measure of both preventing unauthorized access to a resource and also _enabling_ authorised access to that same resource.

They're better in some ways. They don't rely on a secret with low entropy which is really brute forceable. They can't be used on a phishing site because the URL is part of the secret. Even when you authenticate to a fake site you don't give them the ability to authenticate as you until you change the secret (like you do when you give them your password)

They also have 2fa built in. No need for a separate app, entering codes whatever.

Re: Android may soon restrict on-device ADB

#459

Post by wolvoleo »

PunchyHamster wrote: post #426
miroljub wrote: post #188

Earlier quoted context omitted.

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

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

I think the OP means that calling it sideloading gives it a sneaky dark connotation which it doesn't deserve because installing software is simply a normal thing for a user to do. It's Google that's branding it as such because they want people to only trust the play store, and thus protect their 30% stake and other benefits like deciding what goes in the store.

Re: Android may soon restrict on-device ADB

#460

Post by wolvoleo »

light_hue_1 wrote: post #50
p-e-w wrote: post #26

Earlier quoted context omitted.

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.

I don't think the developers are bad, the problem are the top dogs that are telling them what to do.
Post reply on HN