Google is going the Apple route. When will we get the year of the Linux Phone?
I use postmarketOS btw...
Android may soon restrict on-device ADB
191–200 of 535 posts
Re: Android may soon restrict on-device ADB
#192If they stop sideloading and adb why should I even stay with Android?
Re: Android may soon restrict on-device ADB
#193> Spamming the thread will only cause Google developers to lock the issue, ignore valuable community feedback, or stop sharing public updates about this change entirely. So nothing would change (they can also lock away your "valuable community feedback" because what bothers them is the criticism itself), thus feel free to express your approval
> because what bothers them is the criticism itself I think there's a difference between criticism of a policy and being brigaded by a reddit mob.
Google pushes a new feature to Android where phones wake up at 2:22 AM every night to play a blood-curdling scream at maximum volume, regardless of settings. An issue is created and gets assigned, into which Google employees regularly butt in to explain the feature exists to keep users safe from night break-ins. Nothing changes. People have to start modifying their lives around this problem—most have to shut off their phones during the night, many had to buy a separate alarm clock—and masses of disappointed customers eventually make their way to the bug tracker to voice their concern. The issue gets locked as "too heated".
Apple has had this feature for three years on iOS. What else should they have done?
Re: Android may soon restrict on-device ADB
#194I 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…
> This attack vector requires both that the user enabled developer settings and that they have remote adb enabled. Not just that. A non-development Android build will also prompt the user when a connection is made to authorize the client's key. This once again isn't about security of users, this is about security of the company's interests.
Google just got hit by yet another record antitrust fine by the EU [1]. But as long as they see these fines as cost of doing business, nothing will change. Especially if it always takes almost a decade to push this through the judicial system. Their net income last year alone was $130 Billion.
[1] https://www.reuters.com/world/eu-top-court-dismisses-google-...
Re: Android may soon restrict on-device ADB
#195Earlier quoted context omitted.
It can and will most probably turn to indefinite time depending on the answer to the question "will we have a viable alternative to jump ship before that happens ?". We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.
> will we have a viable alternative to jump ship before that happens ? Here is a better question: "Is the EU going to stop this?"
Why would the EU stop it?
Re: Android may soon restrict on-device ADB
#196Earlier quoted context omitted.
The original issue is proposing letting the user assign the debug service to a specific interface, one of which would presumably be loopback. This article is about the proposal from a developer that it should only ever be assigned to wlan0, which would break a lot of apps. Letting applications bypass permissions with this feature is the exact usecase they don't want to lose. If anything, I don't see them being agains…
It would break exactly 0 apps because none of the apps should be using this API to access your private data and phone call audio.
So what official API call recorder app can use?
Re: Android may soon restrict on-device ADB
#197IIRC Google never originally intended for Wireless ADB to be used by the very same device, as it skirts the intended app permission model even if it takes many steps to opt in.
Re: Android may soon restrict on-device ADB
#198Of course this was bound to happen, next you're telling me people will be surprised that the 24 hour limit for side loading will turn into some indefinite time period.
It can and will most probably turn to indefinite time depending on the answer to the question "will we have a viable alternative to jump ship before that happens ?". We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.
I get the analogy but it's a false one. Google covers about 90% of Mozilla's funding. Firefox only survives because of Google, and that's so they don't hit antitrust problems.
Re: Android may soon restrict on-device ADB
#199Earlier quoted context omitted.
Wait till you hear that your OEM can remotely rollout full OS updates with full access to all your data and drivers... carrying Google software and most of it Google code.
Snarks do not lead to productive discussions. You also know that there is has always been an implicit social contract between users and vendors. The vendor rolls out updates as part of the service attached to the device (typically included in the purchase price) and that the vendor does not abuse the update mechanism to make things worse for the user. If vendors use updates to restrict functionality that the user had…
>implicit social contract
Sounds worthless (in court).
Re: Android may soon restrict on-device ADB
#200I 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…
The bug literally describes how they're avoiding OS security restictions by going through the debug port. This is a CVE by any definition and you'd be screaming your head off if any other OS would allow this kind of permission bypass (or even if another app did it). But sure, Google evil.
There's a vulnerability in my bike - when I push my left handlebar hard forward when riding down a road, I can crash into a pillar.
I think a possibility of knowingly pushing the handlebar should be removed from me, just in case. After all I could do it.
And while we're at it I just realised my car has a similar vulnerability, but triggered by a slightly different mechanism, but the effect is exactly the same, I can crash into a pillar.
Edit: oops, I just discovered that if I have a banking app installed on my phone, then tap my screen in the specific places, enter several numbers, including the number I receive in text, suddenly I lose all the money.
That's staggering!