Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

Post reply on HN
Print view View original

271–280 of 535 posts

Re: Android may soon restrict on-device ADB

#271

Post by DigiEggz »

ryandrake wrote: post #209
crote wrote: 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…

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 dra…

This gave me a hearty laugh not only due to the idea, but because that's been my near exact experience with helping my family.

Re: Android may soon restrict on-device ADB

#272

Post by fsflover »

devsda wrote: post #27
satvikpendem wrote: post #8

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.

> "will we have a viable alternative to jump ship before that happens ?"

GNU/Linux phones already exist. Sent from my Librem 5.

Re: Android may soon restrict on-device ADB

#273

Post by gruez »

0x_rs wrote: post #251
gruez wrote: post #231

Earlier quoted context omitted.

Practically speaking none of what you brought up are actually issues because once the phone connects to the internet once, it's unlocked forever, including after relocks/flashing. It's like saying you don't "own" the stuff you bought on bandcamp, because there's a split second between when you bought the song and when you could download it, therefore "It depends on a remote endpoint that can go down at any point, and…

I don't think the bandcamp analogy applies. I may purchase a device with the intent of eventually unlocking the bootloader, but not doing so immediately for whatever reason, such as it still being supported by official updates, or the nth feature not being yet removed. Then the possibility of the option being taken away before you've exercised it remains.

1. It's unclear whether the online check is done when you tap the oem unlocking option, or it's done asynchronously in the background. If it's the latter, then it doesn't really matter because it'll get unlocked anyways.

2. There's no real disadvantage to leaving your bootloader in "locked (unlockable)"[1] state, because you can continue using stock rom and avb is enforced, but you can unlock it at any point using fastboot.

3. The Bandcamp analogy still applies because it offers streaming too (ie. web player), which means you could be happily streaming (ie. not downloading) and then one day they shut down, denying you access to all your music.

[1] https://i.ytimg.com/vi/rh6JxG0xE2k/maxresdefault.jpg

Re: Android may soon restrict on-device ADB

#274

Post by echelon »

trollbridge wrote: post #244
oblio wrote: post #206

Earlier quoted context omitted.

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

It was the lamest excuse ever.

Something like, "I'm worried about impairing Google's ability to compete in AI" or some nonsense. (Paraphrasing here.)

Looks like all it takes to compete in AI is to issue stock or get a bunch of investors. I don't see how Google would struggle with that. It's completely orthogonal to antitrust enforcement.

Re: Android may soon restrict on-device ADB

#275

Post by infamia »

gruez wrote: post #220
0x_rs wrote: post #207

Earlier quoted context omitted.

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

>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). What's the problem here? Are you roaming all the time and that imposes a unreasonable cost on you? You want to stay totally off the grid and using VPN/tor isn't enough? >Also, will Google let me browse the web with "my own OS" without their proprietary services installed on…

> Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.

Your example is about one developer's decision, which is not really what we're talking about. The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store? We're talking about restrictions laid down by the OS developer and for iding all applications outside of their crappy walled garden, which is very different. Also, you don't actually think Google is going to stop there do you? They will certainly turn it off one day of they think they can get away with it, because it is in their financial self-interests to do so.

Re: Android may soon restrict on-device ADB

#276

Post by ciefa »

sigmoid10 wrote: post #194
m132 wrote: 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-...

Eh, that is if they pay. Trump already made threats for tariffs in regards to those fines.

Re: Android may soon restrict on-device ADB

#278

Post by 3xpltr3 »

dns_snek wrote: post #90
TeMPOraL wrote: post #48

Earlier quoted context omitted.

> This is a CVE by any definition and you'd be screaming your head off if any other OS would allow this kind of permission bypass. Or perhaps they wouldn't? CVEs aren't holy scripture, and "security" isn't the most important consideration in computing. This theatre has gone too far IMO.

Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.

I agree with user TeMPOraL in his comment. Those who aren't trapped in tunnel-vision, know the app permissions themselves have ALOT of access to all data on your device and users give the apps these permissions. Should we say that every app is a CVE? The real reason any Google dev wants ADB gone is to close open source and lock down the OS to Google sign-ins and a proxy proprietary closed source eco-system. ADB is the master-key to rooting Android devices, getting Android shell access to /root, uploading *.apks, etc... But for the Google monopoly, it makes sense to them to close/restrict this access, then funnel all requests for it through Google's identity gateway for access. So the argument "this app can bypass OS security through ADB and is therefore a CVE" is not valid and an foolish from its /root.

Re: Android may soon restrict on-device ADB

#279

Post by arend321 »

Android Wireless debugging is already a major pita to work with. Requires a wifi connection to even work, so I need to carry a mobile wifi router with me, instead of having it bound to my secure WireGuard connection. Next it assigns a random port number every time the wifi connection is interrupted, or when it considers now is a good time to reset the port number. It should be possible to set a stable port and and have it available, perhaps behind a few awkward UI/adb toggles.

Re: Android may soon restrict on-device ADB

#280

Post by gruez »

zb3 wrote: post #241
gruez wrote: post #229

Earlier quoted context omitted.

[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, den…

>like uninstalling bloatware, denying apps internet access

All of these can be done with a computer.

>recording calls (legally)..

A second phone does the same thing.

>Hack for "escalating privileges" on my own device so I can do nefarious actions

Whether it's a "hack" is orthogonal to whether you control the device or not. I don't think anyone disputes that you "own" your linux PC, but using the well known `docker run --privileged ...`[1] method to get root on your machine is still a hack.

[1] random result: https://github.com/Volodishlav/Docker-Privilege-Escalation

Post reply on HN