Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

161–170 of 536 posts

Re: Android may soon restrict on-device ADB

#161
LEA, Customs and intelligence agencies regularly use GDB to hack and extract information from an Android phone. So in that sense it may be a valid concern and reason to restrict this.

However, I'm pretty sure these entities will already have negotiated exemptions from the restrictions so in that sense they don't add much security.

Re: Android may soon restrict on-device ADB

#162

LEA, Customs and intelligence agencies regularly use GDB to hack and extract information from an Android phone. So in that sense it may be a valid concern and reason to restrict this. However, I'm pretty sure these entities will already have negotiated exemptions from the restrictions so in that sense they don't add much security.

Yeah, and they regularly use USB cables to do that too.

Re: Android may soon restrict on-device ADB

#163

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…

This. I'm a developer, I've published Android apps, & I've still managed to lose access to a device that had dev settings enabled purely because remote adb enablement is a (extremely fiddly) toggle that happened to be off on the device at the time the screen broke. Having these two enabled simultaneously is such a rare case in the wild as to be entirely negligible as a vector.

Re: Android may soon restrict on-device ADB

#164
post #67

Earlier quoted context omitted.

"An app can bypass OS security system with certain setting enabled" absolutely fits into CVEs. There's no "depends: on it. I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.

Anything can fit into CVE. "An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so. "A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too. Whether it matters or is something that should be addressed, is the d…

Apps being able to bypass a restriction put on them by the OS always matter.

Whether that means there's a _feature_ lacking there, is another question.

Re: Android may soon restrict on-device ADB

#165
To quote Scott McNealy, then CEO of Sun microsystems, circa 1999:

"You have zero privacy anyway. Get over it".

It has become truer every year that has passed since then.

The 2026 version : "If you believe you will be allowed to keep any kind of control over the devices you "own", you are deluding yourself".

Re: Android may soon restrict on-device ADB

#168
post #155

Earlier quoted context omitted.

Unfortunately many banks in the UK no longer offer a web portal or physical branches. I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly. (I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)

Huh? Why the hell would you use a bank that doesn't offer a web portal or have branches if there are banks that still do?!?! I bank with HSBC in the UK and there's still branches (worldwide) and banking via web. I assume you mean things like Starling and Monzo in this case? Banking with them is simply dangerous .

There's mobile payment apps worldwide like yappy and UPI, that don't have a web interface and are local monopolies. Even worse they are sometimes controlled by a single large bank, not a government and not a consortium so you're entirely beholden to their (confidential) decisions, whatever they might be. It's not like in the US where you have Venmo, Zelle, and Cash app, or China where there's WeChat and alipay.

Re: Android may soon restrict on-device ADB

#169
post #95

Earlier quoted context omitted.

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.

because it's so niche it's not profitable to implement

Re: Android may soon restrict on-device ADB

#170

Earlier quoted context omitted.

> 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

That link is mentioned in the article. To quote it: > Connection to localhost has also been the source of exploit where app are using that socket to adbd to escalate their privileges. What about we restrict to always only binding to wifi interface wlan0 ? Nowhere in that text do I see a proposal to assign an additional CVE for this behaviour. Personally I think it would be unusual to assign a CVE for intended-but-pot…

Yeah, they didn't claim that it's a CVE, just behavior that they wanted to change. Miscommunication then.
Post reply on HN