Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

241–250 of 535 posts

Re: Android may soon restrict on-device ADB

#241
post #229

When Google first announced sideloading restrictions, somebody told “but we have ADB”, and who disagreed with them was criticized harshly. 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.

[flagged]

> which is the intended use

"Intended use" (as understood by Google) for my smartphone is apparently providing them with data, consuming their advertisements and overpaying for apps that display ads and where you need in-app purchases to unlock basic functionality.

> not as a hack for escalating privileges

Hack for "escalating privileges" on my own device so I can do nefarious actions like uninstalling bloatware, denying apps internet access, recording calls (legally).. how could that be?

Re: Android may soon restrict on-device ADB

#242

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…

It seems to me a lot of Google lately is to block things they don't like using ways that only look like side effects.

The introduction of Manifest V3 API in Chrome for extensions, and disabling Manifest V2 for security reasons. It just so happened that ad blockers were made incompatible with the Manifest V3 API. It's a little blatant considering this came right around the time that YouTube began showing warning messages to users with ad blockers...

Requiring developers to verify their apps via Google Play Developer Console and blocking any unverified APK installations. This is done in such a way that it just so happens to squash F-Droid and most FOSS apps for most people, and blocks any serious competition to Google Play or any apps they don't like.

Of course, there's all this talk about preventing malware, but it is a fact that if you download any random ringtone or PDF app on Google Play it's going to come with probably 25 trackers and send your data to every jurisdiction in the world, and many apps even fail to declare any of this via Google Play data safety or privacy policy. Let's not forget that spyware is a form of malware. Take a look at the leaderboard :) https://reports.exodus-privacy.eu.org/en/reports/list/?filte...

In my opinion, this would probably be an indication that maybe Google controls too much technology and that they may need to be broken up to ensure fair competition. For Christ's sake they almost broke up Microsoft not that long ago for shipping a browser with their operating system, and now Google is blatantly controlling the operating system, the platform and app store, the ecosystem, the browser, the ad network, and abusing their power over it however they can.

Re: Android may soon restrict on-device ADB

#243

Earlier quoted context omitted.

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

>>I use loopback ADB daily to automate scheduling eye care display settings using settings since my OEM does not provide advanced scheduling routines.

>Which OEM do not provide this feature? This hardly quality as a legitimate usecase but rather as a shortcoming of the OEM.

I find this kind of attitude maddening. Although I assume they overlooked "advanced" because as soon as I read that, I knew this wasn't going to be something ever supported as a basic functionality. I get that many people will be fine with simple things but I hate being forced into them.

Re: Android may soon restrict on-device ADB

#244
post #206

Earlier quoted context omitted.

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.

The DOJ brought an antitrust case against Google… and won.

Then the judge pretty much decided “no consequences”.

Re: Android may soon restrict on-device ADB

#250
post #95
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.

I use my bank's website on my phone and desktop.
Post reply on HN