Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

201–210 of 535 posts

Re: Android may soon restrict on-device ADB

#201
post #128

Limiting ADB is the obvious next step. Even if this one specific feature request does not come to pass, Google has cornered everyone into relying on a developer interface for any normal personal computing tasks, whether running on-device or through USB/wireless. It's quite clear at some point in the future you will either be required to surrender your identity to them and pay a yearly fee or be severely limited to co…

> As if you didn't need any more proof you don't own "your" devices.

Can you install your own OS? If yes, you own it. And Google consistently lets you do that. It other OEMs don't then direct your outrage at them.

Re: Android may soon restrict on-device ADB

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

Need to pressure banks to achieve feature parity between their websites and native apps. I'm forced to use Paypal to remote deposit checks because my banks limit that feature to their apps, which I can't use because of my device's age. (Paypal does, too, but their app still works for now.)

Re: Android may soon restrict on-device ADB

#203

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)

> many banks in the UK no longer offer a web portal Same in Norway.

Is it that dire? I'm in with DNB and Nordea and they both have functioning netbanks. But I don't know how the rest are.

I've been getting by with a bankid codebrick and web browser access (although Nordea and DNB apps work fine on GrapheneOS).

Re: Android may soon restrict on-device ADB

#204

Earlier quoted context omitted.

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.

Sometimes attacks happen from users being instructed to enable settings in order to achieve something regardless of whether you’d expect them to have a reason to use the setting

... and it is stupid to try to protect cretins who would do that by screwing everybody else.

Re: Android may soon restrict on-device ADB

#205

Earlier quoted context omitted.

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.

Sometimes attacks happen from users being instructed to enable settings in order to achieve something regardless of whether you’d expect them to have a reason to use the setting

If someone is willing to click on build version 5 times and then gets a mystery prompt about dev mode, and still goes along with the next 4 steps I think they were gonna get hacked a billion different other ways

Re: Android may soon restrict on-device ADB

#206
post #99

Earlier quoted context omitted.

> This attack vector requires both that the user enabled developer settings and that they have remote adb enabled. Not just that. A non-development Android build will also prompt the user when a connection is made to authorize the client's key. This once again isn't about security of users, this is about security of the company's interests.

Google just got hit by yet another record antitrust fine by the EU [1]. But as long as they see these fines as cost of doing business, nothing will change. Especially if it always takes almost a decade to push this through the judicial system. Their net income last year alone was $130 Billion. [1] https://www.reuters.com/world/eu-top-court-dismisses-google-...

The EU shouldn't be regulating Google like this.

The US should.

Re: Android may soon restrict on-device ADB

#207
post #128

Limiting ADB is the obvious next step. Even if this one specific feature request does not come to pass, Google has cornered everyone into relying on a developer interface for any normal personal computing tasks, whether running on-device or through USB/wireless. It's quite clear at some point in the future you will either be required to surrender your identity to them and pay a yearly fee or be severely limited to co…

> As if you didn't need any more proof you don't own "your" devices. Can you install your own OS? If yes, you own it. And Google consistently lets you do that. It other OEMs don't then direct your outrage at them.

>Can you install your own OS? If yes, you own it.

Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0). Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1) And without developers pouring tens of thousands of work hours into making projects such as GrapheneOS viable despite Google, you wouldn't even be able to do much that requires anything to do with SafetyNet and all successors delivered through Google Play Services, which is functionally the core component of any Android device for the near entirety of typical use-cases. And I'm not excusing OEMs, but they did not build their market share off of being "open" then start to close every door and trap you in it.

0. https://www.fitzsim.org/blog/?p=545

1. https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...

Re: Android may soon restrict on-device ADB

#208
post #145
post #119

Earlier quoted context omitted.

It seems to require the user to: 1. Enable Developer Mode by going to an obscure settings page and tapping the build number seven times 2. Enable USB ADB debugging in the Developer Options 3. Establish an actual USB ADB session 4. Enable TCP/IP ADB debugging in the Developer Options 5. Unknowingly download a malware app from the official Play Store 6. Blindly click "Yes" on the permission prompt. In other words: this…

> In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. Have you ever worked with someone who barely knows how to use a mobile phone? They will hand their phone over to someone they barely even know to do something they don't understand. They will follow instructions from a stranger over the phone, without understanding what the phone is…

Those people will be conned in a million other ways.

Re: Android may soon restrict on-device ADB

#209
post #119
post #40

Earlier quoted context omitted.

Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?

It seems to require the user to: 1. Enable Developer Mode by going to an obscure settings page and tapping the build number seven times 2. Enable USB ADB debugging in the Developer Options 3. Establish an actual USB ADB session 4. Enable TCP/IP ADB debugging in the Developer Options 5. Unknowingly download a malware app from the official Play Store 6. Blindly click "Yes" on the permission prompt. In other words: this…

I think expert users on HN seriously downplay the ability and willingness of "regular users" to do very stupid things on their devices. If grandma wants that app that gives her a beautiful horse as a lock screen image, she will follow every one of those six steps that the malware HorseLockScreen app developer presents to her. She will tap a button that has a skull and crossbones icon, that says "tapping this will drain your bank account and kill your dog" if she thinks it will let her do whatever she's trying to do on her device. Have you guys never done IT tech support for your elderly parents' computers?

I'm not saying it's right to respond by simply locking everything down, but let's not downplay the blast radius of basically every attack that involves telling the user to do things.

Post reply on HN