Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

31–40 of 535 posts

Re: Android may soon restrict on-device ADB

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

Toxic max security. Not everyone has the same threat model as you, $BIGTECHCORP.

They dont care about security; only about control.

There are hundreds of millions of outdated Android devices that all Google attestation systems consider secure even though they all running Linux kernel that was never ever updated and can be rooted by anything.

Now try to install your own firmware on them without said outdated kernel... How dare you.

Re: Android may soon restrict on-device ADB

#34
This is about control, not security. As in, Google's control over your device, your experience, your features and choices. This and Google just isn't interested in supporting an open OS anymore. Maybe they think it makes them liable.

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

Re: Android may soon restrict on-device ADB

#35
post #27

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.

Many alternative AOSP-based systems work fine today and do not have the new Android Developer Verifier (wow, already rolled out to 500M+ devices [1], though still dormant).

To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick your phone, etc.

[1] https://play.google.com/store/apps/details?id=com.google.and...

Re: Android may soon restrict on-device ADB

#36

adb connecting a device to itself is just bad design and a hack. Either the capabilities should just be granted directly to the app or it should all be blocked.

Same can be said about loopback device in general. Why do you need to use networking when you are literally on the same device and can use binder/dbus and friends with native apps?

Shizuku uses Binder AFAICS[^1]. Looking deeper it seems that Shizuku does not connect to the device itself per se, but rather it has a privileged server launched manually through adb. Never used Shizuku, so can't say for sure.

[1]: https://github.com/rikkaapps/shizuku#how-does-shizuku-work

Re: Android may soon restrict on-device ADB

#37
post #21

Earlier quoted context omitted.

To iPhone users, perhaps.

I'm afraid in a few years iOS will actually (not as a joke) be the more open and customizable option

That seems rather unlikely given the the ways of the fruit factory. They don't stand to gain anything from loosening their stranglehold on their flock while they could lose substantially if someone were to open the gate and let the sheep escape. Nope, keeping them penned in is the best way to reliably fleece them.

Re: Android may soon restrict on-device ADB

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

No one's requested the config switch from A to B with a restriction that's acceptable to those seeking B. Idealism doesn't tend to offer compromises, and so Idealism tends to lose when it doesn't make a convincing case to regulators. Here's a simple and easy to implement example compromise that could be offered today:

"Changing between A and B requires a device reset."

Most people are going to flat out refuse to wipe their device for a phisher, especially since it'll log them out of everything and trigger all sorts of "new device on your account" warnings everywhere if it's done without their knowledge.

Sure, this is mildly annoying for the 1% that have good reason for A — but it's annoying once per device rather than losing A for good as is happening now. Sure, Google will deny service to A. They're doing that no matter what, either b/c they remove A or b/c they deny A, but this forces them to construct and defend a case for why users who went through the hassle of wiping their device to switch to A ought to be denied access to the app store, and that's a critically absent case in regulatory circles right now. (See also Graphene vs. the EU age check app.)

That's all it would take to protect B from A, but no one asks for it, and no one presses Google publicly for it, and so of course Google isn't doing it. No megacorp will help you walk off the Golden Path without some sort of extrinsic pressure. I see a great deal of clamor around wanting A, but absolutely none of the 'here's a mild annoyance that we came up with as a valid and safe compromise' clamor that would make them look incompetent in the public eye, provide further leverage for EU antitrust steps regarding Android itself, and give them a way to continue to protect users who need B for safety, while allowing those of us who want A to pursue it.

Perhaps other styles of compromise exist, too? As far as I can determine, no one else is thinking about this in terms of "what compromises will developers offer that continue to protect non-developers?", and so I have no other examples to offer. I'd sure love to see more ideas, more effort invested into offering serious and real compromises rather than inflexible resistance of every real safety improvement.

Re: Android may soon restrict on-device ADB

#40

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…

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?
Post reply on HN