3 ms·
> Separately, a number of people here are attempting to argue that the availability of On-Device ADB should be regarded as a "CVE" in and of itself. Google does
by dns_snek 3mo ago
> Separately, a number of people here are attempting to argue that the availability of On-Device ADB should be regarded as a "CVE" in and of itself. Google does not appear to share that view.
This was proposed by a Google employee: https://issuetracker.google.com/issues/526109803#comment3 https://issuetracker.google.com/issues/526109803#comment3
- gnfargbl 3mo agoThat 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.
- dns_snek 3mo agoYeah, they didn't claim that it's a CVE, just behavior that they wanted to change. Miscommunication then.
- duskdozer 3mo ago>>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.