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

101–110 of 535 posts

Re: Android may soon restrict on-device ADB

#101

Post by TeMPOraL »

izacus wrote: post #73
roer wrote: post #61

Earlier quoted context omitted.

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

It would break exactly 0 apps because none of the apps should be using this API to access your private data and phone call audio.

Why? What other APIs should my apps (or the apps I explicitly want to authorize for this purpose) use to access my private data and my phone call audio?

Re: Android may soon restrict on-device ADB

#102

Post by BoxwoodSeed »

daemin wrote: post #95
peheje wrote: post #42

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 these days bank apps are required by the banks for "security", and good luck getting anything done without the bank app installed on your phone. The only other alternative available is SMS but that is being phased out (rightly so) for being insecure.

Currently my bank requires a device where I need to insert my card to get a one time six digit code based on a QR code the banking website serves me that the device scans.

I'm not quite sure why they don't support something like a yubikey with FIDO, but maybe there's a good reason.

Re: Android may soon restrict on-device ADB

#103

Post by xg15 »

SXX wrote: post #19
throw9394999 wrote: post #14

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.

This is solvable by adding big huge warning that ADB is running. Not by removing feature.

That huge warning would also be permanently shown for everyone using Shinzuku apps. I think that UX would neither be desirable nor increase security.

Re: Android may soon restrict on-device ADB

#104

Post by dns_snek »

TeMPOraL wrote: post #93
dns_snek wrote: post #90

Earlier quoted context omitted.

Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.

Yes, but what about allowing me to run adb commands on my phone with my consent , and especially delegating that privilege to "strangers", again, with my ( one-time ) consent - by which I mean authorizing apps to run with elevated privileges and/or reestablish the debugging bridge once it invariably disconnects (for other more or less legitimate security reasons)? It's not like those threats silently turn on ADB on p…

They're 3 separate issues. There's a genuine vulnerability (CVE) which has been fixed, there's a follow-up proposal to allow the user to choose which interfaces to bind to, and there's another proposal to disallow ADB over loopback which would cut you off from using ADB on-device.

Your problem is with the last one which has nothing to do with the CVE itself.

Re: Android may soon restrict on-device ADB

#105

Post by TeMPOraL »

izacus wrote: post #69
light_hue_1 wrote: post #50

Earlier quoted context omitted.

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.

[flagged]

You forgot to ask yourself whose interests are being secured, and who/what is the threat being secured from.

Security is not an unqualified good. It's just mechanism of control.

Re: Android may soon restrict on-device ADB

#106

Post by microtonal »

izacus wrote: post #46
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…

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). But sure, Google evil.

I am not sure I follow. Are you referring to the original CVE (?), I fully agree that it should be fixed, and it is not what my comment was about.

If you are talking about allowing listening on localhost - remote ADB requires enabling in the developer settings. It is a developer feature, similar to ADB over USB. If I'm charitable, it is possible that they are seeing too many people that are using Shizuku without understanding the security implications. But Shizuku has a lot of useful applications and they use ADB because the Android APIs and permission system are lacking and do not make these applications possible.

Re: Android may soon restrict on-device ADB

#107

Post by BoxwoodSeed »

OsrsNeedsf2P wrote: post #55

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..?

Linux phone is already a thing that exists and is at a point where it can be used by tech illiterate people within the confines of what is possible normally.

It's just that few people bother using it. But that number might increase if Android continues it's war against its users.

Re: Android may soon restrict on-device ADB

#108

Post by dns_snek »

gnfargbl wrote: post #94
izacus wrote: post #46

Earlier quoted context omitted.

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). But sure, Google evil.

You, and may of the people in the thread here are at cross purposes, I think. The CVE mentioned in the article is https://nvd.nist.gov/vuln/detail/CVE-2026-0073 . That's a real CVE: logic error leading to auth bypass. Fix can be seen at https://android.googlesource.com/platform/packages/modules/a... . Separately, a number of people here are attempting to argue that the availability of On-Device ADB should be regarded…

> Separately, a number of people here are attempting to argue that the availability of On-Device ADB should be regarded as a "CVE" in and of itself. Google does not appear to share that view.

This was proposed by a Google employee: https://issuetracker.google.com/issues/526109803#comment3

Re: Android may soon restrict on-device ADB

#109

Post by IshKebab »

IvanK_net wrote: post #41

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.

That's already the case for Netflix and other video streaming services.

You don't have to pay a fee directly, but you can't use open source web browsers.

Re: Android may soon restrict on-device ADB

#110

Post by atif089 »

devsda wrote: post #27
satvikpendem wrote: post #8

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.

Google is working on a new recaptcha strategy to counter that. Essentially any non Google flavor of Android OS will fail recaptcha validation
Post reply on HN