Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

401–410 of 536 posts

Re: Android may soon restrict on-device ADB

#401
post #227

Earlier quoted context omitted.

Sometimes people fall down the stairs in their own homes. That doesn't mean the government should mandate everybody to wear helmets at home does it? A measure needs to be in proportion to the actual risk it seeks to mitigate.

I am not in favour of limiting adb access, but this does beg the question, how many accidents would it take to cause enough overfull ERs to make the requirement of staircase railings a thing, in order to make sure there are doctors to treat other things than broken bones. uh happy Saturday.

In many jurisdictions, staircase handrails are required[1] in residential homes.

And even when they are required, it's up to the person using the stairs to determine whether they wish to elect to use the handrail or not.

[1]: IRC R311.7.8

Re: Android may soon restrict on-device ADB

#402
post #345

Earlier quoted context omitted.

I have bad news for you if you think GrapheneOS isn't going to accept this patch from upstream if it lands.

That's a non-issue because you can build (or patch+resign) grapheneos yourself.

But if you do, it fails attestation which turns the phone into a paperweight.

Re: Android may soon restrict on-device ADB

#403

Google is going the Apple route. When will we get the year of the Linux Phone?

For the longest time the free software foundation (well Stillman) were against all mobile phones because of their ability to track people. In the last year they have finally admitted that they were not going to win that battle and have gone head first into trying to build a fully open software stack.

Not saying it will be good or arrive anywhere in the next 5 years but they are very persistent and that tends to work in their favour.

Re: Android may soon restrict on-device ADB

#404
As far as I can tell, this is a big overreaction to a misunderstanding.

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.

Re: Android may soon restrict on-device ADB

#406

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.

Android became a lost cause the second they introduced hardware remote attestation.

Even if there was a way to install your own software, there's no point in doing so. You're "tampering" with the device. Fail attestation and you're untrusted. You get banned from everything. If you hack, you're ostracized from digital society. You're a second class citizen. Can't communicate. Can't bank. Can't stream. Can't play video games. Can't do pretty much anything.

That's the future of Android. GrapheneOS is quite literally the last hope for Android, and only because by some miracle there are companies out there who started trusting Graphene's attestation keys. If that hope ever dies then we might as well buy iPhones.

Re: Android may soon restrict on-device ADB

#407

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…

"Security" is just a scourge on software at this point. It means 2FA on every trivial site, being logged out every few hours for no good reason, having to fuck with settings and type "disable sandbox" to run an agent in YOLO mode which still won't work over mobile, being unable to install an unsigned extension at all in firefox (not behind a setting, literally impossible - you have to get Firefox Developer Edition),…

All this boils down to governments wanting security from their citizens and corporations wanting security from their customers. It's not going to stop, ever.

Re: Android may soon restrict on-device ADB

#408
post #341

Earlier quoted context omitted.

its ridiculous how many people will ignore the warnings and relay the security challenge/solution to the attacker. "we will never ask for this over the phone" takes second place to: "we will send/save you money/time if you make it convenient" dress it up to taste like developer needs, and you can hook the newbies.

> "we will never ask for this over the phone" takes second place to: Doesn't help that the banks then do, in fact, call you, and ask for this over the phone.

those banks that do that are grooming customers for failure, they create a workflow that is close to an attack.

in my region AT&T has a very explicit statement not to reveal MFA codes to anyone who asks, is not part of thier system to do that.

there is 1 bank in my area that does voice call relay over the phone, the others keep it 10 fingers relayed from phone to authentication form.

guess who has the most problems with account compromise, and fraud claims? yes, that one bank. it has a phishing vector in its system.

Re: Android may soon restrict on-device ADB

#409

As far as I can tell, this is a big overreaction to a misunderstanding. 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…

Thanks for clarifying, if your read is correct and they're just putting more control in the user's hand then this isn't an issue at all

Re: Android may soon restrict on-device ADB

#410
post #227

Earlier quoted context omitted.

Sometimes people fall down the stairs in their own homes. That doesn't mean the government should mandate everybody to wear helmets at home does it? A measure needs to be in proportion to the actual risk it seeks to mitigate.

I am not in favour of limiting adb access, but this does beg the question, how many accidents would it take to cause enough overfull ERs to make the requirement of staircase railings a thing, in order to make sure there are doctors to treat other things than broken bones. uh happy Saturday.

Well in my book it is a cost vs benefit question. Handrails are not expensive in comparison to a medical procedure, nor are they particularly hindering in the daily use of the stairs. In fact, quite the opposite: anybody who uses stairs without handrails may find themselves temporarily disabled, e.g. if a circuit breaker tripped and you have to walk down the stairs in the dark.

That means, handrails cost little and have nearly no downsides. Which is why I used helmets as a metaphor. The proposed restrictions has a lot of downsides to deal with a mostly theoretical risk.

Post reply on HN