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

441–450 of 536 posts

Re: Android may soon restrict on-device ADB

#441

Post by Gormo »

zaptheimpaler wrote: post #325
microtonal wrote: post #30

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

Security is also increasingly being used as a pretext for usurpation of end-user control over their own devices, which the situation in this very article seems to be a case of.

The industry, and society at large, are today overrun with fiduciaries who've convinced themselves that they are the principals.

Re: Android may soon restrict on-device ADB

#442

Post by kelnos »

atty wrote: post #186
wahnfrieden wrote: post #185

Earlier quoted context omitted.

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

Sure, sometimes people get social engineered into taking money from their bank account and giving it to criminals. Should banks stop allowing withdrawals?

Your argument is of course absurd, but in general, I think it is a reasonable position to take. The grandmother of someone I know was social engineered into installing a malicious app and changing developer settings on a phone, and lost quite a lot of money. The grandson is at this point absolutely in favor of completely removing the things that allowed that attack vector (I believe in this case it's "merely" the ability to install apps from unknown sources).

I disagree with him. While yes, it's awful and tragic that happened to his grandmother, I think it's incredibly dangerous to allow companies to lock down our devices like that. And I think from a practical perspective, we're never going to be able to eliminate these attack vectors fully; if the grandmother was going to go along with this scammer in this particular way, there would always be some vector that she would fall for, no matter how hard we might try to lock them down.

But I can't bring myself to say his stance is unreasonable. He's dealing with a devastated family member whose retirement is now ruined, and he has to help her pick up the pieces. Not a good position to be in.

Re: Android may soon restrict on-device ADB

#443

Post by Gormo »

TeMPOraL wrote: post #396
hnlmorg wrote: post #384

Earlier quoted context omitted.

IT has always been a spectrum with security at one end and convenience at the other. There is no recent trend that’s changed that. That’s just how life works.

Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible. Also, the original sin: framing it as "security" vs. "convenience". It's not. The other end of the spectrum is utility - as in, maximally secure computing device is an inert rock. More security means less utility - reduced functionality, constrained capability, reasonable use cases no longe…

> It means more electricity, more compute, more money spent.

And it means more middlemen mediating people's access to their own tools.

Re: Android may soon restrict on-device ADB

#444

Post by Gormo »

KerrAvon wrote: post #386
hnlmorg wrote: post #384

Earlier quoted context omitted.

IT has always been a spectrum with security at one end and convenience at the other. There is no recent trend that’s changed that. That’s just how life works.

"Better things aren't possible" is a terrible outlook. There have been real improvements in this space, such as passkeys, and recognition that some of this stuff, like frequent password changes, is counterproductive.

> There have been real improvements in this space, such as passkeys

Passkeys are not an improvement. The way they're being implemented entrenches middlemen into auth flows in a way that reduces users' security in a broader sense, while being just as susceptible to compromise as any other form of credential.

Re: Android may soon restrict on-device ADB

#445

Post by root9876 »

mnahkies wrote: post #71
peheje wrote: 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 many banks in the UK no longer offer a web portal or physical branches. I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly. (I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)

Fun fact that is in Russia major banks are sanctioned and had their apps removed from App Store and Google Play so banks forced to keep mobile optimized and fully featured web portals for iOS users.

Re: Android may soon restrict on-device ADB

#446

Post by kelnos »

JoshTriplett wrote: post #397
ordu wrote: post #263

Earlier quoted context omitted.

I think that these victims are paid by the likes of Google to create a precedent. It is unbelievable stupid scheme to fall to.

While I certainly think we should not be taking features away from people just because there exist people who will let themselves be social-engineered through arbitrary hoops, don't go creating wild conspiracy theories to explain something that supports much simpler explanations instead. It's easy enough to imagine that Google is trying to fix something they see as a problem, and not caring about the developer case r…

I think there's very plausible a middle ground too: Google does want to remove these features for business reasons, and is using the real problem of social engineering as an excuse.

Re: Android may soon restrict on-device ADB

#447

Post by Gormo »

therein wrote: post #359
zaptheimpaler wrote: post #325

Earlier quoted context omitted.

"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),…

It is all so frustrating. Reminds me of what Ubiquiti tried to pull a few weeks ago. They wanted to force everyone to their Cloud UI and login instead of the local interfaces so they reduced the local session lifetime to something insane like 20 minutes while lying to our faces and saying it is for security, and kept the session lifetime longer on their cloud panels. They made sure to exclude this from their changelo…

That's sad news. I've been a fan of Ubiquiti for a long time, and the main selling point has been that they're fully self-managed on-prem infrastructure, with cloud services being an optional afterthought. Seeing them succumb to this disease of using security as a pretext to strongarm their customers is very disheartening.

I had another vendor try to use this argument with us just last week, and I had to vigorously remind them that they were not hired as a security contractor, and that our usage of their product was required to conform to our security policies, not theirs.

Re: Android may soon restrict on-device ADB

#448

Post by Marsymars »

TeMPOraL wrote: post #391
jck86 wrote: post #367

Earlier quoted context omitted.

> 2FA on every trivial site But it helps against account sharing, err I mean they make database leaks irrelevant except for private info of the customer, err I mean that we can now send more mail to the customer about new AI features without risking they think it is phishing, err I mean this is the easiest measure for the auditor findings so since we implemented this we don't need to fix all the crappy internal api a…

> But it helps against account sharing This is actually a feature , very common in real world, that security maximalists keep insisting is a bug.

My wife's insurance provider requires SMS 2FA, which is incredibly annoying for this reason - there's no way for me to submit my massage (or w/e) benefits even though my wife hates dealing with insurance admin and I have the login info and am authorized to do so - I have to wait until my wife is home and then get her to read off an SMS code for me.

Re: Android may soon restrict on-device ADB

#449

Post by Marsymars »

dotancohen wrote: post #432
KerrAvon wrote: post #386

Earlier quoted context omitted.

"Better things aren't possible" is a terrible outlook. There have been real improvements in this space, such as passkeys, and recognition that some of this stuff, like frequent password changes, is counterproductive.

In what way are Passkeys, as implemented (not theoretical benefits), better than passwords? Better: not in a single metric but rather as a complete measure of both preventing unauthorized access to a resource and also _enabling_ authorised access to that same resource.

They're better for both parties with the subset of providers who require one of either SMS 2FA or passkeys.

Re: Android may soon restrict on-device ADB

#450

Post by gruez »

root9876 wrote: post #440
gruez wrote: post #343

Earlier quoted context omitted.

>Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied? Just use firewall VPN apps + VPN lockdown mode (ie. "block connections without VPN"). >So does a Phonograph from 1877, right? I think it's fair to factor in what feature was lost because wireless-adb-on-localhost was removed. If some critical accessibility feature was lost, that would…

It's impossible to use both these firewall VPN apps and real VPN at the same time.

Actually for any VPN apps that support per-app split tunneling, excluding a given app while vpn lockdown is enabled causes the app to be blocked. So you can have both.
Post reply on HN