Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

221–230 of 535 posts

Re: Android may soon restrict on-device ADB

#222
post #27

Earlier 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.

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. https://en.wikipedia.org/wiki/Mozilla_Foundation#Financing

> Firefox only survives because of Google, and that's so they don't hit antitrust problems.

Yes, that is what I meant. They should be hesitant to lockdown completely and (grudgingly even) allow alternative options and/or workarounds due to legal concerns like anti-trust.

Firefox was existing before Chrome, but in this case we either need a different OS or need an android based option like Graphene/3rd party stores gain enough marketshare to trigger anti-competitive laws.

Re: Android may soon restrict on-device ADB

#224

Does anyone have any doubt left that we're headed for a future where you need a government ID to use any computing device, and only allowed to do government-approved tasks and view government-approved content? Not a rhetorical tinfoil question: Does anyone still believe there's some hope for personal freedoms?

> Does anyone still believe there's some hope for personal freedoms?

as long as such personal freedoms gives users the ability to skirt the profit motives of companies making these devices, there will always be a force to try restrict it.

The internet, as it has been, is quite an anomaly, but inevitably, power that the people have gets usurped one way or another. It's just a matter of time.

Re: Android may soon restrict on-device ADB

#225

Earlier quoted context omitted.

> 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 thei…

>What else should they have done?

Use an AOSP fork like grapheneos or lineageos. Barring that, voting with their wallets and buying a HarmonyOS phone. If for whatever reason they're doing that too, there's probably more powerful forces behind this change (eg. government mandates) that won't be helped by spamming an issue tracker.

Re: Android may soon restrict on-device ADB

#226
post #119

Earlier quoted context omitted.

It seems to require the user to: 1. Enable Developer Mode by going to an obscure settings page and tapping the build number seven times 2. Enable USB ADB debugging in the Developer Options 3. Establish an actual USB ADB session 4. Enable TCP/IP ADB debugging in the Developer Options 5. Unknowingly download a malware app from the official Play Store 6. Blindly click "Yes" on the permission prompt. In other words: this…

I think expert users on HN seriously downplay the ability and willingness of "regular users" to do very stupid things on their devices. If grandma wants that app that gives her a beautiful horse as a lock screen image, she will follow every one of those six steps that the malware HorseLockScreen app developer presents to her. She will tap a button that has a skull and crossbones icon, that says "tapping this will dra…

If the users' willingness to do stupid things is boundless, then locking down the system further isn't really of any benefit, since users will continue to venture as far as they need to, no matter the number of safety barriers they've passed. The only solution to that problem is a fully locked down device (which I hope we can all agree should not be the only option).

Re: Android may soon restrict on-device ADB

#227

Earlier quoted context omitted.

This. I'm a developer, I've published Android apps, & I've still managed to lose access to a device that had dev settings enabled purely because remote adb enablement is a (extremely fiddly) toggle that happened to be off on the device at the time the screen broke. Having these two enabled simultaneously is such a rare case in the wild as to be entirely negligible as a vector.

Sometimes attacks happen from users being instructed to enable settings in order to achieve something regardless of whether you’d expect them to have a reason to use the setting

Sometimes people fall down the stairs in their own homes. That doesn't mean the government should mandate everybody to wear helmets at home does it?

A measure needs to be in proportion to the actual risk it seeks to mitigate.

Re: Android may soon restrict on-device ADB

#228
post #220
post #207

Earlier quoted context omitted.

>Can you install your own OS? If yes, you own it. Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0). Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1) And without developers pouring tens of thousands of work hours into making projects such as GrapheneOS viable…

>Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0). What's the problem here? Are you roaming all the time and that imposes a unreasonable cost on you? You want to stay totally off the grid and using VPN/tor isn't enough? >Also, will Google let me browse the web with "my own OS" without their proprietary services installed on…

>What's the problem here? Are you roaming all the time and that imposes a unreasonable cost on you? You want to stay totally off the grid and using VPN/tor isn't enough?

It depends on a remote endpoint that can go down at any point, and depends on the company's policies present and future. It is functionally asking for permission to another party to unlock it, and that would not fall under the umbrella of ownership through being able to install "my own OS" on it, at least for me. And a simple OTA update is all it takes to add multiple verification steps to it, such as providing your ID/using your verified Google account, or just take it out.

Re: Android may soon restrict on-device ADB

#229

When Google first announced sideloading restrictions, somebody told “but we have ADB”, and who disagreed with them was criticized harshly. Now, I’m waiting for a workaround to enable ADB, so sideloading can be handled now, too. Android is not more open that iOS for a very long time now. The trend will continue. Again, this is not a technical problem (the mindset of Google), so technological solutions won’t help.

[flagged]

Re: Android may soon restrict on-device ADB

#230
post #22

Earlier quoted context omitted.

Sometimes it's truly useful featutes, but having no toggle in settings making it terrible. Like iPhone idle auto-reboot every 3 days. After a while they added "Allow Idle Reboot" flag but it only accessible via MDM and require device wipe and for switching it to be a managed device.

What would that be useful for anyway? Sounds like something aimed to prevent people from reusing their old/secondary devices for IoT.

> What would that be useful for anyway?

It puts iPhone in cold boot state if for instance police or any agency confiscate it from you. Better tamper proofing.

Post reply on HN