Comment by izacus

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.

That link is mentioned in the article. To quote it:

> Connection to localhost has also been the source of exploit where app are using that socket to adbd to escalate their privileges. What about we restrict to always only binding to wifi interface wlan0 ?

Nowhere in that text do I see a proposal to assign an additional CVE for this behaviour. Personally I think it would be unusual to assign a CVE for intended-but-potentially-harmful functionality, although I expect people have done that in the past. But, I think overall we're agreeing here.

>>I use loopback ADB daily to automate scheduling eye care display settings using settings since my OEM does not provide advanced scheduling routines.

>Which OEM do not provide this feature? This hardly quality as a legitimate usecase but rather as a shortcoming of the OEM.

I find this kind of attitude maddening. Although I assume they overlooked "advanced" because as soon as I read that, I knew this wasn't going to be something ever supported as a basic functionality. I get that many people will be fine with simple things but I hate being forced into them.

Yes, but what about allowing me to run adb commands on my phone with my consent, and especially delegating that privilege to "strangers", again, with my (one-time) consent - by which I mean authorizing apps to run with elevated privileges and/or reestablish the debugging bridge once it invariably disconnects (for other more or less legitimate security reasons)?

It's not like those threats silently turn on ADB on people's phones without their knowledge. You have to opt in to a rather obscure, hidden by default, and very fickle feature to become potentially vulnerable in the first place.

I agree with user TeMPOraL in his comment. Those who aren't trapped in tunnel-vision, know the app permissions themselves have ALOT of access to all data on your device and users give the apps these permissions. Should we say that every app is a CVE? The real reason any Google dev wants ADB gone is to close open source and lock down the OS to Google sign-ins and a proxy proprietary closed source eco-system. ADB is the master-key to rooting Android devices, getting Android shell access to /root, uploading *.apks, etc... But for the Google monopoly, it makes sense to them to close/restrict this access, then funnel all requests for it through Google's identity gateway for access. So the argument "this app can bypass OS security through ADB and is therefore a CVE" is not valid and an foolish from its /root.

The act of "allowing“ negates the “without your approval“. You see the failure in the logic here I hope.

Anything can fit into CVE.

"An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so.

"A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too.

Whether it matters or is something that should be addressed, is the depends part. Here we're talking about CVE that's at risk of trying to address a feature.

You are forgetting the most important questions of security, without which the whole discussion becomes pointless:

Who is securing what, and from who?

CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.

a lot of cves are of the type "if you leave the keys in the door, then anyone can unlock it and get in! We must destroy all doors, they are insecure!"

This is one of them

I changed the sudo settings to not require a password.

Now an application on my computer can obtain root without user interaction.

Where is my CVE?

When half that security is aimed against the user it's pretty easy to cheer for cracks in it.

Sounds like the Settings panel is a CVE, we should immediately get rid of it. And don't forget the Play Store!

So why do Google Play Services, etc. have full privileged access to a phone, including private data and phone call audio, but the user doesn't?

It is tech feudalism - you don't own anything anymore, you just get to live on the digital land of a bunch of ~trillion dollar companies.

At least, that is the goal.

IMO either everyone gets access at the user's discretion or Google has to sandbox their own GMS services as well.

Why? What other APIs should my apps (or the apps I explicitly want to authorize for this purpose) use to access my private data and my phone call audio?

So what official API call recorder app can use?

More like the credit card company can initiate automatic withdrawals from your bank account without your permission if you previously authorized the company to do autopay.