Earlier quoted context omitted.
Sure, sometimes people get social engineered into taking money from their bank account and giving it to criminals. Should banks stop allowing withdrawals?
In Sweden the answer was yes.
[dead]
Android may soon restrict on-device ADB
361–370 of 535 posts
Re: Android may soon restrict on-device ADB
#362I 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…
"In a normal scenario, a bad actor cannot gain an ADB connection."
It depends on how you define a bad actor.
"rootless privacy tools based on Shizuku."
It's not for the security of the owner; it is for the security of the government.
Trusted execution environment applications like the EU Digital (Identity) Wallet, or whatever they will demand next to protect the children, heavily rely on the fact that users cannot mess with their devices or install unsanctioned software. We all know how badly the Intel SGX story is going.
Re: Android may soon restrict on-device ADB
#363Every time I want to connect ADB to a device, it takes me far more time than it should. Having different ports for pairing and connecting is already a pain. I wonder what new hurdles will come up once they restrict adb to wlan0, even though atm I can't see any problems for my use cases (like pushing APKs, reading logs or connecting dev tools).
Not being able to use VPNs might be a problem in corporate setups (e.g. debugging an issue in production environments).
Re: Android may soon restrict on-device ADB
#364Earlier quoted context omitted.
If the users' willingness to do stupid things is boundless, then locking down the system further isn't really of any benefit, since users will continue to venture as far as they need to, no matter the number of safety barriers they've passed. The only solution to that problem is a fully locked down device (which I hope we can all agree should not be the only option).
That's why they're going to fully locked down devices.
So, they will use other vectors, like convincing people to transfer money. Set up fake webshop. Run scams through online marketplaces, etc. The solution is not to make everything impossible. The solution is to educate people.
Re: Android may soon restrict on-device ADB
#365Call me crazy but that actually makes sense. ADB is clearly meant for one device to control another, otherwise it's just a hack to bypass sandboxes.
That would make sense if they hadn't first taken away the user's ability to control their own device directly. Some people were OK with that because users could still use this hack, but are presumably less OK with it in retrospect now that this second step finishes the job.
Re: Android may soon restrict on-device ADB
#366Re: Android may soon restrict on-device ADB
#367I 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),…
> 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 auth problems and atrocious out of date dependencies, err I mean...
Re: Android may soon restrict on-device ADB
#368I 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),…
There is a simple and highly accurate heuristic to tell if a security measure is reasonable:
Is it an open standard that anyone can permissionlessly implement?
When the answer is yes, there is a high probability that it's something reasonable, e.g. TOTP.
When the answer is no, what you will find behind the curtain is either a fool or a crook.
Re: Android may soon restrict on-device ADB
#369I 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…
In the post iPhone era, a lot of what gets sold as security features is actually just removing functionality from the device. In early days of this, I honestly think it was rooted in the famous Steve Jobs paranoia, the one that shipped without an app store and told users to use Safari, the same Steve Jobs that was said to not want certain medical devices during cancer treatment to touch him because they weren't beaut…
It's a security theater but you should at least respect that the guy was willing to die for beautifully designed devices and rid us of Adobe Flash.
Re: Android may soon restrict on-device ADB
#370Earlier quoted context omitted.
> As if you didn't need any more proof you don't own "your" devices. Can you install your own OS? If yes, you own it. And Google consistently lets you do that. It other OEMs don't then direct your outrage at them.
>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)
oookay? Hardly seems like a big deal? It would indeed be nice if the unlocked phones were set from the factory as such instead of all being the same system image as the ones that locked carriers use, sure, but hardly significant since it's not like you have to sign in or anything?
> Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)
Why are you even asking Google at all? Just use Firefox? Don't even need to root or use a custom ROM for that, even.