Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

Post reply on HN
Print view View original

521–530 of 535 posts

Re: Android may soon restrict on-device ADB

#521

Post by wolvoleo »

dotancohen wrote: post #500
wolvoleo wrote: post #492

Earlier quoted context omitted.

Well that's why they can sync between devices. I don't really see the problem. Even if you don't like to rely on big tech (google/apple), I don't either, there are many options now for full FOSS implementations like bitwarden and KeepassXC. If you use a yubikey as a passkey then yes, that's not a great option also because most services don't allow you to enroll more than one passkey. But with bitwarden that doesn't m…

KeepassXC now supports Passkeys? All right then, I accept that argument. I do use Keepass and compatible programs.

Yes! Though on Android you need the app KeePassDX to read them, I was mistaken about the name.

Re: Android may soon restrict on-device ADB

#522

Post by wolvoleo »

hnlmorg wrote: post #495
wolvoleo wrote: post #494

Earlier quoted context omitted.

Shifting the balance towards security doesn't always improve the overall security stance. What you get is people getting sick of all the stupid hurdles and working around it. Using shadow IT. I find myself doing that too. For example, I was at a highly secured facility one time as a vendor to do a software upgrade. Blocked USB ports, severely reduced internet access etc. So I couldn't do the upgrade, I wasn't even al…

> Shifting the balance towards security doesn't always improve the overall security stance. What youre complaining about isn’t security. It’s security theatre. Which is bullshit > What you get is people getting sick of all the stupid hurdles and working around it. Using shadow IT. I find myself doing that too. Unfortunately it’s people like yourself who implement shadow IT that end up forcing security and infra teams…

> Unfortunately it’s people like yourself who implement shadow IT that end up forcing security and infra teams to add those annoying bureaucratic hurdles to force people in line.

It's because I still need to do my job. And I am also in the security team in fact. But we can't even "burn ISO's" anymore on memory sticks to install stuff in our test lab. When I ask they just say "80/20 rule" which apparently means, they spend the 20% effort on 80% of the usecases and the other 20% can go F themselves. Because the project manager doesn't care, he just wants to tick some boxes in the easiest way possible. That's how you get shadow IT.

> Also RBAC doesn’t prevent you from being hacked. It just limits the blast radius of what is exposed when you do get hacked. It also makes it harder for those who “know enough to be dangerous” to do the wrong thing. Like the shadow IT shenanigans you’ve admitted to.

Exactly, all the mega hacks with the release of millions of customers' data wouldn't have happened if that was properly implemented. Salesforce does have it but companies don't implement it.

And if people go to shadow IT it means that RBAC is not properly implemented because they don't have enough rights to do their job.

Re: Android may soon restrict on-device ADB

#523

Post by 59percentmore »

sunaookami wrote: post #335
59percentmore wrote: post #199

Earlier quoted context omitted.

>implicit social contract Sounds worthless (in court).

And that's how you get a low-trust society.

Well, no. The low-trust society comes (partly) from corporations betraying the trust of consumers, not consumers recognizing that the corporations saying, "Trust us," are probably bullshitting them.

The initial assertion that there has "always" been a social contract is inaccurate.

Re: Android may soon restrict on-device ADB

#524

Post by dotancohen »

wolvoleo wrote: post #520
dotancohen wrote: post #518

Earlier quoted context omitted.

> Well that's why they can sync between devices. What Passkey implantation syncs between devices? I've only ever seen "cloud sync", e.g. syncing with someone else's computer. Can a user sync iPhone passkeys with her Boox E-ink tablet (Android)? Can either sync with a Debian desktop?

Yes you can do that with Bitwarden or KeepassXC. Not sure if either works on iOS, I don't use that but they work on desktop and Android (you use KeepassDX there to read them).

Great, thanks.

Re: Android may soon restrict on-device ADB

#525

Post by Marsymars »

fragmede wrote: post #515
Marsymars wrote: post #448

Earlier quoted context omitted.

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.

Setup a Google voice number as her number in the system and have it forwards to you, with your wife's consent.

a) Google voice doesn't operate outside of the US, and I'm not aware of any equivalent that does, short of setting up, paying for, and managing a full-fledged voip line (e.g. with voip.ms) which are pretty finicky with 2FA codes.

b) These systems are a general pain when you need to deal with human support if your number on file doesn't match the number you call them from. I have a few different numbers that I use variously and run into this every so often - I get a barrage of extra verification questions if I call from a non-matching number, callbacks seem to happen randomly between my number on file vs. my number listed in a ticket, etc. My wife teases me about constantly breaking systems due to hitting untested edge cases.

(Tangentially, various systems will require you to input a phone number with no information stating that it must be a number capable of receiving texts, and at some future date will try to send your landline authentication codes via SMS.)

Re: Android may soon restrict on-device ADB

#526

Post by jambalaya8 »

atoav wrote: post #410
jambalaya8 wrote: post #313

Earlier quoted context omitted.

I am not in favour of limiting adb access, but this does beg the question, how many accidents would it take to cause enough overfull ERs to make the requirement of staircase railings a thing, in order to make sure there are doctors to treat other things than broken bones. uh happy Saturday.

Well in my book it is a cost vs benefit question. Handrails are not expensive in comparison to a medical procedure, nor are they particularly hindering in the daily use of the stairs. In fact, quite the opposite: anybody who uses stairs without handrails may find themselves temporarily disabled, e.g. if a circuit breaker tripped and you have to walk down the stairs in the dark. That means, handrails cost little and h…

I am not arguing with this. I am pointing out that there might be a burden on the medical infrastructure a whole lot of dizzy or partially blind or drunk/high people might put on the system. If you can guarantee you won't prevent someone else from a wait or medical care then it essentially affects noone else but whoever might need to clean up or buy the house you are in if you die and noone finds you in time from the head wound or broken limbs. :).

Re: Android may soon restrict on-device ADB

#527

Post by 1vuio0pswjnm7 »

ShizuWall seems quite useful

For example, the user can keep network access for all apps disabled

Then enable apps needing connectivity on-the-fly only when need to use them

It can be combined with a VPN that does port forwarding like PCAPDroid to be more like NetGuard, i.e., only allowing selected apps to have network access

I have been using Shizuku for years with NMM and some other apps but wasn't aware of ShizuWall; looks like it's been around since 2025

Re: Android may soon restrict on-device ADB

#528

Post by hnlmorg »

wolvoleo wrote: post #522
hnlmorg wrote: post #495

Earlier quoted context omitted.

> Shifting the balance towards security doesn't always improve the overall security stance. What youre complaining about isn’t security. It’s security theatre. Which is bullshit > What you get is people getting sick of all the stupid hurdles and working around it. Using shadow IT. I find myself doing that too. Unfortunately it’s people like yourself who implement shadow IT that end up forcing security and infra teams…

> Unfortunately it’s people like yourself who implement shadow IT that end up forcing security and infra teams to add those annoying bureaucratic hurdles to force people in line. It's because I still need to do my job. And I am also in the security team in fact. But we can't even "burn ISO's" anymore on memory sticks to install stuff in our test lab. When I ask they just say "80/20 rule" which apparently means, they…

You’re hugely over simplifying things.

For starters, your complaint about IT is representative of bad IT operations. NOT security as an industry, like you claim it is.

And your comments about RBAC are such a massive oversimplification that I wonder if you actually do work in security at all. Because no competent security professional would claim that RBAC is a silver bullet that solves all issues.

Re: Android may soon restrict on-device ADB

#529

Post by kllrnohj »

fsflover wrote: post #474
kllrnohj wrote: post #370

Earlier quoted context omitted.

> 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

So the risk is the plug for that being yanked in the ~2-5 days between ordering it and unlocking it? So... not a big deal at all. Not even slightly lol.

Re: Android may soon restrict on-device ADB

#530

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #527

ShizuWall seems quite useful For example, the user can keep network access for all apps disabled Then enable apps needing connectivity on-the-fly only when need to use them It can be combined with a VPN that does port forwarding like PCAPDroid to be more like NetGuard, i.e., only allowing selected apps to have network access I have been using Shizuku for years with NMM and some other apps but wasn't aware of ShizuWal…

Unfortunately it does not block "system" apps
Post reply on HN