The other proposed change (to restrict access to certain interfaces or IP addresses) seems good, but why not allow developers to restrict access localhost?

It reeks of trying to block Shizuku, Canta, etc. using a way that only makes it look like a side-effect.

I'm a developer with remote adb enabled, using it in the normal intended way (to install new builds of an Android project I'm developing, retrieve log files related to it, etc). Currently, I access this via VPN (tailscale), but it's exposed to connections (and any pre-auth security vulnerability risks) on any random public wifi network I connect to. Adding the ability to restrict this to just tailscale will be an improvement, for me.

The proposal at the top of the thread is that you specify which interface you want it to bind to, when you set up remote adb, rather than binding to every interface. Nothing in that proposal suggests that "localhost" would be rejected as a choice of interface. One person suggested binding only to "wlan0", but that was a short throwaway comment that is obviously wrong (wlan0 is less-trusted than VPNs) and obviously not what they're going to do.

>Don’t even get me started on OEMs that force an audio warning such as “This call is being recorded,” when it’s in places where it’s not legally required.

This is also Google's fault. Their dialer--that OEMs increasingly pick over their own, despite their always being much better, see old MIUI one for example--just blanket applies the rule almost everywhere. Especially annoying on all MediaTek SoCs that do not support the feature on an hardware level at all through proper, reliable third-party applications. As if you didn't need any more proof you don't own "your" devices. But maybe in a couple years Gemini will be able to listen to the calls and summarize them for you, just need to go through the approved surveillance channel.

So nothing would change (they can also lock away your "valuable community feedback" because what bothers them is the criticism itself), thus feel free to express your approval

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.

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.

My elderly mum has an Android phone. She is not very tech-literate.

She might see a full page ad "your phone has a virus, clean it now", or somehow end up on something like it (e.g. a scam email).

She then dutifully clicks on it, which prompts to download an apk. The webpage provides clear instructions for how to install the just-downloaded APK.

That APK (app) then walks her though enabling ADB, so it can "clean the phone". The app gave very good instructions (customized to reflect the UI that her device manufacturer would use), so she manages to click through to the hidden settings menu and enable ADB.

The app can now exfiltrate all sorts of data, without needing any scary permissions prompt which will tell the user what is being accessed.

I think this sort of pattern is very real, and many users are being affected by these scams. And undoubtedly more android users than iOS ones.

Finding a balance that allows power users like me to use my device as I wish, and protecting regular users, is quite hard. I think the solution Google came up with of requiring a 24 hour wait, + some extra scary warnings, for unsigned apps is a step in the right direction, it helps less tech literate users avoid scams, and power users just have to be patient for 24h. But of course it's still not satisfactory for everyone, mum might still get scammed, and power users get annoyed at it.

So, they don't want me to even have that one reason to keep choosing Android, I guess.

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

https://github.com/thedjchi/Shizuku/wiki/setup

So it requires

* Enable Developer Options if not already enabled (Generally, this is done by going to Settings > About device and tapping Build number 7 times).

* Enable both USB debugging and Wireless debugging. Tap "Allow" if prompted to allow wireless debugging on the current network.

* Tap Pair device with pairing code.

* Downloadd other apps like ShizuCallRecorder

Or seems to be exactly what this user described.

https://news.ycombinator.com/reply?id=49046291&goto=item%3Fi...

Not being able to use VPNs might be a problem in corporate setups (e.g. debugging an issue in production environments).

I Don't know what else I can do though, next up is switching to grapheneOS but I'm a ways off from that for now.

In case it is made private.

I assume Sailfish and Ubuntu Touch are completely unimpacted?

I feel like an iPhone will be next. Good Android phones are already pricey

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.

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

* https://keepandroidopen.org/

Now, the tradeoff is - less vertical integration, double the integration layer trash (Google & OEM) and a much more locked down experience. But the quality of it hasn't improved, it just got worse.

Doesn't make sense anymore. They can now do 99% of the same things, but iOS has a better quality OS, better apps and better vertical integration.

Not even vertical integration, actually just any kind. FFS it's 2026 and the recommended android way to send a photo to your mac/PC is "upload to google photos and hope it decides to sync".

Android is turning into the iOS/OSX/Win11 model. It’s not your device, you’re just renting it.

You need permission to install applications, or do anything else outside of consuming subscription services.

Where are the Linux phones ?

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.

Do these people even know tech illiterate people? They couldn't enable ADB even with instructions.

Either way the writing is on the wall, and has been for a while.

Not a rhetorical tinfoil question: Does anyone still believe there's some hope for personal freedoms?

I mean it's OK for the crowd here, because amongst us are people who created the technical backends to let these rackets going.

They started with "we love open" and when became virtual monopoly they extort the position :/

Or maybe Google is genuinely about thinking this in good faith. I can't see how, though.

- The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected. No silent exploitation attempts are possible.

I understand the author's rationale and think the reasons why that whole ecosystem is accessing ADB are legitimate - but I have some questions here.

The above flow is basically what apps that use Shizuku have to do as well, right? Only that in that case, the user would deliberately install the app and have the knowledge it uses ADB features and therefore would also confirm the permission prompt.

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

So it also cannot remember that a particular app was already authorized by the user and has to display the prompt again on each connection attempt?

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

This seems honestly like Shizuku itself would increase the risk of a user granting ADB access to a bad actor (i.e. a second app or external connection that is different from the app the user wanted to authorize).

Thinking of "scenario 3" if a Shizuku-enabled app is already running on the device and something else wants to connect to ADB:

- I'm assuming a malicious app was already installed (without privileges) or something tries to connect to port 5555 from outside or via proxyware.

- ADBD is already running and listening for TCP to serve the Shizuku app, so those steps can be taken for granted.

- The malicious app or connection triggers a permission prompt from ADBD. However, by that time, the user has grown used to those prompts, because the Shizuku triggers them frequently, so they are more likely to select "yes".

If ADBD has no information about who is connecting, it also can't show any meaningful information in the prompt. So it cannot really help the user distinguish prompts from the legitimate Shizuku app from malicious prompts. A user still has the timing and context to distinguish prompts, i.e. prompts that appear out of the blue when they aren't using the app are suspicious.

Louis Rossman will have a field day with Google here. I think it is time to end Evil - that is, to end Google. This company serves no more useful purpose on this planet anymore.

Perhaps they should be subjected to the full force of the First Amendment.

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

Per FTC, a stalkerware will: geo locate, read call list & record calls, read notifications, texts, & possibly emails, access gallery, camera, & files, and monitor network activity. [1]

You could do all of those with "on-device adb" (in some cases, with just the appropriate permissions), without root access. Stalkerware & financial fraud enabled merely due to the scale & reach of Android (half of humanity uses it!) and lack of basic security literacy warrants such protective measures, as (Thaler & Sunstein would like to remind us) defaults matter.

With conspiracies abound, we must not lose sight of tech safety and related issues, which almost exclusively affect the most vulnerable & the most disadvantaged.

[0] https://www.techsafety.org/spyware-and-stalkerware-phone-sur...

[1] https://consumer.ftc.gov/articles/stalkerware-what-know

revenue must go up

Anyone up for the challenge? Or a better solution.

Fuck this bullshit. It's only going to get worse.