Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

471–480 of 536 posts

Re: Android may soon restrict on-device ADB

#472

Earlier quoted context omitted.

In what way are Passkeys, as implemented (not theoretical benefits), better than passwords? Better: not in a single metric but rather as a complete measure of both preventing unauthorized access to a resource and also _enabling_ authorised access to that same resource.

They're better in some ways. They don't rely on a secret with low entropy which is really brute forceable. They can't be used on a phishing site because the URL is part of the secret. Even when you authenticate to a fake site you don't give them the ability to authenticate as you until you change the secret (like you do when you give them your password) They also have 2fa built in. No need for a separate app, enterin…

That's why I mentioned "and also enabling authorised access to that same resource". Passkeys are great at preventing unauthorized access. But that comes at the expense of preventing authorised access. For example, using another device or even moving to another device. Replacing a stolen or damaged device is also nearly impossible with a reasonable quantity of Passkeys.

Re: Android may soon restrict on-device ADB

#473
post #206

Earlier quoted context omitted.

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

The EU shouldn't be regulating Google like this. The US should.

The EU absolutely should be regulating companies that operate in her jurisdiction. Google is free to pursue other markets.

Re: Android may soon restrict on-device ADB

#474
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) oookay? Hardly seems like a big deal? It would indeed be nice if the unlocked phones were set from the factory as such instead of all being the same system image as the ones that locked carriers use, sure, but hardly significant since it's not like you have to sign in or any…

> Hardly seems like a big deal?

https://news.ycombinator.com/item?id=49047638

Re: Android may soon restrict on-device ADB

#475

Earlier quoted context omitted.

Hard disagree. iPhones are some of the most secure devices available. They are much more secure than desktop computers. This is a good thing because it protects users private data. With how much personal data phones, it seems reasonable to secure them extensively. That's why I use GrapheneOS.

>iPhones are some of the most secure devices available How do you know? We're not allowed to see the source code.

Replace iPhone with Android/GrapheneOS and the argument still holds.

Re: Android may soon restrict on-device ADB

#476

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.

Android became a lost cause the second they introduced hardware remote attestation. Even if there was a way to install your own software, there's no point in doing so. You're "tampering" with the device. Fail attestation and you're untrusted. You get banned from everything. If you hack, you're ostracized from digital society. You're a second class citizen. Can't communicate. Can't bank. Can't stream. Can't play video…

> GrapheneOS is quite literally the last hope for Android

Don't they support the idea of the hardware attestation and having no root?

Re: Android may soon restrict on-device ADB

#477

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

It's just to restrict us all from using our devices in any way we want. Phone breands are already refusing to unlock bootloaders so that we can't just slap on a pirated version of their firmware and keep the updates flowing in.

Re: Android may soon restrict on-device ADB

#478

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

"Security" is just a scourge on software at this point. It means 2FA on every trivial site, being logged out every few hours for no good reason, having to fuck with settings and type "disable sandbox" to run an agent in YOLO mode which still won't work over mobile, being unable to install an unsigned extension at all in firefox (not behind a setting, literally impossible - you have to get Firefox Developer Edition),…

It's usually a way to make users pay more and regularly, but when it comes to things like extensions in firefox... I just start to think they actually think it actually improves security lol. Cuz why would you even restrict me from loading any extension I want? Nobody buys extensions, nobody pirates them.

Re: Android may soon restrict on-device ADB

#479
post #225

Earlier quoted context omitted.

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

Downside is those specific forks only work on very specific devices, when there's countless great hardware in the wild with shit software.

Lineageos works on about 300 different phones, and you can flash a GSI for partial support on others.

Re: Android may soon restrict on-device ADB

#480

Earlier quoted context omitted.

> But it helps against account sharing This is actually a feature , very common in real world, that security maximalists keep insisting is a bug.

My wife's insurance provider requires SMS 2FA, which is incredibly annoying for this reason - there's no way for me to submit my massage (or w/e) benefits even though my wife hates dealing with insurance admin and I have the login info and am authorized to do so - I have to wait until my wife is home and then get her to read off an SMS code for me.

But that's the thing: SMS can be auto-forwarded without that much effort. Definitely without rooting your phone. I don't recall if there is any built-in functionality for this, or at what granularity, but in the past I had a Tasker profile specifically meant to forward very specific SMS 2FA codes.

Now try that with a bank/vendor app. Or any other communication app. Nowadays, many don't even put the message body into the notification anymore, so you can't forward it via another channel (e.g. via SMS).

Post reply on HN