Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

291–300 of 535 posts

Re: Android may soon restrict on-device ADB

#291
post #46

Earlier quoted context omitted.

The bug literally describes how they're avoiding OS security restictions by going through the debug port. 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 even if another app did it). But sure, Google evil.

There's a vulnerability in my bike - when I push my left handlebar hard forward when riding down a road, I can crash into a pillar. I think a possibility of knowingly pushing the handlebar should be removed from me, just in case. After all I could do it. And while we're at it I just realised my car has a similar vulnerability, but triggered by a slightly different mechanism, but the effect is exactly the same, I can…

I mean, you made a good metaphorical case for controlled handlebar slop/headset resistance in bicycles/motorcycles. Which are things that exist to mitigate crashes from oversteering on both of those vehicles!

Re: Android may soon restrict on-device ADB

#292

Earlier quoted context omitted.

> I'm in with DNB and Nordea and they both have functioning netbanks. And both are banks I'd never want to associate with. I would have used Sbanken before the DNB buyout (and I even did for a bit!), but now that's of the table too. There are a few more options, but many are just worse if you look at their fees and interest rates. I've been very happy with Bulder. The only thing they're missing is a web portal. The f…

I appreciate the info. Re: the banks I'm with, I have no choice. I'm an immigrant and most banks refused to give me an account when I moved here. Or ghosted me during the months long process. These are the banks that let me live here, and actually gave me an account and bank id. It's the only real choice I have until I get citizenship.

If you're stuck with them, that's understandable.

There's no reason the banks should be dicks about it, but they often are in cases like yours. All the accounts I've opened in recent times have just been a matter of logging in with BankID and going through the form and selecting 'no' 10 times. Once you've got BankID and can go through the automated flow, there shouldn't really ever be any issues.

This is why it bothers me greatly that BankID is still controlled by the banks, since they can just decide that someone like you shouldn't get it. It should be government issued and issued to everyone, on the same level as an ID card or a passport.

Re: Android may soon restrict on-device ADB

#293

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

[dead]

Re: Android may soon restrict on-device ADB

#294

It's frankly amazing how many Google developers will associate their real identities and contact info with such hostility, believing they're invincible. Perhaps they should be subjected to the full force of the First Amendment.

I'm more curious to see how the second ammendment could factor into this.

Re: Android may soon restrict on-device ADB

#295

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

Then maybe the best course of action is Google adding a warning before enabling certain settings that help normies avoid these attacks.

Along the lines of "Are you being asked to do this by someone else? Be cautious, as your device could become compromised."

Re: Android may soon restrict on-device ADB

#296
post #276

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

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

Which is a federal sales tax against the citizens of the United States countries abroad do not pay no matter how many times taco lies.

Re: Android may soon restrict on-device ADB

#298

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.

> Again, this is not a technical problem (the mindset of Google)

This is not even Google's mindset, the control strings of this mindset stretch far beyond its management and board of directors.

That's the OBEY from the timeless Carpenter's classic.

Re: Android may soon restrict on-device ADB

#299
post #280
post #241

Earlier quoted context omitted.

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

> All of these can be done with a computer.

Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied? I see no persistence. And if I'm forced to install some crappy app on-the-go, the solution you propose is to always carry a computer with me, right?

> A second phone does the same thing.

So does a Phonograph from 1877, right?

> Whether it's a "hack" is orthogonal to whether you control the device or not.

I didn't object to it being called a hack, I just pointed out how evil and malicious that privilege escalation on my own device is. Google must block it immediately, it endangers the mankind.

Re: Android may soon restrict on-device ADB

#300

Earlier quoted context omitted.

There's a vulnerability in my bike - when I push my left handlebar hard forward when riding down a road, I can crash into a pillar. I think a possibility of knowingly pushing the handlebar should be removed from me, just in case. After all I could do it. And while we're at it I just realised my car has a similar vulnerability, but triggered by a slightly different mechanism, but the effect is exactly the same, I can…

I mean, you made a good metaphorical case for controlled handlebar slop/headset resistance in bicycles/motorcycles. Which are things that exist to mitigate crashes from oversteering on both of those vehicles!

In the bikes they're mostly aimed at preventing tank slappers/death wobble. I have a dampener on my bike myself, but it still allows me to countersteer as harsh/rapidly as I want, and that means crashing into a railing or a cliff wall if I overshoot.

No technology prevents the crash, they just lower the chance of it happening accidentally (like, say, ABS or DCT). I can remove almost all of the guardrails on my bike choosing more aggressive riding mode.

Countermeasures to the accidentally allowing a malware to "do something" already exist and were described in the original article. The comment I was responding to wants a removal of the whole capability, hence my cases.

Post reply on HN