Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

321–330 of 535 posts

Re: Android may soon restrict on-device ADB

#321
post #216
post #70

Earlier quoted context omitted.

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.

Security, but not for you, is no security.

Have you read the android security model? It's a multi party security model which considers apps and users as equals. It's a legitimate security model and just because it's not what you want doesn't mean it's wrong.is it user hostile? Maybe. But that is different than saying it offers no security. It's also not worth bickering about every small decision that is made in line with that security model. If you want a different one, push for it via alternative OS.

Re: Android may soon restrict on-device ADB

#322
post #17
post #3

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.

Google doesn't want you to be able to skip YouTube ads. It's as simple as that.

More specifically apps and users have equal agency in the android security model. Which comes down to the fact that if you don't own the app you can't control its experience. This feels grounded to me. Push for more open source apps where you retain control and ownership.

Re: Android may soon restrict on-device ADB

#323
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.

If I didn't word it like that (I'm the author) the "reddit mob" would have exploded the thread. That's the last thing I want. I want valuable feedback there, for now its somehwat working.

Most of the users who saw the post on reddit didn't even open the blog post anyways, according to analytics.

Re: Android may soon restrict on-device ADB

#324
post #17

Earlier quoted context omitted.

Google doesn't want you to be able to skip YouTube ads. It's as simple as that.

More specifically apps and users have equal agency in the android security model. Which comes down to the fact that if you don't own the app you can't control its experience. This feels grounded to me. Push for more open source apps where you retain control and ownership.

No, I bought the device, I should be able to do whatever I want with it.

Re: Android may soon restrict on-device ADB

#325

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), sites spamming me to get passkeys which will no doubt be declared insecure and replaced by some more moronic thing when users find a way to get hacked with those too, 80 layers of access control/service identities/IAM/Oauth to host an S3 bucket, OAuth everywhere that won't even work on a headless device, banking websites that want their own special snowflake app as 2FA instead of using TOTP, banning VPNs and slowly rolling out completely real identity surveillance on every corner of the internet to "protect the children", ban open-weight models because the numbers are going to send your data to China, and it just goes on and on and on..

When is this insanity going to stop? I really think the IT security industry ought to be ashamed of itself. Security has become a totalizing value that trumps every other value - convenience, user-friendliness, privacy, hackability, openness, just anything at all in the name of MORE SECURITY.

Re: Android may soon restrict on-device ADB

#326
I was thinking a lot about how these restrictions are paved with good intentions, but every time these new security measures are implemented we see criminals adopt new strategies and continue going about their day like nothing ever happened.

I've been seeing this specifically with ID / business verification requirements where they just have some innocent (or sometimes complicit) third party grant them access to verasign 'verified' trust signing keys which actually makes them way more trusted than they were ever before often making anti-malware applications way less strict about blocking it which in turn buys them just enough time to compromise the system and disable said anti-malware applications. The problem here is that anti-malware applications try to be seemless and are effectively in a giant race condition to terminate the application, more recently microsoft anti malware service will now block program execution until it validates that it is safe. Although it is not something other companies do as making the device feel sluggish is something they avoid at all costs (looking at you bitdefender).

Re: Android may soon restrict on-device ADB

#327

Earlier quoted context omitted.

More specifically apps and users have equal agency in the android security model. Which comes down to the fact that if you don't own the app you can't control its experience. This feels grounded to me. Push for more open source apps where you retain control and ownership.

No, I bought the device, I should be able to do whatever I want with it.

And app developers have the right to not offer their services to users who don't give them the security model they want.

You are free to install a custom OS which provides you the security model you desire. You have choices.

Re: Android may soon restrict on-device ADB

#328
post #214

Earlier quoted context omitted.

the question isn't whether you still have a reason to choose android - the question is what alternative do you have but android (or iOS).

If my phone is going to be locked down anyway, I'm choosing the platform that at least pairs with my AirPods properly and doesn't get me weird looks at social events. Google is really stretching their goodwill with this one. The ability to sideload and debug my phone is the only marginal benefit to these janky Java relics. If that's gone, no reason not to switch to a wholely better platform.

If I don't get weird looks at the kinds of social events where everyone else has an iphone, then I have failed at life. I can think of no greater horror than to be seen as uninteresting.

Re: Android may soon restrict on-device ADB

#329
post #96

> Scenario 3: A Developer Using ADB over TCP/IP - You install a malicious application. - You enable USB debugging, starting ADBD. - You connect via USB ADB to enable TCP/IP, then disconnect the USB cable. - ADBD continues running and listens on all network interfaces. - The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected.…

> However, ADBD in this situation only sees a connection attempt, not which app made the attempt, right?

Every ADB connection has some kind of certificate / key that is saved locally. This means that a new application would have a different certificate. That certificate is shown in the yes/no prompt.

> Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?

You can tell android to remember that certificate and allow the connection next time. There is a bug that make it not work on certains specific version of Android 12 I think, but outside of that, it always works.

Re: Android may soon restrict on-device ADB

#330

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 really think the IT security industry ought to be ashamed of itself.

See Pournelle's Iron Law of Bureaucracy.

Post reply on HN