Earlier quoted context omitted.
Technically the security works, just for their threat model. An exploit would need root and root means you likely cannot pass attestation AFAIK. The fact that this same exploiter can download all your contacts photos and texts is immaterial to, say, Disney, who want attestation only to prevent ripping of their content.
Security, but not for you, is no security.
Android may soon restrict on-device ADB
321–330 of 535 posts
Re: Android may soon restrict on-device ADB
#322What I find most annoying aspect of all software from 2010s onwards is this stupid discourse and associated results: - some people want A, or A might even be already in use - A is problematic for $MODERATE_OR_MILD_REASON - B is introduced and made default - a config switch between A and B is never considered So, so tiring. If I want to bind ADB to localhost, _let me_. It's my device and my problem, ffs.
Google doesn't want you to be able to skip YouTube ads. It's as simple as that.
Re: Android may soon restrict on-device ADB
#323Earlier quoted context omitted.
The implication in the blog post that Google developers somehow “overlooked” or “misunderstood” important use cases here, and if only they were informed about them they would reconsider, is frankly insulting.
Every single time any story has the words "Google developers" in it, they're behaving like arrogant, disconnected, anti-consumer jerks. From constant GCP breakage, to not acknowledging obvious Android bugs, to intentionally braking Chrome. It's a stark contrast to behind the scenes interactions with them.
Most of the users who saw the post on reddit didn't even open the blog post anyways, according to analytics.
Re: Android may soon restrict on-device ADB
#324Earlier quoted context omitted.
Google doesn't want you to be able to skip YouTube ads. It's as simple as that.
More specifically apps and users have equal agency in the android security model. Which comes down to the fact that if you don't own the app you can't control its experience. This feels grounded to me. Push for more open source apps where you retain control and ownership.
Re: Android may soon restrict on-device ADB
#325I 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…
When is this insanity going to stop? I really think the IT security industry ought to be ashamed of itself. Security has become a totalizing value that trumps every other value - convenience, user-friendliness, privacy, hackability, openness, just anything at all in the name of MORE SECURITY.
Re: Android may soon restrict on-device ADB
#326I've been seeing this specifically with ID / business verification requirements where they just have some innocent (or sometimes complicit) third party grant them access to verasign 'verified' trust signing keys which actually makes them way more trusted than they were ever before often making anti-malware applications way less strict about blocking it which in turn buys them just enough time to compromise the system and disable said anti-malware applications. The problem here is that anti-malware applications try to be seemless and are effectively in a giant race condition to terminate the application, more recently microsoft anti malware service will now block program execution until it validates that it is safe. Although it is not something other companies do as making the device feel sluggish is something they avoid at all costs (looking at you bitdefender).
Re: Android may soon restrict on-device ADB
#327Earlier quoted context omitted.
More specifically apps and users have equal agency in the android security model. Which comes down to the fact that if you don't own the app you can't control its experience. This feels grounded to me. Push for more open source apps where you retain control and ownership.
No, I bought the device, I should be able to do whatever I want with it.
You are free to install a custom OS which provides you the security model you desire. You have choices.
Re: Android may soon restrict on-device ADB
#328Earlier quoted context omitted.
the question isn't whether you still have a reason to choose android - the question is what alternative do you have but android (or iOS).
If my phone is going to be locked down anyway, I'm choosing the platform that at least pairs with my AirPods properly and doesn't get me weird looks at social events. Google is really stretching their goodwill with this one. The ability to sideload and debug my phone is the only marginal benefit to these janky Java relics. If that's gone, no reason not to switch to a wholely better platform.
Re: Android may soon restrict on-device ADB
#329> Scenario 3: A Developer Using ADB over TCP/IP - You install a malicious application. - You enable USB debugging, starting ADBD. - You connect via USB ADB to enable TCP/IP, then disconnect the USB cable. - ADBD continues running and listens on all network interfaces. - The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected.…
Every ADB connection has some kind of certificate / key that is saved locally. This means that a new application would have a different certificate. That certificate is shown in the yes/no prompt.
> Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?
You can tell android to remember that certificate and allow the connection next time. There is a bug that make it not work on certains specific version of Android 12 I think, but outside of that, it always works.
Re: Android may soon restrict on-device ADB
#330I 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),…
See Pournelle's Iron Law of Bureaucracy.