Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.

▲

TeMPOraL 4 hours ago | parent [-]

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.

▲

dns_snek 4 hours ago | parent [-]

They're 3 separate issues. There's a genuine vulnerability (CVE) which has been fixed, there's a follow-up proposal to allow the user to choose which interfaces to bind to, and there's another proposal to disallow ADB over loopback which would cut you off from using ADB on-device.

Your problem is with the last one which has nothing to do with the CVE itself.

	▲	TeMPOraL 3 hours ago \| parent [-]
		Correct. That, and security maximalism displayed in 3. and some comments in the HN thread.