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 or IP addresses) seems good, but why not allow developers to restrict access localhost?
It reeks of trying to block Shizuku, Canta, etc. using a way that only makes it look like a side-effect.
"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), sites spamming me to get passkeys which will no doubt be declared insecure and replaced by some more moronic thing when users find a way to get hacked with those too, 80 layers of access control/service identities/IAM/Oauth to host an S3 bucket, OAuth everywhere that won't even work on a headless device, banking websites that want their own special snowflake app as 2FA instead of using TOTP, banning VPNs and slowly rolling out completely real identity surveillance on every corner of the internet to "protect the children", ban open-weight models because the numbers are going to send your data to China, and it just goes on and on and on..
When is this insanity going to stop? I really think the IT security industry ought to be ashamed of itself. Security has become a totalizing value that trumps every other value - convenience, user-friendliness, privacy, hackability, openness, just anything at all in the name of MORE SECURITY.
Security is also increasingly being used as a pretext for usurpation of end-user control over their own devices, which the situation in this very article seems to be a case of.
The industry, and society at large, are today overrun with fiduciaries who've convinced themselves that they are the principals.
This heuristic is not covering the dimensions of interest here, because it fails to address the key security questions (that the industry usually wants people to not even think about):
Who is doing the securing, whose interests are being secured, and against who/what?
Security isn't an unqualified good thing to have. It's just an instrument of control. Who wields it and how are the paramount questions. You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner. In fact, that describes many, if not most, security measures introduced in computing over the past 20 years, especially on the web and mobile devices.
> You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner.
Except that you can't, because those systems require the device to come with secret keys, so an interoperable third party implementation would require keys, which requires permission, which is the exact thing "permissionless" is intended to evict.
In Apple's case, I don't know. I'm making macOS software, and the number of roadblocks I keep running into in the name of security is past merely annoying, it's costing real time and money to deal with it. Unfortunately that's where the users are so we have to spend the resources on it so it's an Apple tax on doing things on their platform. We have to spend more money on Apple development, so that ecosystem benefits? idk.
It’s always interesting to see how fast someone takes a proposal and takes it to some ridiculous extreme.
Websites don’t know your account is a throwaway one, and making an exception for those accounts doesn’t make sense anyway.
Saying “ I accept full responsibility for the fallout” obviously doesn’t work on a large scale and here exceptions don’t make sense either.
Just use a password manager that generates and fills your passwords, and never worry about your passwords for those sites. Don’t tell web admins to drop basic security measures because you don’t know how to manage passwords.
All this boils down to governments wanting security from their citizens and corporations wanting security from their customers. It's not going to stop, ever.
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.
You forgot your $3 payout from the class action lawsuit when the company STILL gets hacked and the exec bonus pool increases because the settlement wasn't "that" bad.
$3 payout? You're being generous, last time there was a major breach, I believe Equifax gifted the victims a year of "free subscription" for their service.
The CRAs compete for the opportunity to offer "a year free credit protection" (that a breached company pays for), because to get it, you usually have to provide a credit card and subscribe to the highest tier. You get your free year and then they turn you into a paying member unless you remember to cancel.
But it helps against account sharing, err I mean they make database leaks irrelevant except for private info of the customer, err I mean that we can now send more mail to the customer about new AI features without risking they think it is phishing, err I mean this is the easiest measure for the auditor findings so since we implemented this we don't need to fix all the crappy internal api auth problems and atrocious out of date dependencies, err I mean...
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).
Except for Microsoft, who just sort of scale back MFA (unless you pay for Microsoft 365 Pro Gold Deluxe Plus Platinum Millenium Edition E5 to set the policy that used to be free) because of reasons.
IT has always been a spectrum with security at one end and convenience at the other. There is no recent trend that’s changed that. That’s just how life works.
Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible.
Also, the original sin: framing it as "security" vs. "convenience". It's not. The other end of the spectrum is utility - as in, maximally secure computing device is an inert rock. More security means less utility - reduced functionality, constrained capability, reasonable use cases no longer possible. It means manual process where previously automation or batching was possible. It means more electricity, more compute, more money spent.
It means more user time and therefore more human lives wasted.
This ultimate non-renewable resource is what we're trading off when we accept even more security. This trade-off needs to be respected much more than it is.
> Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible.
That’s not what’s happening. Here you have security used as an excuse for vendor lock ins. Just like AI is used as an excuse for layoffs. But you shouldn’t confuse actual security with BS like this.
I remember working at a major company where important systems had an admin password of "<company name>123". That was stupid. I asked to change it but the answer was no because too many people would have to be told the new password.
That was too much in favour of convenience and I'm surprised they never got pwned in the worst way.
These days the balance has swung way too much in favour of security though. Even when it concerns assets that have no value.
"Better things aren't possible" is a terrible outlook. There have been real improvements in this space, such as passkeys, and recognition that some of this stuff, like frequent password changes, is counterproductive.
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, entering codes whatever.
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.
> There have been real improvements in this space, such as passkeys
Passkeys are not an improvement. The way they're being implemented entrenches middlemen into auth flows in a way that reduces users' security in a broader sense, while being just as susceptible to compromise as any other form of credential.
Reminds me of what Ubiquiti tried to pull a few weeks ago. They wanted to force everyone to their Cloud UI and login instead of the local interfaces so they reduced the local session lifetime to something insane like 20 minutes while lying to our faces and saying it is for security, and kept the session lifetime longer on their cloud panels. They made sure to exclude this from their changelog too.
The community started monkey patching their local scripts, wrote services to undo their changes, many people disabled auto-updates as Ubiquiti only makes their product worse with their updates. Publicly complained on their support forum that we are onto their little plot.
They ended up backtracking for now but you just know they will try again like Google does.
That's sad news. I've been a fan of Ubiquiti for a long time, and the main selling point has been that they're fully self-managed on-prem infrastructure, with cloud services being an optional afterthought. Seeing them succumb to this disease of using security as a pretext to strongarm their customers is very disheartening.
I had another vendor try to use this argument with us just last week, and I had to vigorously remind them that they were not hired as a security contractor, and that our usage of their product was required to conform to our security policies, not theirs.
Exactly. At work I now have to MFA and type a random code every time I want to book a desk. It kills the session after 30 minutes. It's ridiculous. If an attacker ever got hold of it, they could... book a desk at that shitty office for me. Whoopty doo what horror.
The same with logging my hours in a different system. I only use those systems for those things, nothing else.
Security is important for things that actually hold value. Like when I connect to my admin account. Or even when I connect to our intranet. But they enforce the highest level even for stupid stuff.
One insider threat actor might book a previously unbugged desk, bug it with multi-antenna keystroke logger (making and breaking resistive connections across parasitic capacitance nodes, changes the direction dependent EM scattering function). One can correlate acoustic key press detection with changes in scattering, unsupervised.
Fixed desks are way more secure than promiscuous desk multiplexing.
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.
You're splitting hairs in this case, while that's unquestionably true, it's irrelevant if there tariffs are only set on one party.
That's why Trump's tariffs on everything was so ... Uh ... "Interesting". If only one party gets the tariffs, you end up with other parties selling the goods instead, which does cause meaningful damage to the tariffed party
Or the tariffing party just continues buying very nearly the same amount of things at higher prices in many categories because those items don’t have perfectly elastic supply and demand.
That’s actually kind of like not a good statistic though.
For 30% of transactions with the EU it’s just the US shooting itself in the foot and passing on higher costs to average Americans.
Imagine enacting a tax where 30% of the money collected was a net negative. I can’t think of many taxes that are that poorly constructed.
For the 70% of transactions where US companies and individuals decide to buy less or use alternative sources, doesn’t that at some point harm US businesses? At the very least you’re now artificially lowering competition, which tends to drive overall prices up and quality down.
Something like, "I'm worried about impairing Google's ability to compete in AI" or some nonsense. (Paraphrasing here.)
Looks like all it takes to compete in AI is to issue stock or get a bunch of investors. I don't see how Google would struggle with that. It's completely orthogonal to antitrust enforcement.
Actually, the EU should very much crack down on any foreign company that abuses its market position to stifle local business competition. There's no good reason to allow them to break local laws and diminish the local economy just because they keep their headquarters outside the EU.
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
Sure, sometimes people get social engineered into taking money from their bank account and giving it to criminals. Should banks stop allowing withdrawals?
Your argument is of course absurd, but in general, I think it is a reasonable position to take. The grandmother of someone I know was social engineered into installing a malicious app and changing developer settings on a phone, and lost quite a lot of money. The grandson is at this point absolutely in favor of completely removing the things that allowed that attack vector (I believe in this case it's "merely" the ability to install apps from unknown sources).
I disagree with him. While yes, it's awful and tragic that happened to his grandmother, I think it's incredibly dangerous to allow companies to lock down our devices like that. And I think from a practical perspective, we're never going to be able to eliminate these attack vectors fully; if the grandmother was going to go along with this scammer in this particular way, there would always be some vector that she would fall for, no matter how hard we might try to lock them down.
But I can't bring myself to say his stance is unreasonable. He's dealing with a devastated family member whose retirement is now ruined, and he has to help her pick up the pieces. Not a good position to be in.
If someone is willing to click on build version 5 times and then gets a mystery prompt about dev mode, and still goes along with the next 4 steps I think they were gonna get hacked a billion different other ways
The solution to social engineering can't be to remove useful features - you can socially engineer people to do literally anything, you can have someone walk to their bank, withdraw cash & fly to you with it with a dating scam: there are literally no boundaries once you get into that area of security. Digitally, you combat that through UX, messaging & education.
I totally agree they're easy to dismiss and start to feel cumbersome, but if "protecting users" is their actual motive (I doubt it), this would be a reasonable way to handle it while giving power users the flexibility they want, and that there's high demand for.
Half the issue is, people need to acquire the same wisdom about cybersecurity hygiene as they do looking both ways before crossing the street, but even that's too much to ask for some people. They just don't do it.
At some point, it has to become the responsibility of the potential victim, if liability is such a concern from big tech companies.
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 have nearly no downsides. Which is why I used helmets as a metaphor. The proposed restrictions has a lot of downsides to deal with a mostly theoretical risk.
While I certainly think we should not be taking features away from people just because there exist people who will let themselves be social-engineered through arbitrary hoops, don't go creating wild conspiracy theories to explain something that supports much simpler explanations instead.
It's easy enough to imagine that Google is trying to fix something they see as a problem, and not caring about the developer case rather than specifically seeking to destroy it.
When Apple fixed security issues that allowed for jailbreaking, they weren't doing it specifically because people use it for jailbreaking, they were doing it because it was a security issue.
We should have 100% control of our own devices. But we should have it by design, in a fashion that makes sure that we control them rather than other people.
I think there's very plausible a middle ground too: Google does want to remove these features for business reasons, and is using the real problem of social engineering as an excuse.
In the post iPhone era, a lot of what gets sold as security features is actually just removing functionality from the device.
In early days of this, I honestly think it was rooted in the famous Steve Jobs paranoia, the one that shipped without an app store and told users to use Safari, the same Steve Jobs that was said to not want certain medical devices during cancer treatment to touch him because they weren't beautifully designed. It was fundamentally about not wanting "dirty" things coming in contact with his "perfect" device. They dressed it up in language about security as a post hoc justification.
I remember in those days people would say they didn't want it to be like malware ridden Windows 98. But they omitted the weak security behind Windows at that time, which modern systems had long ago exceeded, even in the Windows world.
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.
"In a normal scenario, a bad actor cannot gain an ADB connection."
It depends on how you define a bad actor.
"rootless privacy tools based on Shizuku."
It's not for the security of the owner; it is for the security of the government.
Trusted execution environment applications like the EU Digital (Identity) Wallet, or whatever they will demand next to protect the children, heavily rely on the fact that users cannot mess with their devices or install unsanctioned software. We all know how badly the Intel SGX story is going.
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.
It seems to me a lot of Google lately is to block things they don't like using ways that only look like side effects.
The introduction of Manifest V3 API in Chrome for extensions, and disabling Manifest V2 for security reasons. It just so happened that ad blockers were made incompatible with the Manifest V3 API. It's a little blatant considering this came right around the time that YouTube began showing warning messages to users with ad blockers...
Requiring developers to verify their apps via Google Play Developer Console and blocking any unverified APK installations. This is done in such a way that it just so happens to squash F-Droid and most FOSS apps for most people, and blocks any serious competition to Google Play or any apps they don't like.
Of course, there's all this talk about preventing malware, but it is a fact that if you download any random ringtone or PDF app on Google Play it's going to come with probably 25 trackers and send your data to every jurisdiction in the world, and many apps even fail to declare any of this via Google Play data safety or privacy policy. Let's not forget that spyware is a form of malware. Take a look at the leaderboard :) https://reports.exodus-privacy.eu.org/en/reports/list/?filte...
In my opinion, this would probably be an indication that maybe Google controls too much technology and that they may need to be broken up to ensure fair competition. For Christ's sake they almost broke up Microsoft not that long ago for shipping a browser with their operating system, and now Google is blatantly controlling the operating system, the platform and app store, the ecosystem, the browser, the ad network, and abusing their power over it however they can.
I still can’t believe that an advertising company was able to effectively neuter ad/content blocking for 80% of the world under the guise of wholly invented safety issues.
Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?
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 is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. And it only works if the Play Store is useless at preventing malware in the first place - but I thought their excellent app scanning was the entire reasoning behind all-but-banning 3rd-party app stores and sideloading???
It is "for safety" in the same sense that governments banning all encryption is to "protect the children" or to "prevent terrorism": flawed justification invented to distract from the real reason they want it.
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 drain your bank account and kill your dog" if she thinks it will let her do whatever she's trying to do on her device. Have you guys never done IT tech support for your elderly parents' computers?
I'm not saying it's right to respond by simply locking everything down, but let's not downplay the blast radius of basically every attack that involves telling the user to do things.
A long time ago, I fixed Windows machines for pocket change. I can confirm some users will make bad decisions no matter what warnings they're given.
I think the impulse for an OS vendor to try to make such mistakes impossible is about as wrong as selling knives dull so people can't hurt themselves. A knife that can't cut its user is useless as a knife.
Eh, this is a tough conversation for engineering-minded folks because the right answer is probably somewhere in the middle of a few different variables.
Too far towards trying to make mistakes impossible (which is easy for corporations to talk themselves into because it also makes them money and moat) and you make devices useless. Too far towards full user control and you get difficulties in support and security issues (which are tractable if you’re an enthusiast, but not so much if you’re a normie on a corporate-maintained device).
Truthseeking here is further complicated by ordinary end users’ dislikes and usability issues not always overlapping.
It requires a nuanced discussion and willingness to compromise to find the right balance. I don't like it myself when, every macOS release, Apple nerfs the system even more and locks down even more, but I also don't like telling my relatives that their system is part of a botnet and that they need to change all their password and call their bank, simply because they saw a popup that told them to download and run TrojanHappyFunGame.
Many software vendors have deliberately blurred the lines between "on your computer" and "on the internet". When you save something in Application A, is it really being saved on your computer, or is it in the cloud? It used to be obvious, but now you kind of don't know until you do some digging in your filesystem. And, now we actually run some apps from the web!
The phrase "the user doesn't have to know if this is on his computer or the cloud" has done a lot of harm to the software ecosystem.
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).
So, they will use other vectors, like convincing people to transfer money. Set up fake webshop. Run scams through online marketplaces, etc. The solution is not to make everything impossible. The solution is to educate people.
Right, and for the few people who can’t be educated, there’s always the option of making dedicated idiot-proof devices. Some people need to wear helmets and knee pads while walking around, but that doesn’t mean that all of us do. Some people shouldn’t be allowed near sharp objects, etc.
Stop trying to flatten the human experience, Harrison Bergeron style.
Until they will look indistinguishable from regular businesses doing regular marketing, advertising, and "value engineering" bullshit. It's xkcd://810 of the advertising industry, I guess - all the scammers doing the legitimate, sanctioned scamming like one big happy family, instead of unfairly competing.
> Have you guys never done IT tech support for your elderly parents' computers?
This kind of comment is frequently made on HN and elsewhere. However, more than a few "elderly parents" are as computer-sophisticated as their grown children. A safe bet it's not rare to be exchanging ideas with an elderly person sophisticated enough to make comments on HN.
AFAIK there's no shortage of careless, uninformed, non-elderly individuals who get scammed into doing stupid things. Age is only one possible factor out of many contributing to scam vulnerability. And let us not forget that youthful, well-trained professional IT workers, developers and software engineers are not immune to scams via misunderstanding elements of the systems or processes they supervise.
Well the messaging we’re told is that the google play store exists for safety - such an app would never exist on there.
Of course this isn’t true, the play store, and yes even the apple App Store to a lesser extent, is riddled with malware.
But what this demonstrates is that, clearly, Google doesn’t care too much about security or safety. It’s a pretense, not a goal. If it was a goal, they’d dump money into fixing the play store, but they won’t and they don’t.
So, we should be highly skeptical when they say something is for “safety” and “security”. At this point, it’s a lot like saying something is for “national security”.
On multiple occasions I had trouble getting people to accept a self signed cert to show them something on a local webpage. It seems that elderly nowadays are super vary of any hacking or scams. YMMV.
> It seems that elderly nowadays are super vary of any hacking or scams. YMMV.
I'm sure you meant "wary". How amazing, education really does work. There is such a thing as overabundance of caution. But it's possible further education could encourage users to apply more balanced caution policies.
Excellent, security education is working. The correct response to someone trying to convince you to accept a self-signed certificate is extreme skepticism; don't undermine people's understanding of good security practices.
> let's not downplay the blast radius of basically every attack that involves telling the user to do things.
That radius would be negligible should the things that must remain secret remain offline.
But no, that's a luddite thing to even think about in an all-connected ever-online world where even wiping one's ass is done via of a swarm of dedicated apps.
On the other hand, there has always been a way to extract secrets from a granny via a mere voice call, so no amount of dumbing it down would really help.
> In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it.
Have you ever worked with someone who barely knows how to use a mobile phone? They will hand their phone over to someone they barely even know to do something they don't understand. They will follow instructions from a stranger over the phone, without understanding what the phone is warning them about.
I have worked with such a person. They did have someone walk them through a dubious process. Thankfully they realized what was going on before the process was complete, but who knows how much damage was done by the initial steps.
There are legitimate security reasons here. Whether there are reasons beyond that is an open question.
Following this logic, shouldn't we just ban smart phones for everyone then? If we need to dumb down all technology to the absolute lowest level, we should probably ban computers or at least require an official government-controlled license to get access to one. Is this a world you want to live in? Me neither.
I suspect this is in bad faith, but assuming not: how does that follow?
“Large numbers of people will uncritically follow sketchy instructions and get hacked” doesn’t in any way lead to “and therefore they cannot be trusted with devices”.
“People keep dying in auto accidents” doesn’t imply “ban cars” on the first order, it implies “seat belts and airbags”.
On the contrary, we should simply restrict app development to a handful of megacorps (who are all in bed with the government) so they can make more money and the government can get the data it wants. Problem solved!
A lot of people are misconstruing what I have said, which is pointing out that this can impact regular users. It not intended as a justification to restrict on-device ADB, and it certainly isn't meant to justify more extreme measures. That being said, we should not ignore what happens in the real world since the consequences are real.
Can we freaking sell them dumbphones, then, and stop destroying portable computers for everyone else with that excuse?
Which incidentally is often just a pretense for other motives?
If computers have suddenly become so dangerous for normal people, and they want smartphones nonetheless, add to them a dumb-mode encouraged at the initial setup, and requiring some third party assistance to turn it off once enabled..! (and forbid apps to change their behavior if it's not enabled)
Lots of dumb phones are trojaned on a firmware level. Trojans are different, but in general they allow the third-party (malware author) to accept SMS and forward them over internet. This is used to register accounts on a services which requires a phone number.
The ad depicts it as a mere phone instead of a potentially hostile Turing machine. There is equivalent messaging in the android ecosystem but its advertising is not so ubiquitous.
You haven't been able to connect to an android device on port 5555 for yeeears. Every time you enable adb/IP it generates a new random port, or you need to use the QR/PIN pairing thing. On top of needing to enable developer options, adb/IP, confirm the fingerprint.
Kimwolf exploits vulnerable Android Debug Bridge (ADB) services. Many low-cost TV boxes come "pre-infected" with proxy SDKs; Kimwolf then scans these residential proxy networks and exploits the devices within minutes as it propagates.
Well yes, but those won't get Google's new updates either. Open ADB on 5555 was a problem we solved almost a decade ago and these devices are still vulnerable. Even further restricting ADB in the latest version won't do anything to prevent that.
Hadn't thought about that additional attack vector those proxies are enabling. In addition to "internet access from residental connection" privileges, the attacker also gets access to loopback on the device that does the proxying...
But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?
You can't fully protect people from the risk of taking bad advice from malicious strangers.
Not the least because most of our industry relies on it to make money. Marketing and advertising themselves are institutionalized forms of "do this thing that's actually harmful to you to get free coins / be safe / get laid".
Told by whom though? If it's through proxyware, then there are three parties who mostly don't know each other:
- the app embedding the proxyware SDK for money
- the proxy operators
- the attackers/botnets using the proxy to access ADB.
The botnet has no access to the app, so it can't show any messages.
The app can show messages, but probably has no connection to the botnet. (I hope)
The proxy operators could show a message by abusing the SDK even more, but that would mean they actively colluded with the botnet. Is that likely? Then they could just give the botnet direct access to the app, no need to do the whole proxy thing.
From memory, for the kimwolf exploit things, other user already had good points about the device already beeing compromised. But also, the authentification part of ADB was just completly disabled, which is why this worked. Basically it was so-compromised as-is that ADB was just sitting here open, as is you where to put SSH with no authentification at all.
There are so many people in my neighborhood here that are actively members of residential proxy networks that it makes me stabby. They don't seem to care.
That said, I wasn't under the impression kimwolf was that technically sophisticated. Some of the others are, though.
I think the OP means that calling it sideloading gives it a sneaky dark connotation which it doesn't deserve because installing software is simply a normal thing for a user to do. It's Google that's branding it as such because they want people to only trust the play store, and thus protect their 30% stake and other benefits like deciding what goes in the store.
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).
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.
I mean, you made a good metaphorical case for controlled handlebar slop/headset resistance in bicycles/motorcycles. Which are things that exist to mitigate crashes from oversteering on both of those vehicles!
In the bikes they're mostly aimed at preventing tank slappers/death wobble. I have a dampener on my bike myself, but it still allows me to countersteer as harsh/rapidly as I want, and that means crashing into a railing or a cliff wall if I overshoot.
No technology prevents the crash, they just lower the chance of it happening accidentally (like, say, ABS or DCT). I can remove almost all of the guardrails on my bike choosing more aggressive riding mode.
Countermeasures to the accidentally allowing a malware to "do something" already exist and were described in the original article. The comment I was responding to wants a removal of the whole capability, hence my cases.
> 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 perhaps they wouldn't? CVEs aren't holy scripture, and "security" isn't the most important consideration in computing. This theatre has gone too far IMO.
Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.
Yes, but what about allowing me to run adb commands on my phone with my consent, and especially delegating that privilege to "strangers", again, with my (one-time) consent - by which I mean authorizing apps to run with elevated privileges and/or reestablish the debugging bridge once it invariably disconnects (for other more or less legitimate security reasons)?
It's not like those threats silently turn on ADB on people's phones without their knowledge. You have to opt in to a rather obscure, hidden by default, and very fickle feature to become potentially vulnerable in the first place.
They're 3 separate issues. There's a genuine vulnerability (CVE) which has been fixed, there's a follow-up proposal to allow the user to choose which interfaces to bind to, and there's another proposal to disallow ADB over loopback which would cut you off from using ADB on-device.
Your problem is with the last one which has nothing to do with the CVE itself.
I agree with user TeMPOraL in his comment. Those who aren't trapped in tunnel-vision, know the app permissions themselves have ALOT of access to all data on your device and users give the apps these permissions. Should we say that every app is a CVE?
The real reason any Google dev wants ADB gone is to close open source and lock down the OS to Google sign-ins and a proxy proprietary closed source eco-system. ADB is the master-key to rooting Android devices, getting Android shell access to /root, uploading *.apks, etc... But for the Google monopoly, it makes sense to them to close/restrict this access, then funnel all requests for it through Google's identity gateway for access. So the argument "this app can bypass OS security through ADB and is therefore a CVE" is not valid and an foolish from its /root.
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.
> 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.
That 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.
>>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.
Can you provide a reasonable definition where an authentication bypass in ADB doesn't qualify as a vulnerability? Is there a use case for allowing anyone on your network to run adb commands without your approval?
There are 3 things which I feel like are being confused here:
1. There was a genuine authentication bypass vulnerability in ADB (bad)
2. Initial proposed change wants to add an option to limit the ADB server to certain IPs or network interfaces (good - it doesn't affect you)
3. Response to the original request, proposing that ADB shouldn't be allowed to listen on loopback interfaces (bad/nefarious - it breaks functionality)
"An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so.
"A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too.
Whether it matters or is something that should be addressed, is the depends part. Here we're talking about CVE that's at risk of trying to address a feature.
You are forgetting the most important questions of security, without which the whole discussion becomes pointless:
Who is securing what, and from who?
CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.
The OS provides restrictions and permissions so that the user can apply them to apps.
If the user chooses to free certain apps from restrictions, that should be their choice.
But if a piece of software overrides the users' choice, that certainly qualifies as a CVE.
This is an important distinction! The user must always have final say.
Whether an app breaks out of the sandbox and steals my vacation photos, or the OS sets new restrictions I can't remove, both are wrong.
Any piece of software has to act in service of the user, and ONLY the user. It must not do things or set restrictions without the users consent. No means no.
This is not one of them. This is "the lock accepts any key" type of CVE.
> In adbd_tls_verify_cert of auth.cpp, there is a possible bypass of wireless ADB mutual authentication due to a logic error in the code. This could lead to remote (proximal/adjacent) code execution as the shell user with no additional execution privileges needed.
> EVP_PKEY_cmp() return 1 if the keys match, 0 if they don't match, -1 if the key types are different and -2 if the operation is not supported.
The original code cast the integer return value to boolean, and -1 and -2 cast to "true", therefore authentication would succeed if the key types were different or the operation wasn't supported.
You jest, but passkeys seem to have literally been invented to address something like: "Keys to your doors can be used by anyone to open those doors, regardless of your knowledge or presence".
Which is a problem only if the third party acquired those keys without your permission, but the industry decided to "fix it" regardless.
Same. There are so many things you could mess up without root from my account anyway. My account isn't a locked down one. You could alias sudo to a keylogger, for instance, and then do whatever as root the next time I sudo something.
So the password check really has no point. Typing sudo is still a lightweight sanity check, otherwise I may as well just log in as root.
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 against the original proposal possibly restricting non-loopback access, which would enhance security.
Why? What other APIs should my apps (or the apps I explicitly want to authorize for this purpose) use to access my private data and my phone call audio?
Because you know, the actual solution would be to have more granularity in authentication process than "allow whole device to attach to ADB", but that would be like, difficult... so they're not going to so that.
Right now any app on my PC connected to ADB could manipulate my phone then, and that's somehow not a CVE?
I am not sure I follow. Are you referring to the original CVE (?), I fully agree that it should be fixed, and it is not what my comment was about.
If you are talking about allowing listening on localhost - remote ADB requires enabling in the developer settings. It is a developer feature, similar to ADB over USB. If I'm charitable, it is possible that they are seeing too many people that are using Shizuku without understanding the security implications. But Shizuku has a lot of useful applications and they use ADB because the Android APIs and permission system are lacking and do not make these applications possible.
Actually that's what the whole fraud detection thing is about. If you transfer money wrong, they lock your account. Some countries like Sweden even went cashless so they can see all transfers.
More like the credit card company can initiate automatic withdrawals from your bank account without your permission if you previously authorized the company to do autopay.
"...avoiding OS security restictions by going through the debug port..." the user delibretry opened and paired to app with clear visual confirmation in order to use it.
no, its a cve if the app can just do it automatically, it is NOT a cve that user goes through 5 steps that they very explicitly do, including unlocking hidden menus to open up developer options, and then allow it.
seriously, get real, please explain how your train of thought works here
Limiting ADB is the obvious next step. Even if this one specific feature request does not come to pass, Google has cornered everyone into relying on a developer interface for any normal personal computing tasks, whether running on-device or through USB/wireless. It's quite clear at some point in the future you will either be required to surrender your identity to them and pay a yearly fee or be severely limited to continue using it in any meaningful capacity, because Google does not want you to develop applications on Android outside their controlled channels -- and it's a developer bridge, the battle was already lost when they did not back down from the changes forbidding normal, legitimate ̶s̶i̶d̶e̶l̶o̶a̶d̶i̶n̶g̶ installation.
>Don’t even get me started on OEMs that force an audio warning such as “This call is being recorded,” when it’s in places where it’s not legally required.
This is also Google's fault. Their dialer--that OEMs increasingly pick over their own, despite their always being much better, see old MIUI one for example--just blanket applies the rule almost everywhere. Especially annoying on all MediaTek SoCs that do not support the feature on an hardware level at all through proper, reliable third-party applications. As if you didn't need any more proof you don't own "your" devices. But maybe in a couple years Gemini will be able to listen to the calls and summarize them for you, just need to go through the approved surveillance channel.
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 despite Google, you wouldn't even be able to do much that requires anything to do with SafetyNet and all successors delivered through Google Play Services, which is functionally the core component of any Android device for the near entirety of typical use-cases. And I'm not excusing OEMs, but they did not build their market share off of being "open" then start to close every door and trap you in 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)
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 anything?
> Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)
Why are you even asking Google at all? Just use Firefox? Don't even need to root or use a custom ROM for that, even.
>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 it? (see 1)
Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.
>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.
Practically speaking none of what you brought up are actually issues because once the phone connects to the internet once, it's unlocked forever, including after relocks/flashing. It's like saying you don't "own" the stuff you bought on bandcamp, because there's a split second between when you bought the song and when you could download it, therefore "It depends on a remote endpoint that can go down at any point, and depends on the company's policies present and future" and "It is functionally asking for permission to another party".
I don't think the bandcamp analogy applies. I may purchase a device with the intent of eventually unlocking the bootloader, but not doing so immediately for whatever reason, such as it still being supported by official updates, or the nth feature not being yet removed. Then the possibility of the option being taken away before you've exercised it remains.
1. It's unclear whether the online check is done when you tap the oem unlocking option, or it's done asynchronously in the background. If it's the latter, then it doesn't really matter because it'll get unlocked anyways.
2. There's no real disadvantage to leaving your bootloader in "locked (unlockable)"[1] state, because you can continue using stock rom and avb is enforced, but you can unlock it at any point using fastboot.
3. The Bandcamp analogy still applies because it offers streaming too (ie. web player), which means you could be happily streaming (ie. not downloading) and then one day they shut down, denying you access to all your music.
> Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.
Your example is about one developer's decision, which is not really what we're talking about. The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store? We're talking about restrictions laid down by the OS developer and for iding all applications outside of their crappy walled garden, which is very different. Also, you don't actually think Google is going to stop there do you? They will certainly turn it off one day of they think they can get away with it, because it is in their financial self-interests to do so.
>Your example is about one developer's decision, which is not really what we're talking about.
Is it? Many games outsource their anticheat to a third party developer, similar to how many apps outsource their app security to play integrity.
>The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store?
What about (nearly) all the games that only support windows, and worse yet, are exclusives on one distribution platform? Yes, there's wine/proton and cracks, but that's a "solution" in the same way that using a modded apk to get past the play integrity requirements is a "solution".
> 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
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?
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.
The implication in the blog post that Google developers somehow “overlooked” or “misunderstood” important use cases here, and if only they were informed about them they would reconsider, is frankly insulting.
Every single time any story has the words "Google developers" in it, they're behaving like arrogant, disconnected, anti-consumer jerks. From constant GCP breakage, to not acknowledging obvious Android bugs, to intentionally braking Chrome. It's a stark contrast to behind the scenes interactions with them.
If I didn't word it like that (I'm the author) the "reddit mob" would have exploded the thread. That's the last thing I want. I want valuable feedback there, for now its somehwat working.
Most of the users who saw the post on reddit didn't even open the blog post anyways, according to analytics.
Yeah, my favorite one is how Chrome users are not smart enough to handle case-aware web-page search toggle. Although to be fair their Chrome team is very arrogant even by Google standards.
The moment an article like this hits HN or Reddit or any other such forum, any hope of changing anyone's mind is lost. The same happens to Github issues too. I haven't checked the isue myself, but seeing it here means it's probably already too late at this point, it'll probably get flooded.
Google does take feedback from app developers every now and then, but obviously their own teams' feelings on the subject are more important to them than some open source developers relying on a hack like in this article.
I think it should be quite obvious that the ADB daemon wasn't designed to enable call recording from an app initiating an adb session over a loopback address. https://xkcd.com/1172/ strikes again.
That doesn't mean the developer who wrote this is wrong to dislike the change: Google themselves have added call recording to their dialer a while ago so it's clearly a feature they stand behind. That doesn't mean the adb team shouldn't do a little security hardening, though.
In 2008 Sergey Brin and Larry Page saw the limo waiting, and instead chose to rollerblade to the Android unveiling. Sergey Brin, during the presentation, threw his G1 in the air to show off how his homemade application leveraged the accelerometer to see how high he'd thrown it
That use-case was never designed for when the sensor was added, and is every bit as hacky and fun as adding call recording with a loopbakc address
And that's the first problem: Android is no longer fun, and it's no longer for trying this hilariously stupid hacky method of doing what we, the users, want.
The second problem is an attitude of "Google's dialer has it built-in, why would one want a third-party dialer instead of Google's?"
Because we fucking can - or could, at least. The OS was designed to be as modular as possible, to the point where, while iOS still can't change their launcher, Android has had that option since day one. Setting aside Google casting themselves as the (not so) benevolent dictator of "Just use our apps exclusively. Life will be easier that way", closing off the modularity is antithecal to the Android experience that so many geeks fell in love with, and arguably made the platform what it is
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 games. Can't do pretty much anything.
That's the future of Android. GrapheneOS is quite literally the last hope for Android, and only because by some miracle there are companies out there who started trusting Graphene's attestation keys. If that hope ever dies then we might as well buy iPhones.
Play Attestation is a Google hosted database of build keys/hashes for known Android builds. Android-side of this attestation is an API which calculates and returns those hashes to the app.
There's nothing preventing the app from verifying the build itself against its own database. So they can allowlist GrapheneOS builds if they want - but of course that means that all other ROMs are still banned.
Of 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.
Many alternative AOSP-based systems work fine today and do not have the new Android Developer Verifier (wow, already rolled out to 500M+ devices [1], though still dormant).
To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick your phone, etc.
and now people install Remote Access Trojans just to let GPT and Claude think and work for them, granting them shell and a11y access. really? after seeing that, nothing surprises me
Yes, really. The obvious answer that security maximallists deny even exists is, who is doing it and why. In LLM case, users are doing it themselves to allow a way of computing they want and find useful, in spite of platform locks designed to deny users just that.
I mean, go tell Anthropic to prompt Claude to make it adopt Landlock in Claude Code instead of regex-based filtering. actually adopt it, not how Codex did, but with controls on the level of some third-party harnesses and Pi plugins.
> To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones.
Are any commercial mobile phone vendors not able to do such a thing? Do remember that this giant kerfuffle is all over the seeming preparation for the apparent removal of a developer feature that iPhones have never had at all.
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 before, puts existing features behind paywalls, etc. people are rightfully outraged, because it breaks the social contract.
It's just that the repeated offenses have made us insensitive. Imagine Debian rolling out some mechanism that only allows you to install software outside their repos with a 24 hour delay. It would destroy Debian.
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.
> 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.
No because the EUDI Wallet needs Google Play Services. People need to come to the realization that the EU has no interest in regulating the freedom of devices because the EU itself is benefitting from the closed-down ecosystem.
As far as I can tell, this is a big overreaction to a misunderstanding.
I'm a developer with remote adb enabled, using it in the normal intended way (to install new builds of an Android project I'm developing, retrieve log files related to it, etc). Currently, I access this via VPN (tailscale), but it's exposed to connections (and any pre-auth security vulnerability risks) on any random public wifi network I connect to. Adding the ability to restrict this to just tailscale will be an improvement, for me.
The proposal at the top of the thread is that you specify which interface you want it to bind to, when you set up remote adb, rather than binding to every interface. Nothing in that proposal suggests that "localhost" would be rejected as a choice of interface. One person suggested binding only to "wlan0", but that was a short throwaway comment that is obviously wrong (wlan0 is less-trusted than VPNs) and obviously not what they're going to do.
The person who made that suggestion (sa...@google.com) is presumed to be the one of the main maintainer of ADB as their name (Fabien Sanglard) showed up in non-redacted in the history and CC here (https://android-review.googlesource.com/c/platform/packages/...) after it was linked in the original Google IssueTracker. We can confirm they are a Google employee as per their @google.com top domain name. (For users reading, please don't target this person, it won't change anything AT ALL, i'm stating this since its public informations, and for proof)
Their email is also in the CODEOWNER of ADB, and they made the recent ADB Wifi 2.0 presentation at Droid-Con Paris.
They stated, "Connection to localhost has also been the source of exploits where apps are using that socket to adbd to escalate their privileges," which suggests that internally they viewed it primarily as an exploit bad actor uses. Without feedback, they would most lickly not consider changing their point of view, this is why the blog post was made.
I do agree, however, that many of the comments, mainly on Reddit, blow the issue way out of proportion. Based on the website analytics, I can also confidently say that most people didn't even open or read the blog post. That's fine with me, though. My goal was to get the attention of actual developers and more technical users.
I have been very carful in the blog post not to write something too dramatic like some news outlets do, but if no one read it, I can't do anything about it.
EDIT: I have purposefully left that person name out of the blog post I originally made to avoid encouraging people to message them directly. However, if I need to update the blog or publish some kind of follow-up with supporting evidence, I may end up linking it. I'm not sure tbh.
I am worried that this might happen to websites soon.
If you want your website to be openable on Apple devices, you would have to pay Apple a fee each month. If you want your website to be openable on Android devices, you would have to pay Google a fee ecah month, etc.
You would have the "new web" consisting of the top n major websites paying this fee.
And then you would have the "old web", accessible only to people still owning their own PCs with unrestricted browsers. And probably heavily scrapped by AI companies to reguritate to the masses through the new web.
So you won't be able to use your banking apps, your local transport app, public services apps, health services apps, etc.
But sure, you can do SMS (no RCS though), use the device calculator, and maybe browse the Web… until websites kick you out because your non Chrome/Safari browser isn't supported anymore. Even Signal won't work well due to the lack of FCM.
And I'm a GrapheneOS user happy with Obtainium and without Play Services installed in main user space.
I always disable everything Google that comes preinstalled other than maps, including the App store. You can download stuff that you can only get there through Aurora, but really most of what I use comes from F-Droid.
Not that I trust a device running Android enough to do banking, mind you.
We need Linux on phones. Bank apps not needed as long as I can use browser. But do need some things like wireless cards, popular apps like Sonos and Spotify working.
Unfortunately many banks in the UK no longer offer a web portal or physical branches.
I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly.
(I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)
Require payment services providers to ensure that all users can benefit from methods to perform SCA which are adapted to their needs and situations and, in particular, that those methods do not depend on one single technology, device or mechanism, for instance on the possession of a smartphone.
Wise in the UK currently is good. You can use it completely without a phone app.
It also has good support for passkeys, TOTP, and SMS OTP, allowing to add multiple of each as it should be. If you do choose the Wise app, it currently warns when you run a custom Android ROM, but let's you use it.
Our company also uses Revolut business, but that requires a phone app to verify online payments with cards. And Revolut recently changed the app so it now requires Google Play Integrity so it doesn't work with LineageOS anymore. So I'm looking to move all new things away from Revolut. I have little patience with companies that want to unbank my company, and decide what hardware or software we use.
Fun fact that is in Russia major banks are sanctioned and had their apps removed from App Store and Google Play so banks forced to keep mobile optimized and fully featured web portals for iOS users.
There's mobile payment apps worldwide like yappy and UPI, that don't have a web interface and are local monopolies. Even worse they are sometimes controlled by a single large bank, not a government and not a consortium so you're entirely beholden to their (confidential) decisions, whatever they might be. It's not like in the US where you have Venmo, Zelle, and Cash app, or China where there's WeChat and alipay.
> I'm in with DNB and Nordea and they both have functioning netbanks.
And both are banks I'd never want to associate with. I would have used Sbanken before the DNB buyout (and I even did for a bit!), but now that's of the table too.
There are a few more options, but many are just worse if you look at their fees and interest rates.
I've been very happy with Bulder. The only thing they're missing is a web portal. The fact that they're missing that annoys me greatly, but they've been good to me in every single other aspect, so it's hard to be dissatisfied (especially compared to the other banks where I and others have been burned). Their app works fine on de-Googled Android, and so long as that's true, I can live with my choices.
I appreciate the info. Re: the banks I'm with, I have no choice.
I'm an immigrant and most banks refused to give me an account when I moved here. Or ghosted me during the months long process. These are the banks that let me live here, and actually gave me an account and bank id. It's the only real choice I have until I get citizenship.
There's no reason the banks should be dicks about it, but they often are in cases like yours. All the accounts I've opened in recent times have just been a matter of logging in with BankID and going through the form and selecting 'no' 10 times. Once you've got BankID and can go through the automated flow, there shouldn't really ever be any issues.
This is why it bothers me greatly that BankID is still controlled by the banks, since they can just decide that someone like you shouldn't get it. It should be government issued and issued to everyone, on the same level as an ID card or a passport.
Good point. They don't. Huh, that's really worrying. My bank started requiring phone for web portal only about a few years ago. They don't allow to use an alternative MFA method. This should be made illegal.
This is all inevitable direction over long period of time
What’s worrying is that noone protests about it
It doesn’t suprise me that corporations and governments want the laziest, most „protective” laws passed that extend their power. But why noone, absolutely noone puts some kind of resistance to it?
Government and citizens are at eternal conflict of interests. It has been this way and it will be this way forever.
Your job as a citizen is to make sure you have greatest amount of liberties
The frogs are almost done, and the silicone figurines that used to impost actual frogs and croak how pleasant the water is and how it should always keep getting warmer to keep everyone comfortable, will soon be removed from the pot, their duties fullfilled.
Need to pressure banks to achieve feature parity between their websites and native apps. I'm forced to use Paypal to remote deposit checks because my banks limit that feature to their apps, which I can't use because of my device's age. (Paypal does, too, but their app still works for now.)
Unfortunately these days bank apps are required by the banks for "security", and good luck getting anything done without the bank app installed on your phone.
The only other alternative available is SMS but that is being phased out (rightly so) for being insecure.
Currently my bank requires a device where I need to insert my card to get a one time six digit code based on a QR code the banking website serves me that the device scans.
I'm not quite sure why they don't support something like a yubikey with FIDO, but maybe there's a good reason.
Every bank here had that. Now they all require apps.
For the banks I understand. Now they don't have to supply millions of code calculator devices. And they force their apps which they can stuff full of tracking to mine their customers for data they can sell.
It's sad but part of the usual enshittification cycle
Lots of questionable replies to you here, people recommending Android/Lineage/Graphene are being silly, Sailfish is a better answer but with major proprietary components I would still skip it. postmarketOS is the best option I believe. Mobian and some others possibly worth a mention as well. I found Ubuntu Touch/ubports to be disappointing so I wouldn't bother with that either. You can check the pmOS wiki to find compatible devices. Perhaps check first if anything you already own has support, and help them support your device better if you are able. Otherwise look for the devices with the best support and get one off eBay. Librem 5 and PinePhone should be among the best supported devices but you may get better performance / $ with a OnePlus 6T or other formerly-Android phone (again, verify most stuff is already working before buying something if possible).
For the popular apps you mention, there is Waydroid to run Android apps.
There's only one reason for anyone, or for me, at least, to choose Android, and it's the only reason I've consistently chosen Android from the very first Google Developer Phone: It's more open.
So, they don't want me to even have that one reason to keep choosing Android, I guess.
If my phone is going to be locked down anyway, I'm choosing the platform that at least pairs with my AirPods properly and doesn't get me weird looks at social events.
Google is really stretching their goodwill with this one. The ability to sideload and debug my phone is the only marginal benefit to these janky Java relics. If that's gone, no reason not to switch to a wholely better platform.
If I don't get weird looks at the kinds of social events where everyone else has an iphone, then I have failed at life. I can think of no greater horror than to be seen as uninteresting.
I was thinking a lot about how these restrictions are paved with good intentions, but every time these new security measures are implemented we see criminals adopt new strategies and continue going about their day like nothing ever happened.
I've been seeing this specifically with ID / business verification requirements where they just have some innocent (or sometimes complicit) third party grant them access to verasign 'verified' trust signing keys which actually makes them way more trusted than they were ever before often making anti-malware applications way less strict about blocking it which in turn buys them just enough time to compromise the system and disable said anti-malware applications. The problem here is that anti-malware applications try to be seemless and are effectively in a giant race condition to terminate the application, more recently microsoft anti malware service will now block program execution until it validates that it is safe. Although it is not something other companies do as making the device feel sluggish is something they avoid at all costs (looking at you bitdefender).
> This feature was proposed following a major security issue identified as CVE-2026-0073, which allowed the Wireless ADB authentication process to be fully bypassed. What is proposed in this issue is actually a nice idea.
Clearly this is not an issue when the wireless authentication process works as intended. I see no need to change that at all. They just need to fix that bug.
It's quite difficult to do this. You need to enable wireless debugging. Then pair to a random port with a random pairing code and then connect to yet another random port. When it works as intended it's more than secure enough.
If they really want to restrict it, just let the user choose in the development settings what interface to listen to.
This assumes user is the only person with physical access to unlocked phone.
All sorts of goverment agencies, airport security, even teachers now have access. And such attacks can be trivially automated, so even low paid worker can do it.
Step back to the other issue (referenced in the page*), that Google would pushing on devices something that blocks applications that do not come from play.google.com . Was it not established that Google can only push that update on devices with a google account?
For the longest time the free software foundation (well Stillman) were against all mobile phones because of their ability to track people. In the last year they have finally admitted that they were not going to win that battle and have gone head first into trying to build a fully open software stack.
Not saying it will be good or arrive anywhere in the next 5 years but they are very persistent and that tends to work in their favour.
The apps that are the reason some people use smartphones at all — bank apps — require Google services and remote attestation that runs in an environment with more privileges than the OS kernel. Otherwise everyone interested would just unlock their bootloader and use a ROM with all the asinine restrictions removed.
Android Wireless debugging is already a major pita to work with.
Requires a wifi connection to even work, so I need to carry a mobile wifi router with me, instead of having it bound to my secure WireGuard connection.
Next it assigns a random port number every time the wifi connection is interrupted, or when it considers now is a good time to reset the port number. It should be possible to set a stable port and and have it available, perhaps behind a few awkward UI/adb toggles.
Android had a tradeoff - less vertical integration and more annoyances, a bit worse software quality, for a more open, customisable and utility-like experience. I loved that.
Now, the tradeoff is - less vertical integration, double the integration layer trash (Google & OEM) and a much more locked down experience. But the quality of it hasn't improved, it just got worse.
Doesn't make sense anymore. They can now do 99% of the same things, but iOS has a better quality OS, better apps and better vertical integration.
Not even vertical integration, actually just any kind. FFS it's 2026 and the recommended android way to send a photo to your mac/PC is "upload to google photos and hope it decides to sync".
Amazon crippled the ADB functionality on FireTV Sticks a while ago. Making it an absolute pain to build and debug TV apps on. Currently, the only way to test is to install a release build every time.
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.
Right, that too. But that's a reason to recommend regular reboots[0], not to force them, and "3 days of inactivity" is a suspiciously specific time that I also saw mentioned in Android settings somewhere the other day.
--
[0] - Which I find deeply ironic, in that merely a decade ago, people would laugh at Windows with its "reboot after installs, reboot in case of problems" approach, and now frequent reboots are seen as Standard Security and Stability Practice on *nix systems, both mobile and server-bound...
I have no issue restarting my iOS/Mac/Linux machines because the time to get back to doing fun or productive stuff is measured in seconds. And usually you only have to restart one time. Windows used to take ages, and often you’d reboot only find out that something else that requires a reboot only triggered because of the previous reboot, so you were sometimes in for 2-3 restarts.
It’s not like that anymore in my experience at least but the stigma stuck.
They dont care about security; only about control.
There are hundreds of millions of outdated Android devices that all Google attestation systems consider secure even though they all running Linux kernel that was never ever updated and can be rooted by anything.
Now try to install your own firmware on them without said outdated kernel... How dare you.
Technically the security works, just for their threat model. An exploit would need root and root means you likely cannot pass attestation AFAIK. The fact that this same exploiter can download all your contacts photos and texts is immaterial to, say, Disney, who want attestation only to prevent ripping of their content.
No it doesnt actually work because its possible to do privilege escalaction without tampering with firmware or filesystem or triggering other markera. OS will be practically rooted while passing attestation just fine.
Only things attestation do is security theater and messing up people ability to use software of their choosing.
Have you read the android security model? It's a multi party security model which considers apps and users as equals. It's a legitimate security model and just because it's not what you want doesn't mean it's wrong.is it user hostile? Maybe. But that is different than saying it offers no security. It's also not worth bickering about every small decision that is made in line with that security model. If you want a different one, push for it via alternative OS.
It's not even "max security". We are talking about those big tech corps which are infamous for sharing all of your private information with the government, and analyzing it so as to manipulate you in to buying things, and possibly for other obscure commercial purpuses.
They securely share your private info with their advertising partners. You know that no hackers that didnt pay google would get access to that information.
More specifically apps and users have equal agency in the android security model. Which comes down to the fact that if you don't own the app you can't control its experience. This feels grounded to me. Push for more open source apps where you retain control and ownership.
It's already hard enough that we can't mess with apps' internal storage without rooting IMO. It's my device. I should be able to inspect what every app is collecting about me. Just like I can on windows.
IMO the user should always be the top admin on a device they own.
Indeed I absolutely am. I don't believe in this model where we have to trust some big commercial party for our security and privacy. And they abuse this all the time, both Google and iOS.
The problem is though that I have no choice. iOS is even more locked down and distrusting of the user. It's never even had a bootloader unlock option for example. And not using a smartphone is not possible in this day and age.
No, when you can't participate in modern society without specific apps, I would argue those developers, in fact, don't have the right to not offer me their services.
No one's requested the config switch from A to B with a restriction that's acceptable to those seeking B. Idealism doesn't tend to offer compromises, and so Idealism tends to lose when it doesn't make a convincing case to regulators. Here's a simple and easy to implement example compromise that could be offered today:
"Changing between A and B requires a device reset."
Most people are going to flat out refuse to wipe their device for a phisher, especially since it'll log them out of everything and trigger all sorts of "new device on your account" warnings everywhere if it's done without their knowledge.
Sure, this is mildly annoying for the 1% that have good reason for A — but it's annoying once per device rather than losing A for good as is happening now. Sure, Google will deny service to A. They're doing that no matter what, either b/c they remove A or b/c they deny A, but this forces them to construct and defend a case for why users who went through the hassle of wiping their device to switch to A ought to be denied access to the app store, and that's a critically absent case in regulatory circles right now. (See also Graphene vs. the EU age check app.)
That's all it would take to protect B from A, but no one asks for it, and no one presses Google publicly for it, and so of course Google isn't doing it. No megacorp will help you walk off the Golden Path without some sort of extrinsic pressure. I see a great deal of clamor around wanting A, but absolutely none of the 'here's a mild annoyance that we came up with as a valid and safe compromise' clamor that would make them look incompetent in the public eye, provide further leverage for EU antitrust steps regarding Android itself, and give them a way to continue to protect users who need B for safety, while allowing those of us who want A to pursue it.
Perhaps other styles of compromise exist, too? As far as I can determine, no one else is thinking about this in terms of "what compromises will developers offer that continue to protect non-developers?", and so I have no other examples to offer. I'd sure love to see more ideas, more effort invested into offering serious and real compromises rather than inflexible resistance of every real safety improvement.
Every time I want to connect ADB to a device, it takes me far more time than it should. Having different ports for pairing and connecting is already a pain. I wonder what new hurdles will come up once they restrict adb to wlan0, even though atm I can't see any problems for my use cases (like pushing APKs, reading logs or connecting dev tools).
Not being able to use VPNs might be a problem in corporate setups (e.g. debugging an issue in production environments).
That would make sense if they hadn't first taken away the user's ability to control their own device directly. Some people were OK with that because users could still use this hack, but are presumably less OK with it in retrospect now that this second step finishes the job.
I'd be interested to see whether this comes with a replacement for legitimate use cases. Removing a capability without offering an alternative tends to push developers toward even more fragile or in some cases "rule breaking" workarounds
The On-Device ADB work-arounds and a lot of open-source apps related to it are already in that fragile workarounds "zone".
For most, this is the last resort / only way possible. As AOSP refuse to add secure permission or services to allow third-party application to do specific actions.
If this get fixed, it will be the end of thoses project on-device for non-rooted ROMs. Sure, you could still run it via a computer, or to be far fetched, start Shizuku via a computer. But that's no longer "on-device". It kill a lot of usages, including developers who need it "on-the-fly".
why not cut to the chase and simply remove user access to devices? preventing non playstore installs and restricting adb are addressing symptoms, user behaviour, not actual security issues.
Linux phones exist but work on a limited number of devices (see PostMarketOS) or Linux primary devices like Purism or Pinephone (which I've heard are expensive). That's the primary issue, you either need to buy an expensive and potentially underpowered phone OR have one that is supported most of the way with PostMarketOS (Wifi, SIM card, GPU, etc. sometimes may not work even though the phone can boot PostMarketOS).
I personally don't have a problem with a mediocre-performance phone but it should not be expensive. Not to mention app ecosystems - there aren't a lot of Linux apps for Linux phones.
I've paid 200€ for my PinePhone. It is underpowered, but at least it doesn't have to waste its resources on rendering ads.
Where Android/iPhone users have "apps", I mostly end up writing small shell scripts around existing linux tools. My alarm clock "app" is realized via cron jobs; my TOTP "app" is a one-liner around `oathtool`.
Messenger apps are a bit tricky; I'll probably end up hosting my own matrix homeserver and then have bridges running for Signal and the likes.
There are plenty of apps for Linux phones because you get all of the Linux software automatically. What there isn’t plenty of is commercial pop culture apps from social media companies, banks, and other businesses but for some of those you can run an android emulator or use their website.
LEA, Customs and intelligence agencies regularly use GDB to hack and extract information from an Android phone. So in that sense it may be a valid concern and reason to restrict this.
However, I'm pretty sure these entities will already have negotiated exemptions from the restrictions so in that sense they don't add much security.
Can they ruin it faster i am sick of it already. Need to root the phone to get basic functionality, i need like 6-7 magisk modules to do basic things. I can't access file system on device i paid 250$. I have to use adb to change basic things, i rather use symbian.
Symbian pioneered this bullshit. Having to sign apps with Nokia keys just to install them was a thing since the days of S60. And it all went downhill from there.
This is about control, not security. As in, Google's control over your device, your experience, your features and choices. This and Google just isn't interested in supporting an open OS anymore. Maybe they think it makes them liable.
Either way the writing is on the wall, and has been for a while.
IIRC 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.
use encryption and keys for all socket connections to adb, listen on 0.0.0.0 and unify the wifi thing with the socket thing, add an app level permission that allows apps to access an ephemeral system key via the binder to enable libadb style usecases?
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.
> The internet, as it has been, is quite an anomaly
It's not an anomaly, it was the data grabbing infrastructure, and now that enough data is vacuumed in from it to train AI, it is now time to turn this dangerously conductive communication network into a control-only one, by all logic of the process and those who funded it all the way.
What's ironic is that these news are something you'd expect to hear from China or former Soviet countries. But frogs still believe that "putting America in the same sentence as Russia" is stupid
I'm so done with Android and iOS. I already carry around 2 phones because neither will give me exactly what I want, maybe it's time for a 3rd running Linux..?
Linux phone is already a thing that exists and is at a point where it can be used by tech illiterate people within the confines of what is possible normally.
It's just that few people bother using it. But that number might increase if Android continues it's war against its users.
adb is not being stopped, the bug is talking about a niche way folks use it without a secondary device. There is also no conclusion from the bug on what action will actually be taken.
And people wonder why we're in the rut that we are.
Sidenote: The poster in that article is insane to me. Imagine advertising yourself as the only alternative. I'd rather vote for an empty seat than for someone who's that arrogant! Then again, I don't really have to imagine it, since there have been quite a few politicians within the last 10 years who have functionally done that same, just without actually saying those words out loud.
And I might soon restrict use of Android and iOS in my life. Because of this nonsense, how will I get around the app issue is something I am still trying to figure out but I won't pay money to companies that make my products(I own them after I bought them) worse bit by bit anymore.
Do you want your smart TV to become a persistent access point to your home network? If not, you should prefer to have an explicit unbypassable confirmation before another device is allowed to install arbitrary apps on it and pregrant them arbitrary permissions.
- You connect via USB ADB to enable TCP/IP, then disconnect the USB cable.
- ADBD continues running and listens on all network interfaces.
- The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected. No silent exploitation attempts are possible.
I understand the author's rationale and think the reasons why that whole ecosystem is accessing ADB are legitimate - but I have some questions here.
The above flow is basically what apps that use Shizuku have to do as well, right? Only that in that case, the user would deliberately install the app and have the knowledge it uses ADB features and therefore would also confirm the permission prompt.
However, ADBD in this situation only sees a connection attempt, not which app made the attempt, right?
So it also cannot remember that a particular app was already authorized by the user and has to display the prompt again on each connection attempt?
Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?
This seems honestly like Shizuku itself would increase the risk of a user granting ADB access to a bad actor (i.e. a second app or external connection that is different from the app the user wanted to authorize).
Thinking of "scenario 3" if a Shizuku-enabled app is already running on the device and something else wants to connect to ADB:
- I'm assuming a malicious app was already installed (without privileges) or something tries to connect to port 5555 from outside or via proxyware.
- ADBD is already running and listening for TCP to serve the Shizuku app, so those steps can be taken for granted.
- The malicious app or connection triggers a permission prompt from ADBD. However, by that time, the user has grown used to those prompts, because the Shizuku triggers them frequently, so they are more likely to select "yes".
If ADBD has no information about who is connecting, it also can't show any meaningful information in the prompt. So it cannot really help the user distinguish prompts from the legitimate Shizuku app from malicious prompts. A user still has the timing and context to distinguish prompts, i.e. prompts that appear out of the blue when they aren't using the app are suspicious.
> However, ADBD in this situation only sees a connection attempt, not which app made the attempt, right?
Every ADB connection has some kind of certificate / key that is saved locally. This means that a new application would have a different certificate. That certificate is shown in the yes/no prompt.
> Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?
You can tell android to remember that certificate and allow the connection next time. There is a bug that make it not work on certains specific version of Android 12 I think, but outside of that, it always works.
These are not accidents. Google declared total war against open source.
You only need to remember how it declared war against ublock origin. In
the long run this will also fail, but until then Google causes a lot of
damage. Legislation needs to control this tyrant but unfortunately the
oligarchs run the country of the mad orange king right now.
Louis Rossman will have a field day with Google here. I think it is time
to end Evil - that is, to end Google. This company serves no more useful
purpose on this planet anymore.
It's frankly amazing how many Google developers will associate their real identities and contact info with such hostility, believing they're invincible.
Perhaps they should be subjected to the full force of the First Amendment.
The article overlooks security implications from spyware, which is a huge problem not only for financial applications, but personal safety, too [0].
Per FTC, a stalkerware will: geo locate, read call list & record calls, read notifications, texts, & possibly emails, access gallery, camera, & files, and monitor network activity. [1]
You could do all of those with "on-device adb" (in some cases, with just the appropriate permissions), without root access. Stalkerware & financial fraud enabled merely due to the scale & reach of Android (half of humanity uses it!) and lack of basic security literacy warrants such protective measures, as (Thaler & Sunstein would like to remind us) defaults matter.
With conspiracies abound, we must not lose sight of tech safety and related issues, which almost exclusively affect the most vulnerable & the most disadvantaged.
Spyware using ADB could be a thing (assuming someone has full access to your phone, including the password). However, it is impractical, as a reboot, system update, or Wi-Fi change would likely break everything.
It is much easier for spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps as a one-time setup.
At that point, ADB no longer matters. The spyware is already configured and ready to run. Even if on-device ADB were patched, anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.
As for attacks without physical access, as explained in the article with the 3 scenario, this is neither practical nor realistic. It only affects a very small subset of users (primarily Android developers) under very specific circumstances and during limited time windows.
> spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps
Correct, and apps using these setups (even for genuine reasons) have been under the cosh.
> At that point, ADB no longer matters.
"on-device adb" wasn't meant for scenarios it is being used for (via Shizuku, for example). It is a pointless attack surface.
> anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.
This same case can be made in support of removing on-device adb. Anyone with physical access can install & configure for their use cases. If you claim that's more hassle than worth, then you have your answer (that is, added hassle for stalkerware sellers, too).
Disallowing on-device adb is restrictive (I co-develop a security app that can absolutely make more from elevated permissions, via Shizuku or Device Admin; let alone root), but I don't think Google will do so because they want to close Android (the platform) more than they need to. To me, given the very human costs of stalkerware & financial fraud, it is an understandable, even if disappointing, security decision. Otoh, I do get that the road to hell is paved with good intentions...
adb connecting a device to itself is just bad design and a hack. Either the capabilities should just be granted directly to the app or it should all be blocked.
Same can be said about loopback device in general. Why do you need to use networking when you are literally on the same device and can use binder/dbus and friends with native apps?
Shizuku uses Binder AFAICS[^1]. Looking deeper it seems that Shizuku does not connect to the device itself per se, but rather it has a privileged server launched manually through adb. Never used Shizuku, so can't say for sure.
Shizuku essentially implements an API that your OS creator should have implemented via using adb access to have more privileges than a regular app could have access to. If your OS creator implemented these APIs they could properly implement them without this hack or requiring adb to be used.
That seems rather unlikely given the the ways of the fruit factory. They don't stand to gain anything from loosening their stranglehold on their flock while they could lose substantially if someone were to open the gate and let the sheep escape. Nope, keeping them penned in is the best way to reliably fleece them.
I think one attack vector this sort of overlooks in the first point, regular users installing malicious apps.
My elderly mum has an Android phone. She is not very tech-literate.
She might see a full page ad "your phone has a virus, clean it now", or somehow end up on something like it (e.g. a scam email).
She then dutifully clicks on it, which prompts to download an apk. The webpage provides clear instructions for how
to install the just-downloaded APK.
That APK (app) then walks her though enabling ADB, so it can "clean the phone". The app gave very good instructions (customized to reflect the UI that her device manufacturer would use), so she manages to click through to the hidden settings menu and enable ADB.
The app can now exfiltrate all sorts of data, without needing any scary permissions prompt which will tell the user what is being accessed.
I think this sort of pattern is very real, and many users are being affected by these scams. And undoubtedly more android users than iOS ones.
Finding a balance that allows power users like me to use my device as I wish, and protecting regular users, is quite hard. I think the solution Google came up with of requiring a 24 hour wait, + some extra scary warnings, for unsigned apps is a step in the right direction, it helps less tech literate users avoid scams, and power users just have to be patient for 24h. But of course it's still not satisfactory for everyone, mum might still get scammed, and power users get annoyed at it.
Your post switched half-way from "this hypothetical app your mum might hypothetically install" to "this apparently real app doing these specific things". Which way is it? Are you describing an actual threat in the wild, or just speculating about possibility?
FWIW, similar kinds of attacks is exactly why side-loading apps is about to require a reboot and 24 hour cooldown. Which you mention at the end. It sucks, but it's a decent compromise; power users like me will just do the dance and pick the "indefinite" option the moment they unpack their new phone, and rest of the people will never even know about it until they're half-way through being scammed.
I personally don't believe doing anything more in this direction is warranted.
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 or IP addresses) seems good, but why not allow developers to restrict access localhost?
It reeks of trying to block Shizuku, Canta, etc. using a way that only makes it look like a side-effect.
"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), sites spamming me to get passkeys which will no doubt be declared insecure and replaced by some more moronic thing when users find a way to get hacked with those too, 80 layers of access control/service identities/IAM/Oauth to host an S3 bucket, OAuth everywhere that won't even work on a headless device, banking websites that want their own special snowflake app as 2FA instead of using TOTP, banning VPNs and slowly rolling out completely real identity surveillance on every corner of the internet to "protect the children", ban open-weight models because the numbers are going to send your data to China, and it just goes on and on and on..
When is this insanity going to stop? I really think the IT security industry ought to be ashamed of itself. Security has become a totalizing value that trumps every other value - convenience, user-friendliness, privacy, hackability, openness, just anything at all in the name of MORE SECURITY.
Security is also increasingly being used as a pretext for usurpation of end-user control over their own devices, which the situation in this very article seems to be a case of.
The industry, and society at large, are today overrun with fiduciaries who've convinced themselves that they are the principals.
There is a simple and highly accurate heuristic to tell if a security measure is reasonable:
Is it an open standard that anyone can permissionlessly implement?
When the answer is yes, there is a high probability that it's something reasonable, e.g. TOTP.
When the answer is no, what you will find behind the curtain is either a fool or a crook.
This heuristic is not covering the dimensions of interest here, because it fails to address the key security questions (that the industry usually wants people to not even think about):
Who is doing the securing, whose interests are being secured, and against who/what?
Security isn't an unqualified good thing to have. It's just an instrument of control. Who wields it and how are the paramount questions. You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner. In fact, that describes many, if not most, security measures introduced in computing over the past 20 years, especially on the web and mobile devices.
> You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner.
Except that you can't, because those systems require the device to come with secret keys, so an interoperable third party implementation would require keys, which requires permission, which is the exact thing "permissionless" is intended to evict.
Right, and that leads us back to the more-generalized (but very classic) cui bono? Who gets the benefits?
In Apple's case, I don't know. I'm making macOS software, and the number of roadblocks I keep running into in the name of security is past merely annoying, it's costing real time and money to deal with it. Unfortunately that's where the users are so we have to spend the resources on it so it's an Apple tax on doing things on their platform. We have to spend more money on Apple development, so that ecosystem benefits? idk.
Don't forget "Remember for 30 days" checkboxes that don't do anything.
I'm begging, please let me use password "asdfasdf" on throwaway accounts. I accept full responsibility for the fallout.
Seriously, many web admins need to hear this message: "Chill. Your site is not that important."
It’s always interesting to see how fast someone takes a proposal and takes it to some ridiculous extreme.
Websites don’t know your account is a throwaway one, and making an exception for those accounts doesn’t make sense anyway.
Saying “ I accept full responsibility for the fallout” obviously doesn’t work on a large scale and here exceptions don’t make sense either.
Just use a password manager that generates and fills your passwords, and never worry about your passwords for those sites. Don’t tell web admins to drop basic security measures because you don’t know how to manage passwords.
Your site is non trivial.
I'll repeat what GP wrote:
> Seriously, many web admins need to hear this message: "Chill. Your site is not that important."
No site is important until it is, but by then it's too late to overhaul your security architecture.
All this boils down to governments wanting security from their citizens and corporations wanting security from their customers. It's not going to stop, ever.
Taking this attitude, it's guaranteed.
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.
You forgot your $3 payout from the class action lawsuit when the company STILL gets hacked and the exec bonus pool increases because the settlement wasn't "that" bad.
$3 payout? You're being generous, last time there was a major breach, I believe Equifax gifted the victims a year of "free subscription" for their service.
Accountability is nonexistent in our industry.
The CRAs compete for the opportunity to offer "a year free credit protection" (that a breached company pays for), because to get it, you usually have to provide a credit card and subscribe to the highest tier. You get your free year and then they turn you into a paying member unless you remember to cancel.
> 2FA on every trivial site
But it helps against account sharing, err I mean they make database leaks irrelevant except for private info of the customer, err I mean that we can now send more mail to the customer about new AI features without risking they think it is phishing, err I mean this is the easiest measure for the auditor findings so since we implemented this we don't need to fix all the crappy internal api auth problems and atrocious out of date dependencies, err I mean...
> 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).
Except for Microsoft, who just sort of scale back MFA (unless you pay for Microsoft 365 Pro Gold Deluxe Plus Platinum Millenium Edition E5 to set the policy that used to be free) because of reasons.
Not until we clearly identify the deep root from which all of this is conveyed.
IT has always been a spectrum with security at one end and convenience at the other. There is no recent trend that’s changed that. That’s just how life works.
Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible.
Also, the original sin: framing it as "security" vs. "convenience". It's not. The other end of the spectrum is utility - as in, maximally secure computing device is an inert rock. More security means less utility - reduced functionality, constrained capability, reasonable use cases no longer possible. It means manual process where previously automation or batching was possible. It means more electricity, more compute, more money spent.
It means more user time and therefore more human lives wasted.
This ultimate non-renewable resource is what we're trading off when we accept even more security. This trade-off needs to be respected much more than it is.
> Right, but security maximalist are running the asylum now, and they try to sell everyone the lie that more security is possible.
That’s not what’s happening. Here you have security used as an excuse for vendor lock ins. Just like AI is used as an excuse for layoffs. But you shouldn’t confuse actual security with BS like this.
> It means more electricity, more compute, more money spent.
And it means more middlemen mediating people's access to their own tools.
Yes but the balance has shifted a lot.
I remember working at a major company where important systems had an admin password of "<company name>123". That was stupid. I asked to change it but the answer was no because too many people would have to be told the new password.
That was too much in favour of convenience and I'm surprised they never got pwned in the worst way.
These days the balance has swung way too much in favour of security though. Even when it concerns assets that have no value.
"Better things aren't possible" is a terrible outlook. There have been real improvements in this space, such as passkeys, and recognition that some of this stuff, like frequent password changes, is counterproductive.
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, entering codes whatever.
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.
They're better for both parties with the subset of providers who require one of either SMS 2FA or passkeys.
> There have been real improvements in this space, such as passkeys
Passkeys are not an improvement. The way they're being implemented entrenches middlemen into auth flows in a way that reduces users' security in a broader sense, while being just as susceptible to compromise as any other form of credential.
> Better things aren't possible
Literally no one in security thinks this.
I really think the IT security industry ought to be ashamed of itself.
See Pournelle's Iron Law of Bureaucracy.
It will be "so convenient" when we finally have digital ID so we won't have to deal with all that stuff.
Wait until you figure out just how much trust is required to make Zero Trust work.
It is all so frustrating.
Reminds me of what Ubiquiti tried to pull a few weeks ago. They wanted to force everyone to their Cloud UI and login instead of the local interfaces so they reduced the local session lifetime to something insane like 20 minutes while lying to our faces and saying it is for security, and kept the session lifetime longer on their cloud panels. They made sure to exclude this from their changelog too.
The community started monkey patching their local scripts, wrote services to undo their changes, many people disabled auto-updates as Ubiquiti only makes their product worse with their updates. Publicly complained on their support forum that we are onto their little plot.
They ended up backtracking for now but you just know they will try again like Google does.
That's sad news. I've been a fan of Ubiquiti for a long time, and the main selling point has been that they're fully self-managed on-prem infrastructure, with cloud services being an optional afterthought. Seeing them succumb to this disease of using security as a pretext to strongarm their customers is very disheartening.
I had another vendor try to use this argument with us just last week, and I had to vigorously remind them that they were not hired as a security contractor, and that our usage of their product was required to conform to our security policies, not theirs.
Exactly. At work I now have to MFA and type a random code every time I want to book a desk. It kills the session after 30 minutes. It's ridiculous. If an attacker ever got hold of it, they could... book a desk at that shitty office for me. Whoopty doo what horror.
The same with logging my hours in a different system. I only use those systems for those things, nothing else.
Security is important for things that actually hold value. Like when I connect to my admin account. Or even when I connect to our intranet. But they enforce the highest level even for stupid stuff.
One insider threat actor might book a previously unbugged desk, bug it with multi-antenna keystroke logger (making and breaking resistive connections across parasitic capacitance nodes, changes the direction dependent EM scattering function). One can correlate acoustic key press detection with changes in scattering, unsupervised.
Fixed desks are way more secure than promiscuous desk multiplexing.
> 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-...
Eh, that is if they pay. Trump already made threats for tariffs in regards to those fines.
Which is a federal sales tax against the citizens of the United States countries abroad do not pay no matter how many times taco lies.
You're splitting hairs in this case, while that's unquestionably true, it's irrelevant if there tariffs are only set on one party.
That's why Trump's tariffs on everything was so ... Uh ... "Interesting". If only one party gets the tariffs, you end up with other parties selling the goods instead, which does cause meaningful damage to the tariffed party
Or the tariffing party just continues buying very nearly the same amount of things at higher prices in many categories because those items don’t have perfectly elastic supply and demand.
Technically true but highly misleading. The amount of good like that are few, less then 30% of the EU -> US trade.
That’s actually kind of like not a good statistic though.
For 30% of transactions with the EU it’s just the US shooting itself in the foot and passing on higher costs to average Americans.
Imagine enacting a tax where 30% of the money collected was a net negative. I can’t think of many taxes that are that poorly constructed.
For the 70% of transactions where US companies and individuals decide to buy less or use alternative sources, doesn’t that at some point harm US businesses? At the very least you’re now artificially lowering competition, which tends to drive overall prices up and quality down.
The EU shouldn't be regulating Google like this.
The US should.
The DOJ brought an antitrust case against Google… and won.
Then the judge pretty much decided “no consequences”.
It was the lamest excuse ever.
Something like, "I'm worried about impairing Google's ability to compete in AI" or some nonsense. (Paraphrasing here.)
Looks like all it takes to compete in AI is to issue stock or get a bunch of investors. I don't see how Google would struggle with that. It's completely orthogonal to antitrust enforcement.
Why not both? Countries should be able to signal which business practices are undesirable.
The EU can't realistically bring Google to its knees. The US could.
I say that as a European that's very much in favor of government intervention to fix market distortions.
Yes, laws are laws but one affects a branch, the other a root.
Cut off enough branches and the roots die.
Actually, the EU should very much crack down on any foreign company that abuses its market position to stifle local business competition. There's no good reason to allow them to break local laws and diminish the local economy just because they keep their headquarters outside the EU.
The EU absolutely should be regulating companies that operate in her jurisdiction. Google is free to pursue other markets.
Hopeless. US already lost against corps. And that will be their downfall.
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
Sure, sometimes people get social engineered into taking money from their bank account and giving it to criminals. Should banks stop allowing withdrawals?
Your argument is of course absurd, but in general, I think it is a reasonable position to take. The grandmother of someone I know was social engineered into installing a malicious app and changing developer settings on a phone, and lost quite a lot of money. The grandson is at this point absolutely in favor of completely removing the things that allowed that attack vector (I believe in this case it's "merely" the ability to install apps from unknown sources).
I disagree with him. While yes, it's awful and tragic that happened to his grandmother, I think it's incredibly dangerous to allow companies to lock down our devices like that. And I think from a practical perspective, we're never going to be able to eliminate these attack vectors fully; if the grandmother was going to go along with this scammer in this particular way, there would always be some vector that she would fall for, no matter how hard we might try to lock them down.
But I can't bring myself to say his stance is unreasonable. He's dealing with a devastated family member whose retirement is now ruined, and he has to help her pick up the pieces. Not a good position to be in.
In Sweden the answer was yes.
On the plus side, that also allows for mass surveillance of the population for, uh, security reasons. For the children. Probably.
If someone is willing to click on build version 5 times and then gets a mystery prompt about dev mode, and still goes along with the next 4 steps I think they were gonna get hacked a billion different other ways
The solution to social engineering can't be to remove useful features - you can socially engineer people to do literally anything, you can have someone walk to their bank, withdraw cash & fly to you with it with a dating scam: there are literally no boundaries once you get into that area of security. Digitally, you combat that through UX, messaging & education.
Then maybe the best course of action is Google adding a warning before enabling certain settings that help normies avoid these attacks.
Along the lines of "Are you being asked to do this by someone else? Be cautious, as your device could become compromised."
Nobody reads the warnings and getting to use ADB on a phone is already a quest of epic proportions, soon to become the next Monkey Island sequel.
I totally agree they're easy to dismiss and start to feel cumbersome, but if "protecting users" is their actual motive (I doubt it), this would be a reasonable way to handle it while giving power users the flexibility they want, and that there's high demand for.
its ridiculous how many people will ignore the warnings and relay the security challenge/solution to the attacker.
"we will never ask for this over the phone" takes second place to:
"we will send/save you money/time if you make it convenient"
dress it up to taste like developer needs, and you can hook the newbies.
> "we will never ask for this over the phone" takes second place to:
Doesn't help that the banks then do, in fact, call you, and ask for this over the phone.
those banks that do that are grooming customers for failure, they create a workflow that is close to an attack.
in my region AT&T has a very explicit statement not to reveal MFA codes to anyone who asks, is not part of thier system to do that.
there is 1 bank in my area that does voice call relay over the phone, the others keep it 10 fingers relayed from phone to authentication form.
guess who has the most problems with account compromise, and fraud claims? yes, that one bank. it has a phishing vector in its system.
Half the issue is, people need to acquire the same wisdom about cybersecurity hygiene as they do looking both ways before crossing the street, but even that's too much to ask for some people. They just don't do it.
At some point, it has to become the responsibility of the potential victim, if liability is such a concern from big tech companies.
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.
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.
In many jurisdictions, staircase handrails are required[1] in residential homes.
And even when they are required, it's up to the person using the stairs to determine whether they wish to elect to use the handrail or not.
[1]: IRC R311.7.8
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 have nearly no downsides. Which is why I used helmets as a metaphor. The proposed restrictions has a lot of downsides to deal with a mostly theoretical risk.
I think that these victims are paid by the likes of Google to create a precedent. It is unbelievable stupid scheme to fall to.
While I certainly think we should not be taking features away from people just because there exist people who will let themselves be social-engineered through arbitrary hoops, don't go creating wild conspiracy theories to explain something that supports much simpler explanations instead.
It's easy enough to imagine that Google is trying to fix something they see as a problem, and not caring about the developer case rather than specifically seeking to destroy it.
When Apple fixed security issues that allowed for jailbreaking, they weren't doing it specifically because people use it for jailbreaking, they were doing it because it was a security issue.
We should have 100% control of our own devices. But we should have it by design, in a fashion that makes sure that we control them rather than other people.
I think there's very plausible a middle ground too: Google does want to remove these features for business reasons, and is using the real problem of social engineering as an excuse.
... and it is stupid to try to protect cretins who would do that by screwing everybody else.
In the post iPhone era, a lot of what gets sold as security features is actually just removing functionality from the device.
In early days of this, I honestly think it was rooted in the famous Steve Jobs paranoia, the one that shipped without an app store and told users to use Safari, the same Steve Jobs that was said to not want certain medical devices during cancer treatment to touch him because they weren't beautifully designed. It was fundamentally about not wanting "dirty" things coming in contact with his "perfect" device. They dressed it up in language about security as a post hoc justification.
I remember in those days people would say they didn't want it to be like malware ridden Windows 98. But they omitted the weak security behind Windows at that time, which modern systems had long ago exceeded, even in the Windows world.
It's a security theater but you should at least respect that the guy was willing to die for beautifully designed devices and rid us of Adobe Flash.
> you should at least respect that the guy was willing to die for beautifully designed devices
I don’t think that kind of stupidity warrants respect.
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.
"In a normal scenario, a bad actor cannot gain an ADB connection."
It depends on how you define a bad actor.
"rootless privacy tools based on Shizuku."
It's not for the security of the owner; it is for the security of the government.
Trusted execution environment applications like the EU Digital (Identity) Wallet, or whatever they will demand next to protect the children, heavily rely on the fact that users cannot mess with their devices or install unsanctioned software. We all know how badly the Intel SGX story is going.
> why not allow developers to restrict access localhost?
Ads and tracking, obviously (https://localmess.github.io/)
All these changes Google is doing to Android aren't for you as the user, they are to protect their business interests from the user.
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.
It seems to me a lot of Google lately is to block things they don't like using ways that only look like side effects.
The introduction of Manifest V3 API in Chrome for extensions, and disabling Manifest V2 for security reasons. It just so happened that ad blockers were made incompatible with the Manifest V3 API. It's a little blatant considering this came right around the time that YouTube began showing warning messages to users with ad blockers...
Requiring developers to verify their apps via Google Play Developer Console and blocking any unverified APK installations. This is done in such a way that it just so happens to squash F-Droid and most FOSS apps for most people, and blocks any serious competition to Google Play or any apps they don't like.
Of course, there's all this talk about preventing malware, but it is a fact that if you download any random ringtone or PDF app on Google Play it's going to come with probably 25 trackers and send your data to every jurisdiction in the world, and many apps even fail to declare any of this via Google Play data safety or privacy policy. Let's not forget that spyware is a form of malware. Take a look at the leaderboard :) https://reports.exodus-privacy.eu.org/en/reports/list/?filte...
In my opinion, this would probably be an indication that maybe Google controls too much technology and that they may need to be broken up to ensure fair competition. For Christ's sake they almost broke up Microsoft not that long ago for shipping a browser with their operating system, and now Google is blatantly controlling the operating system, the platform and app store, the ecosystem, the browser, the ad network, and abusing their power over it however they can.
I still can’t believe that an advertising company was able to effectively neuter ad/content blocking for 80% of the world under the guise of wholly invented safety issues.
They wouldn't have been able to if people didn't use a browser created by an advertising company.
uBlock origin and Brave shields work great. Never had a problem.
Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?
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 is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. And it only works if the Play Store is useless at preventing malware in the first place - but I thought their excellent app scanning was the entire reasoning behind all-but-banning 3rd-party app stores and sideloading???
It is "for safety" in the same sense that governments banning all encryption is to "protect the children" or to "prevent terrorism": flawed justification invented to distract from the real reason they want it.
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 drain your bank account and kill your dog" if she thinks it will let her do whatever she's trying to do on her device. Have you guys never done IT tech support for your elderly parents' computers?
I'm not saying it's right to respond by simply locking everything down, but let's not downplay the blast radius of basically every attack that involves telling the user to do things.
A long time ago, I fixed Windows machines for pocket change. I can confirm some users will make bad decisions no matter what warnings they're given.
I think the impulse for an OS vendor to try to make such mistakes impossible is about as wrong as selling knives dull so people can't hurt themselves. A knife that can't cut its user is useless as a knife.
Eh, this is a tough conversation for engineering-minded folks because the right answer is probably somewhere in the middle of a few different variables.
Too far towards trying to make mistakes impossible (which is easy for corporations to talk themselves into because it also makes them money and moat) and you make devices useless. Too far towards full user control and you get difficulties in support and security issues (which are tractable if you’re an enthusiast, but not so much if you’re a normie on a corporate-maintained device).
Truthseeking here is further complicated by ordinary end users’ dislikes and usability issues not always overlapping.
It requires a nuanced discussion and willingness to compromise to find the right balance. I don't like it myself when, every macOS release, Apple nerfs the system even more and locks down even more, but I also don't like telling my relatives that their system is part of a botnet and that they need to change all their password and call their bank, simply because they saw a popup that told them to download and run TrojanHappyFunGame.
It used to be common knowledge that downloading stuff could be dangerous. That went away when vendors tried to make it safe.
Many software vendors have deliberately blurred the lines between "on your computer" and "on the internet". When you save something in Application A, is it really being saved on your computer, or is it in the cloud? It used to be obvious, but now you kind of don't know until you do some digging in your filesystem. And, now we actually run some apps from the web!
The phrase "the user doesn't have to know if this is on his computer or the cloud" has done a lot of harm to the software ecosystem.
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).
That's why they're going to fully locked down devices.
So, they will use other vectors, like convincing people to transfer money. Set up fake webshop. Run scams through online marketplaces, etc. The solution is not to make everything impossible. The solution is to educate people.
Right, and for the few people who can’t be educated, there’s always the option of making dedicated idiot-proof devices. Some people need to wear helmets and knee pads while walking around, but that doesn’t mean that all of us do. Some people shouldn’t be allowed near sharp objects, etc.
Stop trying to flatten the human experience, Harrison Bergeron style.
Until they will look indistinguishable from regular businesses doing regular marketing, advertising, and "value engineering" bullshit. It's xkcd://810 of the advertising industry, I guess - all the scammers doing the legitimate, sanctioned scamming like one big happy family, instead of unfairly competing.
> Have you guys never done IT tech support for your elderly parents' computers?
This kind of comment is frequently made on HN and elsewhere. However, more than a few "elderly parents" are as computer-sophisticated as their grown children. A safe bet it's not rare to be exchanging ideas with an elderly person sophisticated enough to make comments on HN.
AFAIK there's no shortage of careless, uninformed, non-elderly individuals who get scammed into doing stupid things. Age is only one possible factor out of many contributing to scam vulnerability. And let us not forget that youthful, well-trained professional IT workers, developers and software engineers are not immune to scams via misunderstanding elements of the systems or processes they supervise.
"Ageism" is a word as ugly as what it signifies.
Well the messaging we’re told is that the google play store exists for safety - such an app would never exist on there.
Of course this isn’t true, the play store, and yes even the apple App Store to a lesser extent, is riddled with malware.
But what this demonstrates is that, clearly, Google doesn’t care too much about security or safety. It’s a pretense, not a goal. If it was a goal, they’d dump money into fixing the play store, but they won’t and they don’t.
So, we should be highly skeptical when they say something is for “safety” and “security”. At this point, it’s a lot like saying something is for “national security”.
On multiple occasions I had trouble getting people to accept a self signed cert to show them something on a local webpage. It seems that elderly nowadays are super vary of any hacking or scams. YMMV.
> It seems that elderly nowadays are super vary of any hacking or scams. YMMV.
I'm sure you meant "wary". How amazing, education really does work. There is such a thing as overabundance of caution. But it's possible further education could encourage users to apply more balanced caution policies.
Excellent, security education is working. The correct response to someone trying to convince you to accept a self-signed certificate is extreme skepticism; don't undermine people's understanding of good security practices.
> let's not downplay the blast radius of basically every attack that involves telling the user to do things.
That radius would be negligible should the things that must remain secret remain offline.
But no, that's a luddite thing to even think about in an all-connected ever-online world where even wiping one's ass is done via of a swarm of dedicated apps.
On the other hand, there has always been a way to extract secrets from a granny via a mere voice call, so no amount of dumbing it down would really help.
This gave me a hearty laugh not only due to the idea, but because that's been my near exact experience with helping my family.
> In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it.
Have you ever worked with someone who barely knows how to use a mobile phone? They will hand their phone over to someone they barely even know to do something they don't understand. They will follow instructions from a stranger over the phone, without understanding what the phone is warning them about.
I have worked with such a person. They did have someone walk them through a dubious process. Thankfully they realized what was going on before the process was complete, but who knows how much damage was done by the initial steps.
There are legitimate security reasons here. Whether there are reasons beyond that is an open question.
Following this logic, shouldn't we just ban smart phones for everyone then? If we need to dumb down all technology to the absolute lowest level, we should probably ban computers or at least require an official government-controlled license to get access to one. Is this a world you want to live in? Me neither.
I suspect this is in bad faith, but assuming not: how does that follow?
“Large numbers of people will uncritically follow sketchy instructions and get hacked” doesn’t in any way lead to “and therefore they cannot be trusted with devices”.
“People keep dying in auto accidents” doesn’t imply “ban cars” on the first order, it implies “seat belts and airbags”.
Yeah well this new thing is like requiring a certified Ford driver to drive the car.
Me personaly, I'm so fed up with these advocates of security-through-universal-presumption-of-imbecility!..
On the contrary, we should simply restrict app development to a handful of megacorps (who are all in bed with the government) so they can make more money and the government can get the data it wants. Problem solved!
> ban computers or at least require an official government-controlled license to get access to one
People seem to be ok with needing a license to operate a motor vehicle and those are far less dangerous.
Cars are far more dangerous and they kill people. It’s the number one cause of death for some demographics in the US.
A lot of people are misconstruing what I have said, which is pointing out that this can impact regular users. It not intended as a justification to restrict on-device ADB, and it certainly isn't meant to justify more extreme measures. That being said, we should not ignore what happens in the real world since the consequences are real.
Can we freaking sell them dumbphones, then, and stop destroying portable computers for everyone else with that excuse?
Which incidentally is often just a pretense for other motives?
If computers have suddenly become so dangerous for normal people, and they want smartphones nonetheless, add to them a dumb-mode encouraged at the initial setup, and requiring some third party assistance to turn it off once enabled..! (and forbid apps to change their behavior if it's not enabled)
Lots of dumb phones are trojaned on a firmware level. Trojans are different, but in general they allow the third-party (malware author) to accept SMS and forward them over internet. This is used to register accounts on a services which requires a phone number.
Here's my article about that from 2021. It's for the devices sold in Russia, but this issue is worldwide: https://habr.com/ru/articles/575626/
And here's more detailed research of two particular devices: https://notes.valdikss.org.ru/trojan-digma/
"Can we freaking sell them dumbphones"
Nothing is stopping the guy at Walmart or Tmobile from selling them dumbphones, or are you implying they are forced to?
Try letting the blame trickle down from the pyramid's apex instead of blaming the footman.
Here is the first iPhone ad:
https://www.youtube.com/watch?v=6Bvfs4ai5XU
The ad depicts it as a mere phone instead of a potentially hostile Turing machine. There is equivalent messaging in the android ecosystem but its advertising is not so ubiquitous.
You are right, better locking them out of the Play Store, there's too much risk using it.
We could also imagine a 24h delay to get Play Store access with a modal to make them understand the risks.
Those people will be conned in a million other ways.
You haven't been able to connect to an android device on port 5555 for yeeears. Every time you enable adb/IP it generates a new random port, or you need to use the QR/PIN pairing thing. On top of needing to enable developer options, adb/IP, confirm the fingerprint.
Millions of Superboxes and various digital picture frames say different.
https://synthient.com/blog/a-broken-system-fueling-botnets
Kimwolf exploits vulnerable Android Debug Bridge (ADB) services. Many low-cost TV boxes come "pre-infected" with proxy SDKs; Kimwolf then scans these residential proxy networks and exploits the devices within minutes as it propagates.
https://www.cloudflare.com/learning/ddos/glossary/aisuru-kim...
This is like saying that SSH is insecure because some device vendors install SSH, permitting root login with a default password of 'root'.
Yeah let's block port 80, too many people expose unprotected api.
This is what several cellular ISP to (block ports <1024 and 5555) to protect the users on IPv6.
You can unlock it with additional free option.
Well yes, but those won't get Google's new updates either. Open ADB on 5555 was a problem we solved almost a decade ago and these devices are still vulnerable. Even further restricting ADB in the latest version won't do anything to prevent that.
Hadn't thought about that additional attack vector those proxies are enabling. In addition to "internet access from residental connection" privileges, the attacker also gets access to loopback on the device that does the proxying...
But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?
Yes, but users are told to allow it if they want to get free coins etc.
You can't fully protect people from the risk of taking bad advice from malicious strangers.
Not the least because most of our industry relies on it to make money. Marketing and advertising themselves are institutionalized forms of "do this thing that's actually harmful to you to get free coins / be safe / get laid".
> Not the least because most of our industry relies on it to make money.
I mean, this seems more like one of the root causes for a lot of bad things in the industry me...
Told by whom though? If it's through proxyware, then there are three parties who mostly don't know each other:
- the app embedding the proxyware SDK for money
- the proxy operators
- the attackers/botnets using the proxy to access ADB.
The botnet has no access to the app, so it can't show any messages.
The app can show messages, but probably has no connection to the botnet. (I hope)
The proxy operators could show a message by abusing the SDK even more, but that would mean they actively colluded with the botnet. Is that likely? Then they could just give the botnet direct access to the app, no need to do the whole proxy thing.
It isn't being done behind-the-back of proxy operators.
It's one more revenue stream to be able to remote control real android phones to pass device attestation checks etc.
It's marketed to users with phrases like "earn money from your phone whilst you sleep".
And it's entirely Cloudflare's and Google's fault. When you say you need to have X to do Y, people are going to find ways to get X.
Ok, that makes more sense. Hooray for stuff getting even worse...
Remote attestation itself being a questionable idea at best, so it's bad things creating a market for even worse workarounds.
No objection there.
Also telling that advertising and locking down devices are driven by the same companies...
From memory, for the kimwolf exploit things, other user already had good points about the device already beeing compromised. But also, the authentification part of ADB was just completly disabled, which is why this worked. Basically it was so-compromised as-is that ADB was just sitting here open, as is you where to put SSH with no authentification at all.
There are so many people in my neighborhood here that are actively members of residential proxy networks that it makes me stabby. They don't seem to care.
That said, I wasn't under the impression kimwolf was that technically sophisticated. Some of the others are, though.
It's not because of security. It's to slowly close any avenues for side-loading stuff
It's not side loading. Word you are looking for is called "installing".
Not on android https://www.reddit.com/r/explainlikeimfive/comments/1k824n8/...
I think the OP means that calling it sideloading gives it a sneaky dark connotation which it doesn't deserve because installing software is simply a normal thing for a user to do. It's Google that's branding it as such because they want people to only trust the play store, and thus protect their 30% stake and other benefits like deciding what goes in the store.
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!
I mean, you made a good metaphorical case for controlled handlebar slop/headset resistance in bicycles/motorcycles. Which are things that exist to mitigate crashes from oversteering on both of those vehicles!
In the bikes they're mostly aimed at preventing tank slappers/death wobble. I have a dampener on my bike myself, but it still allows me to countersteer as harsh/rapidly as I want, and that means crashing into a railing or a cliff wall if I overshoot.
No technology prevents the crash, they just lower the chance of it happening accidentally (like, say, ABS or DCT). I can remove almost all of the guardrails on my bike choosing more aggressive riding mode.
Countermeasures to the accidentally allowing a malware to "do something" already exist and were described in the original article. The comment I was responding to wants a removal of the whole capability, hence my cases.
> 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 perhaps they wouldn't? CVEs aren't holy scripture, and "security" isn't the most important consideration in computing. This theatre has gone too far IMO.
Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.
Yes, but what about allowing me to run adb commands on my phone with my consent, and especially delegating that privilege to "strangers", again, with my (one-time) consent - by which I mean authorizing apps to run with elevated privileges and/or reestablish the debugging bridge once it invariably disconnects (for other more or less legitimate security reasons)?
It's not like those threats silently turn on ADB on people's phones without their knowledge. You have to opt in to a rather obscure, hidden by default, and very fickle feature to become potentially vulnerable in the first place.
They're 3 separate issues. There's a genuine vulnerability (CVE) which has been fixed, there's a follow-up proposal to allow the user to choose which interfaces to bind to, and there's another proposal to disallow ADB over loopback which would cut you off from using ADB on-device.
Your problem is with the last one which has nothing to do with the CVE itself.
Correct.
That, and security maximalism displayed in 3. and some comments in the HN thread.
I agree with user TeMPOraL in his comment. Those who aren't trapped in tunnel-vision, know the app permissions themselves have ALOT of access to all data on your device and users give the apps these permissions. Should we say that every app is a CVE? The real reason any Google dev wants ADB gone is to close open source and lock down the OS to Google sign-ins and a proxy proprietary closed source eco-system. ADB is the master-key to rooting Android devices, getting Android shell access to /root, uploading *.apks, etc... But for the Google monopoly, it makes sense to them to close/restrict this access, then funnel all requests for it through Google's identity gateway for access. So the argument "this app can bypass OS security through ADB and is therefore a CVE" is not valid and an foolish from its /root.
You, and may of the people in the thread here are at cross purposes, I think.
The CVE mentioned in the article is https://nvd.nist.gov/vuln/detail/CVE-2026-0073. That's a real CVE: logic error leading to auth bypass. Fix can be seen at https://android.googlesource.com/platform/packages/modules/a....
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.
> 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
That 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.
Yeah, they didn't claim that it's a CVE, just behavior that they wanted to change. Miscommunication then.
>>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.
Depends how you define a CVE. If owning and controlling your device is a CVE/bug then sure you need a tight box with anti tempering as well.
Can you provide a reasonable definition where an authentication bypass in ADB doesn't qualify as a vulnerability? Is there a use case for allowing anyone on your network to run adb commands without your approval?
There are 3 things which I feel like are being confused here:
1. There was a genuine authentication bypass vulnerability in ADB (bad)
2. Initial proposed change wants to add an option to limit the ADB server to certain IPs or network interfaces (good - it doesn't affect you)
3. Response to the original request, proposing that ADB shouldn't be allowed to listen on loopback interfaces (bad/nefarious - it breaks functionality)
[1] https://nvd.nist.gov/vuln/detail/CVE-2026-0073
[2] https://issuetracker.google.com/issues/526109803#comment1
[3] https://issuetracker.google.com/issues/526109803#comment3
The act of "allowing“ negates the “without your approval“. You see the failure in the logic here I hope.
I thought we were having a technical discussion not a linguistic one. Baseline level of technical understanding is expected. s/allowing/enabling/.
allow [intransitive verb]: to make a possibility
https://www.merriam-webster.com/dictionary/allow
"An app can bypass OS security system with certain setting enabled" absolutely fits into CVEs. There's no "depends: on it.
I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.
Anything can fit into CVE.
"An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so.
"A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too.
Whether it matters or is something that should be addressed, is the depends part. Here we're talking about CVE that's at risk of trying to address a feature.
You are forgetting the most important questions of security, without which the whole discussion becomes pointless:
Who is securing what, and from who?
CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.
Apps being able to bypass a restriction put on them by the OS always matter.
Whether that means there's a _feature_ lacking there, is another question.
The OS provides restrictions and permissions so that the user can apply them to apps.
If the user chooses to free certain apps from restrictions, that should be their choice.
But if a piece of software overrides the users' choice, that certainly qualifies as a CVE.
This is an important distinction! The user must always have final say.
Whether an app breaks out of the sandbox and steals my vacation photos, or the OS sets new restrictions I can't remove, both are wrong.
Any piece of software has to act in service of the user, and ONLY the user. It must not do things or set restrictions without the users consent. No means no.
a lot of cves are of the type "if you leave the keys in the door, then anyone can unlock it and get in! We must destroy all doors, they are insecure!"
This is one of them
This is not one of them. This is "the lock accepts any key" type of CVE.
> In adbd_tls_verify_cert of auth.cpp, there is a possible bypass of wireless ADB mutual authentication due to a logic error in the code. This could lead to remote (proximal/adjacent) code execution as the shell user with no additional execution privileges needed.
Patch: https://android.googlesource.com/platform/packages/modules/a...
Docs:
> EVP_PKEY_cmp() return 1 if the keys match, 0 if they don't match, -1 if the key types are different and -2 if the operation is not supported.
The original code cast the integer return value to boolean, and -1 and -2 cast to "true", therefore authentication would succeed if the key types were different or the operation wasn't supported.
You jest, but passkeys seem to have literally been invented to address something like: "Keys to your doors can be used by anyone to open those doors, regardless of your knowledge or presence".
Which is a problem only if the third party acquired those keys without your permission, but the industry decided to "fix it" regardless.
I changed the sudo settings to not require a password.
Now an application on my computer can obtain root without user interaction.
Where is my CVE?
Same. There are so many things you could mess up without root from my account anyway. My account isn't a locked down one. You could alias sudo to a keylogger, for instance, and then do whatever as root the next time I sudo something.
So the password check really has no point. Typing sudo is still a lightweight sanity check, otherwise I may as well just log in as root.
When half that security is aimed against the user it's pretty easy to cheer for cracks in it.
Sounds like the Settings panel is a CVE, we should immediately get rid of it. And don't forget the Play Store!
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 against the original proposal possibly restricting non-loopback access, which would enhance security.
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 why do Google Play Services, etc. have full privileged access to a phone, including private data and phone call audio, but the user doesn't?
It is tech feudalism - you don't own anything anymore, you just get to live on the digital land of a bunch of ~trillion dollar companies.
At least, that is the goal.
IMO either everyone gets access at the user's discretion or Google has to sandbox their own GMS services as well.
Why? What other APIs should my apps (or the apps I explicitly want to authorize for this purpose) use to access my private data and my phone call audio?
So what official API call recorder app can use?
Because you know, the actual solution would be to have more granularity in authentication process than "allow whole device to attach to ADB", but that would be like, difficult... so they're not going to so that.
Right now any app on my PC connected to ADB could manipulate my phone then, and that's somehow not a CVE?
Is it a CVE that an app running on my PC could actually be running under GDB? It's the entire purpose of these tools.
In this case, the OS security restrictions should be questioned in the first place as excessive if a "backdoor" is necessary for normal function.
I am not sure I follow. Are you referring to the original CVE (?), I fully agree that it should be fixed, and it is not what my comment was about.
If you are talking about allowing listening on localhost - remote ADB requires enabling in the developer settings. It is a developer feature, similar to ADB over USB. If I'm charitable, it is possible that they are seeing too many people that are using Shizuku without understanding the security implications. But Shizuku has a lot of useful applications and they use ADB because the Android APIs and permission system are lacking and do not make these applications possible.
New CVE found in Bank of America app that may cause user to transfer money to hackers if they press certain combination of keys.
Actually that's what the whole fraud detection thing is about. If you transfer money wrong, they lock your account. Some countries like Sweden even went cashless so they can see all transfers.
More like if you have some settings enabled someone on your network can do it for you without your permission
More like the credit card company can initiate automatic withdrawals from your bank account without your permission if you previously authorized the company to do autopay.
"...avoiding OS security restictions by going through the debug port..." the user delibretry opened and paired to app with clear visual confirmation in order to use it.
Even if you have to deliberately enable a setting and enter a pairing code?
It's like saying that the fact the user knows their own password is a vulnerability because they might enter it to log into their account.
no, its a cve if the app can just do it automatically, it is NOT a cve that user goes through 5 steps that they very explicitly do, including unlocking hidden menus to open up developer options, and then allow it.
seriously, get real, please explain how your train of thought works here
Limiting ADB is the obvious next step. Even if this one specific feature request does not come to pass, Google has cornered everyone into relying on a developer interface for any normal personal computing tasks, whether running on-device or through USB/wireless. It's quite clear at some point in the future you will either be required to surrender your identity to them and pay a yearly fee or be severely limited to continue using it in any meaningful capacity, because Google does not want you to develop applications on Android outside their controlled channels -- and it's a developer bridge, the battle was already lost when they did not back down from the changes forbidding normal, legitimate ̶s̶i̶d̶e̶l̶o̶a̶d̶i̶n̶g̶ installation.
>Don’t even get me started on OEMs that force an audio warning such as “This call is being recorded,” when it’s in places where it’s not legally required.
This is also Google's fault. Their dialer--that OEMs increasingly pick over their own, despite their always being much better, see old MIUI one for example--just blanket applies the rule almost everywhere. Especially annoying on all MediaTek SoCs that do not support the feature on an hardware level at all through proper, reliable third-party applications. As if you didn't need any more proof you don't own "your" devices. But maybe in a couple years Gemini will be able to listen to the calls and summarize them for you, just need to go through the approved surveillance channel.
> As if you didn't need any more proof you don't own "your" devices.
Speak for yourself. Sent from my GNU/Linux phone Librem 5.
> As if you didn't need any more proof you don't own "your" devices.
Can you install your own OS? If yes, you own it. And Google consistently lets you do that. It other OEMs don't then direct your outrage at them.
>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 despite Google, you wouldn't even be able to do much that requires anything to do with SafetyNet and all successors delivered through Google Play Services, which is functionally the core component of any Android device for the near entirety of typical use-cases. And I'm not excusing OEMs, but they did not build their market share off of being "open" then start to close every door and trap you in it.
0. https://www.fitzsim.org/blog/?p=545
1. https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
> 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 anything?
> Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)
Why are you even asking Google at all? Just use Firefox? Don't even need to root or use a custom ROM for that, even.
> Hardly seems like a big deal?
https://news.ycombinator.com/item?id=49047638
>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 it? (see 1)
Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.
>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.
Practically speaking none of what you brought up are actually issues because once the phone connects to the internet once, it's unlocked forever, including after relocks/flashing. It's like saying you don't "own" the stuff you bought on bandcamp, because there's a split second between when you bought the song and when you could download it, therefore "It depends on a remote endpoint that can go down at any point, and depends on the company's policies present and future" and "It is functionally asking for permission to another party".
I don't think the bandcamp analogy applies. I may purchase a device with the intent of eventually unlocking the bootloader, but not doing so immediately for whatever reason, such as it still being supported by official updates, or the nth feature not being yet removed. Then the possibility of the option being taken away before you've exercised it remains.
1. It's unclear whether the online check is done when you tap the oem unlocking option, or it's done asynchronously in the background. If it's the latter, then it doesn't really matter because it'll get unlocked anyways.
2. There's no real disadvantage to leaving your bootloader in "locked (unlockable)"[1] state, because you can continue using stock rom and avb is enforced, but you can unlock it at any point using fastboot.
3. The Bandcamp analogy still applies because it offers streaming too (ie. web player), which means you could be happily streaming (ie. not downloading) and then one day they shut down, denying you access to all your music.
[1] https://i.ytimg.com/vi/rh6JxG0xE2k/maxresdefault.jpg
> Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.
Your example is about one developer's decision, which is not really what we're talking about. The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store? We're talking about restrictions laid down by the OS developer and for iding all applications outside of their crappy walled garden, which is very different. Also, you don't actually think Google is going to stop there do you? They will certainly turn it off one day of they think they can get away with it, because it is in their financial self-interests to do so.
>Your example is about one developer's decision, which is not really what we're talking about.
Is it? Many games outsource their anticheat to a third party developer, similar to how many apps outsource their app security to play integrity.
>The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store?
What about (nearly) all the games that only support windows, and worse yet, are exclusives on one distribution platform? Yes, there's wine/proton and cracks, but that's a "solution" in the same way that using a modded apk to get past the play integrity requirements is a "solution".
> Can you install your own OS? If yes, you own it.
Except all drivers and firmware are closed, so whenever the vendor decides updates are over, you have to replace the device or be insecure.
> 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?
>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.
And apparently a lot of people can't access their savings with grapheneOS. I know eventually I'm going to end up carrying 2 devices.
I have bad news for you if you think GrapheneOS isn't going to accept this patch from upstream if it lands.
Graphene would probably make it an option, like how it asks you if apps should be able to access the internet.
That's a non-issue because you can build (or patch+resign) grapheneos yourself.
But if you do, it fails attestation which turns the phone into a paperweight.
You think wrong, "mob" is a collective way of criticizing a policy.
Sure, there are differences in types criticisms, but then try to actually articulate those and address whatever you think the issues with those are
The implication in the blog post that Google developers somehow “overlooked” or “misunderstood” important use cases here, and if only they were informed about them they would reconsider, is frankly insulting.
Every single time any story has the words "Google developers" in it, they're behaving like arrogant, disconnected, anti-consumer jerks. From constant GCP breakage, to not acknowledging obvious Android bugs, to intentionally braking Chrome. It's a stark contrast to behind the scenes interactions with them.
If I didn't word it like that (I'm the author) the "reddit mob" would have exploded the thread. That's the last thing I want. I want valuable feedback there, for now its somehwat working.
Most of the users who saw the post on reddit didn't even open the blog post anyways, according to analytics.
Yeah, my favorite one is how Chrome users are not smart enough to handle case-aware web-page search toggle. Although to be fair their Chrome team is very arrogant even by Google standards.
I don't think the developers are bad, the problem are the top dogs that are telling them what to do.
Exhibit A: https://issues.chromium.org/issues/40093420
Decades of people desperate for a fix, utter stonewall from Google
Some PM somewhere decided that autocomplete belongs on all your fields, and who are you, the poor site developer, to disagree?
The moment an article like this hits HN or Reddit or any other such forum, any hope of changing anyone's mind is lost. The same happens to Github issues too. I haven't checked the isue myself, but seeing it here means it's probably already too late at this point, it'll probably get flooded.
Google does take feedback from app developers every now and then, but obviously their own teams' feelings on the subject are more important to them than some open source developers relying on a hack like in this article.
I think it should be quite obvious that the ADB daemon wasn't designed to enable call recording from an app initiating an adb session over a loopback address. https://xkcd.com/1172/ strikes again.
That doesn't mean the developer who wrote this is wrong to dislike the change: Google themselves have added call recording to their dialer a while ago so it's clearly a feature they stand behind. That doesn't mean the adb team shouldn't do a little security hardening, though.
In 2008 Sergey Brin and Larry Page saw the limo waiting, and instead chose to rollerblade to the Android unveiling. Sergey Brin, during the presentation, threw his G1 in the air to show off how his homemade application leveraged the accelerometer to see how high he'd thrown it
That use-case was never designed for when the sensor was added, and is every bit as hacky and fun as adding call recording with a loopbakc address
And that's the first problem: Android is no longer fun, and it's no longer for trying this hilariously stupid hacky method of doing what we, the users, want.
The second problem is an attitude of "Google's dialer has it built-in, why would one want a third-party dialer instead of Google's?"
Because we fucking can - or could, at least. The OS was designed to be as modular as possible, to the point where, while iOS still can't change their launcher, Android has had that option since day one. Setting aside Google casting themselves as the (not so) benevolent dictator of "Just use our apps exclusively. Life will be easier that way", closing off the modularity is antithecal to the Android experience that so many geeks fell in love with, and arguably made the platform what it is
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 games. Can't do pretty much anything.
That's the future of Android. GrapheneOS is quite literally the last hope for Android, and only because by some miracle there are companies out there who started trusting Graphene's attestation keys. If that hope ever dies then we might as well buy iPhones.
> and only because by some miracle there are companies out there who started trusting Graphene's attestation keys.
Are the bank apps trusting graphene keys or google them self? Isn't play attestation completely in the hands of google.
Play Attestation is a Google hosted database of build keys/hashes for known Android builds. Android-side of this attestation is an API which calculates and returns those hashes to the app.
There's nothing preventing the app from verifying the build itself against its own database. So they can allowlist GrapheneOS builds if they want - but of course that means that all other ROMs are still banned.
Agreed, GrapheneOS is underrated.
> GrapheneOS is quite literally the last hope for Android
Don't they support the idea of the hardware attestation and having no root?
> Again, this is not a technical problem (the mindset of Google)
This is not even Google's mindset, the control strings of this mindset stretch far beyond its management and board of directors.
That's the OBEY from the timeless Carpenter's classic.
Of 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.
Many alternative AOSP-based systems work fine today and do not have the new Android Developer Verifier (wow, already rolled out to 500M+ devices [1], though still dormant).
To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick your phone, etc.
[1] https://play.google.com/store/apps/details?id=com.google.and...
We used to call programs like this, that allow someone to remotely break your system, a Trojan horse...
and now people install Remote Access Trojans just to let GPT and Claude think and work for them, granting them shell and a11y access. really? after seeing that, nothing surprises me
Yes, really. The obvious answer that security maximallists deny even exists is, who is doing it and why. In LLM case, users are doing it themselves to allow a way of computing they want and find useful, in spite of platform locks designed to deny users just that.
I mean, go tell Anthropic to prompt Claude to make it adopt Landlock in Claude Code instead of regex-based filtering. actually adopt it, not how Codex did, but with controls on the level of some third-party harnesses and Pi plugins.
> To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones.
Are any commercial mobile phone vendors not able to do such a thing? Do remember that this giant kerfuffle is all over the seeming preparation for the apparent removal of a developer feature that iPhones have never had at all.
> brick your phone, etc.
Apple can do the same for iPhones. In terms of dark shit they can do there's no difference anymore.
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 before, puts existing features behind paywalls, etc. people are rightfully outraged, because it breaks the social contract.
It's just that the repeated offenses have made us insensitive. Imagine Debian rolling out some mechanism that only allows you to install software outside their repos with a 24 hour delay. It would destroy Debian.
>implicit social contract
Sounds worthless (in court).
And that's how you get a low-trust society.
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.
Google is working on a new recaptcha strategy to counter that. Essentially any non Google flavor of Android OS will fail recaptcha validation
> will we have a viable alternative to jump ship before that happens ?
Here is a better question:
"Is the EU going to stop this?"
No because the EUDI Wallet needs Google Play Services. People need to come to the realization that the EU has no interest in regulating the freedom of devices because the EU itself is benefitting from the closed-down ecosystem.
Why would the EU stop it?
> "will we have a viable alternative to jump ship before that happens ?"
GNU/Linux phones already exist. Sent from my Librem 5.
This is huge, Android getting locked down to such levels should be sounding alarm bells. They are slowly removing everything that makes Android good.
As far as I can tell, this is a big overreaction to a misunderstanding.
I'm a developer with remote adb enabled, using it in the normal intended way (to install new builds of an Android project I'm developing, retrieve log files related to it, etc). Currently, I access this via VPN (tailscale), but it's exposed to connections (and any pre-auth security vulnerability risks) on any random public wifi network I connect to. Adding the ability to restrict this to just tailscale will be an improvement, for me.
The proposal at the top of the thread is that you specify which interface you want it to bind to, when you set up remote adb, rather than binding to every interface. Nothing in that proposal suggests that "localhost" would be rejected as a choice of interface. One person suggested binding only to "wlan0", but that was a short throwaway comment that is obviously wrong (wlan0 is less-trusted than VPNs) and obviously not what they're going to do.
The person who made that suggestion (sa...@google.com) is presumed to be the one of the main maintainer of ADB as their name (Fabien Sanglard) showed up in non-redacted in the history and CC here (https://android-review.googlesource.com/c/platform/packages/...) after it was linked in the original Google IssueTracker. We can confirm they are a Google employee as per their @google.com top domain name. (For users reading, please don't target this person, it won't change anything AT ALL, i'm stating this since its public informations, and for proof)
Their email is also in the CODEOWNER of ADB, and they made the recent ADB Wifi 2.0 presentation at Droid-Con Paris.
They stated, "Connection to localhost has also been the source of exploits where apps are using that socket to adbd to escalate their privileges," which suggests that internally they viewed it primarily as an exploit bad actor uses. Without feedback, they would most lickly not consider changing their point of view, this is why the blog post was made.
The article shows that this is technically possible for bad actors to use it, assuming the user allow it, but highly unlikely in practice: https://kitsumed.github.io/blog/posts/android-may-soon-restr...
I do agree, however, that many of the comments, mainly on Reddit, blow the issue way out of proportion. Based on the website analytics, I can also confidently say that most people didn't even open or read the blog post. That's fine with me, though. My goal was to get the attention of actual developers and more technical users.
I have been very carful in the blog post not to write something too dramatic like some news outlets do, but if no one read it, I can't do anything about it.
EDIT: I have purposefully left that person name out of the blog post I originally made to avoid encouraging people to message them directly. However, if I need to update the blog or publish some kind of follow-up with supporting evidence, I may end up linking it. I'm not sure tbh.
Thanks for clarifying, if your read is correct and they're just putting more control in the user's hand then this isn't an issue at all
I am worried that this might happen to websites soon.
If you want your website to be openable on Apple devices, you would have to pay Apple a fee each month. If you want your website to be openable on Android devices, you would have to pay Google a fee ecah month, etc.
I am worried that this might happen to websites soon.
You mean the new recaptcha that requires remote attestation?
https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
Obviously, it doesn't have the fee part. But Google can decide soon for a substantial number of websites which devices can visit them and which not.
I am thinking how this would split the web.
You would have the "new web" consisting of the top n major websites paying this fee.
And then you would have the "old web", accessible only to people still owning their own PCs with unrestricted browsers. And probably heavily scrapped by AI companies to reguritate to the masses through the new web.
That's already the case for Netflix and other video streaming services.
You don't have to pay a fee directly, but you can't use open source web browsers.
we can just fork android
edit: I not realizing that I been replying to wrong comment
Ah yes, Android without the Play Store.
So you won't be able to use your banking apps, your local transport app, public services apps, health services apps, etc.
But sure, you can do SMS (no RCS though), use the device calculator, and maybe browse the Web… until websites kick you out because your non Chrome/Safari browser isn't supported anymore. Even Signal won't work well due to the lack of FCM.
And I'm a GrapheneOS user happy with Obtainium and without Play Services installed in main user space.
I always disable everything Google that comes preinstalled other than maps, including the App store. You can download stuff that you can only get there through Aurora, but really most of what I use comes from F-Droid.
Not that I trust a device running Android enough to do banking, mind you.
the situation is not ideal but this is the best we can do
We need Linux on phones. Bank apps not needed as long as I can use browser. But do need some things like wireless cards, popular apps like Sonos and Spotify working.
Unfortunately many banks in the UK no longer offer a web portal or physical branches.
I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly.
(I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)
Good news for EU citizens though, PSD3 will require that authentication methods without a smartphone are provided:
https://ec.europa.eu/commission/presscorner/detail/fr/qanda_...
Require payment services providers to ensure that all users can benefit from methods to perform SCA which are adapted to their needs and situations and, in particular, that those methods do not depend on one single technology, device or mechanism, for instance on the possession of a smartphone.
Wise in the UK currently is good. You can use it completely without a phone app. It also has good support for passkeys, TOTP, and SMS OTP, allowing to add multiple of each as it should be. If you do choose the Wise app, it currently warns when you run a custom Android ROM, but let's you use it.
Our company also uses Revolut business, but that requires a phone app to verify online payments with cards. And Revolut recently changed the app so it now requires Google Play Integrity so it doesn't work with LineageOS anymore. So I'm looking to move all new things away from Revolut. I have little patience with companies that want to unbank my company, and decide what hardware or software we use.
Fun fact that is in Russia major banks are sanctioned and had their apps removed from App Store and Google Play so banks forced to keep mobile optimized and fully featured web portals for iOS users.
Huh? Why the hell would you use a bank that doesn't offer a web portal or have branches if there are banks that still do?!?!
I bank with HSBC in the UK and there's still branches (worldwide) and banking via web.
I assume you mean things like Starling and Monzo in this case? Banking with them is simply dangerous.
There's mobile payment apps worldwide like yappy and UPI, that don't have a web interface and are local monopolies. Even worse they are sometimes controlled by a single large bank, not a government and not a consortium so you're entirely beholden to their (confidential) decisions, whatever they might be. It's not like in the US where you have Venmo, Zelle, and Cash app, or China where there's WeChat and alipay.
What's wrong with Starling/Monzo?
They’re only ok until something goes wrong or you end up with an overdraft. Then they screw you with poor customer service. Like the worst.
> many banks in the UK no longer offer a web portal
Same in Norway.
Is it that dire? I'm in with DNB and Nordea and they both have functioning netbanks. But I don't know how the rest are.
I've been getting by with a bankid codebrick and web browser access (although Nordea and DNB apps work fine on GrapheneOS).
> I'm in with DNB and Nordea and they both have functioning netbanks.
And both are banks I'd never want to associate with. I would have used Sbanken before the DNB buyout (and I even did for a bit!), but now that's of the table too.
There are a few more options, but many are just worse if you look at their fees and interest rates.
I've been very happy with Bulder. The only thing they're missing is a web portal. The fact that they're missing that annoys me greatly, but they've been good to me in every single other aspect, so it's hard to be dissatisfied (especially compared to the other banks where I and others have been burned). Their app works fine on de-Googled Android, and so long as that's true, I can live with my choices.
I appreciate the info. Re: the banks I'm with, I have no choice.
I'm an immigrant and most banks refused to give me an account when I moved here. Or ghosted me during the months long process. These are the banks that let me live here, and actually gave me an account and bank id. It's the only real choice I have until I get citizenship.
If you're stuck with them, that's understandable.
There's no reason the banks should be dicks about it, but they often are in cases like yours. All the accounts I've opened in recent times have just been a matter of logging in with BankID and going through the form and selecting 'no' 10 times. Once you've got BankID and can go through the automated flow, there shouldn't really ever be any issues.
This is why it bothers me greatly that BankID is still controlled by the banks, since they can just decide that someone like you shouldn't get it. It should be government issued and issued to everyone, on the same level as an ID card or a passport.
Poland, all banks I know offer web portal. Linux, Firefox - works perfectly.
Follow up question: how many of those still let you log in and authorize transfers without relying on their mobile app as required second factor?
Good point. They don't. Huh, that's really worrying. My bank started requiring phone for web portal only about a few years ago. They don't allow to use an alternative MFA method. This should be made illegal.
It should be. How screwed are you if you lose your phone?
Don't fret, the govt has this covered: RFID chip up the ass to the rescue!
This is all inevitable direction over long period of time
What’s worrying is that noone protests about it
It doesn’t suprise me that corporations and governments want the laziest, most „protective” laws passed that extend their power. But why noone, absolutely noone puts some kind of resistance to it?
Government and citizens are at eternal conflict of interests. It has been this way and it will be this way forever.
Your job as a citizen is to make sure you have greatest amount of liberties
Noone will do it for you.
The frogs are almost done, and the silicone figurines that used to impost actual frogs and croak how pleasant the water is and how it should always keep getting warmer to keep everyone comfortable, will soon be removed from the pot, their duties fullfilled.
Need to pressure banks to achieve feature parity between their websites and native apps. I'm forced to use Paypal to remote deposit checks because my banks limit that feature to their apps, which I can't use because of my device's age. (Paypal does, too, but their app still works for now.)
Unfortunately these days bank apps are required by the banks for "security", and good luck getting anything done without the bank app installed on your phone.
The only other alternative available is SMS but that is being phased out (rightly so) for being insecure.
Currently my bank requires a device where I need to insert my card to get a one time six digit code based on a QR code the banking website serves me that the device scans.
I'm not quite sure why they don't support something like a yubikey with FIDO, but maybe there's a good reason.
ING supports hardware keys in some markets, so there's no reason not to.
Every bank here had that. Now they all require apps.
For the banks I understand. Now they don't have to supply millions of code calculator devices. And they force their apps which they can stuff full of tracking to mine their customers for data they can sell.
It's sad but part of the usual enshittification cycle
because it's so niche it's not profitable to implement
I use my bank's website on my phone and desktop.
We need unlockable bootloaders on ALL phones. Then many more OSes will come
Pixels do have unlockable bootloaders, but they also have a non-unlockable hypervisor that would snitch on you and make some apps refuse to work.
<https://puri.sm/products/librem-5/>
https://sailfishos.org/
Android is Linux on phones ;)
And MacOS is Unix on Macs?
GrapheneOS is what you're looking for
Lots of questionable replies to you here, people recommending Android/Lineage/Graphene are being silly, Sailfish is a better answer but with major proprietary components I would still skip it. postmarketOS is the best option I believe. Mobian and some others possibly worth a mention as well. I found Ubuntu Touch/ubports to be disappointing so I wouldn't bother with that either. You can check the pmOS wiki to find compatible devices. Perhaps check first if anything you already own has support, and help them support your device better if you are able. Otherwise look for the devices with the best support and get one off eBay. Librem 5 and PinePhone should be among the best supported devices but you may get better performance / $ with a OnePlus 6T or other formerly-Android phone (again, verify most stuff is already working before buying something if possible).
For the popular apps you mention, there is Waydroid to run Android apps.
There's only one reason for anyone, or for me, at least, to choose Android, and it's the only reason I've consistently chosen Android from the very first Google Developer Phone: It's more open.
So, they don't want me to even have that one reason to keep choosing Android, I guess.
the question isn't whether you still have a reason to choose android - the question is what alternative do you have but android (or iOS).
If my phone is going to be locked down anyway, I'm choosing the platform that at least pairs with my AirPods properly and doesn't get me weird looks at social events.
Google is really stretching their goodwill with this one. The ability to sideload and debug my phone is the only marginal benefit to these janky Java relics. If that's gone, no reason not to switch to a wholely better platform.
If I don't get weird looks at the kinds of social events where everyone else has an iphone, then I have failed at life. I can think of no greater horror than to be seen as uninteresting.
Looking what's this is about - Shizuku
https://github.com/thedjchi/Shizuku/wiki/setup
So it requires
* Enable Developer Options if not already enabled (Generally, this is done by going to Settings > About device and tapping Build number 7 times).
* Enable both USB debugging and Wireless debugging. Tap "Allow" if prompted to allow wireless debugging on the current network.
* Tap Pair device with pairing code.
* Downloadd other apps like ShizuCallRecorder
Or seems to be exactly what this user described.
https://news.ycombinator.com/reply?id=49046291&goto=item%3Fi...
finally my children will be secure and my bank account impenetrable!
/s
It's this stuff thats caused me to start degoogling as much as I can. I've started using nongmail emails and removing photos.
I Don't know what else I can do though, next up is switching to grapheneOS but I'm a ways off from that for now.
I was thinking a lot about how these restrictions are paved with good intentions, but every time these new security measures are implemented we see criminals adopt new strategies and continue going about their day like nothing ever happened.
I've been seeing this specifically with ID / business verification requirements where they just have some innocent (or sometimes complicit) third party grant them access to verasign 'verified' trust signing keys which actually makes them way more trusted than they were ever before often making anti-malware applications way less strict about blocking it which in turn buys them just enough time to compromise the system and disable said anti-malware applications. The problem here is that anti-malware applications try to be seemless and are effectively in a giant race condition to terminate the application, more recently microsoft anti malware service will now block program execution until it validates that it is safe. Although it is not something other companies do as making the device feel sluggish is something they avoid at all costs (looking at you bitdefender).
> This feature was proposed following a major security issue identified as CVE-2026-0073, which allowed the Wireless ADB authentication process to be fully bypassed. What is proposed in this issue is actually a nice idea.
Clearly this is not an issue when the wireless authentication process works as intended. I see no need to change that at all. They just need to fix that bug.
It's quite difficult to do this. You need to enable wireless debugging. Then pair to a random port with a random pairing code and then connect to yet another random port. When it works as intended it's more than secure enough.
If they really want to restrict it, just let the user choose in the development settings what interface to listen to.
https://archive.ph/gla4i
In case it is made private.
This assumes user is the only person with physical access to unlocked phone.
All sorts of goverment agencies, airport security, even teachers now have access. And such attacks can be trivially automated, so even low paid worker can do it.
This is solvable by adding big huge warning that ADB is running. Not by removing feature.
That huge warning would also be permanently shown for everyone using Shinzuku apps. I think that UX would neither be desirable nor increase security.
..for the very little number of people who use them?
Arguably it would be highly preferable compared to the option of not being able to use them at all.
Just use opensource phone os!
android is open source
Step back to the other issue (referenced in the page*), that Google would pushing on devices something that blocks applications that do not come from play.google.com . Was it not established that Google can only push that update on devices with a google account?
* https://keepandroidopen.org/
Google is going the Apple route. When will we get the year of the Linux Phone?
For the longest time the free software foundation (well Stillman) were against all mobile phones because of their ability to track people. In the last year they have finally admitted that they were not going to win that battle and have gone head first into trying to build a fully open software stack.
Not saying it will be good or arrive anywhere in the next 5 years but they are very persistent and that tends to work in their favour.
https://jolla.com/
The apps that are the reason some people use smartphones at all — bank apps — require Google services and remote attestation that runs in an environment with more privileges than the OS kernel. Otherwise everyone interested would just unlock their bootloader and use a ROM with all the asinine restrictions removed.
I use postmarketOS btw...
Android Wireless debugging is already a major pita to work with. Requires a wifi connection to even work, so I need to carry a mobile wifi router with me, instead of having it bound to my secure WireGuard connection. Next it assigns a random port number every time the wifi connection is interrupted, or when it considers now is a good time to reset the port number. It should be possible to set a stable port and and have it available, perhaps behind a few awkward UI/adb toggles.
Thank you for telling me about Shizuku! Android world is so vast and full of resources
> Android world is so vast and full of resources
and google is doing all they can to try shut it down, because they saw how profitable a walled garden like iOS really is.
Android had a tradeoff - less vertical integration and more annoyances, a bit worse software quality, for a more open, customisable and utility-like experience. I loved that.
Now, the tradeoff is - less vertical integration, double the integration layer trash (Google & OEM) and a much more locked down experience. But the quality of it hasn't improved, it just got worse.
Doesn't make sense anymore. They can now do 99% of the same things, but iOS has a better quality OS, better apps and better vertical integration.
Not even vertical integration, actually just any kind. FFS it's 2026 and the recommended android way to send a photo to your mac/PC is "upload to google photos and hope it decides to sync".
> send a photo to your mac/PC is "upload to google photos and hope it decides to sync".
and conveniently, google now has access to your photo, the meta data, and potentially able to scan it for advertising purposes.
and hopefully the other scans won't trip a false positive that leads to your inconvenience/death
Amazon crippled the ADB functionality on FireTV Sticks a while ago. Making it an absolute pain to build and debug TV apps on. Currently, the only way to test is to install a release build every time.
What I find most annoying aspect of all software from 2010s onwards is this stupid discourse and associated results:
- some people want A, or A might even be already in use
- A is problematic for $MODERATE_OR_MILD_REASON
- B is introduced and made default
- a config switch between A and B is never considered
So, so tiring. If I want to bind ADB to localhost, _let me_. It's my device and my problem, ffs.
Toxic max security.
Not everyone has the same threat model as you, $BIGTECHCORP.
Isn't security just an excuse to push user hostile features?
Like, if security was a concern we would have simpler systems and still use 2fa devices for banks etc.
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.
Hides memory leaks
Right, that too. But that's a reason to recommend regular reboots[0], not to force them, and "3 days of inactivity" is a suspiciously specific time that I also saw mentioned in Android settings somewhere the other day.
--
[0] - Which I find deeply ironic, in that merely a decade ago, people would laugh at Windows with its "reboot after installs, reboot in case of problems" approach, and now frequent reboots are seen as Standard Security and Stability Practice on *nix systems, both mobile and server-bound...
I have no issue restarting my iOS/Mac/Linux machines because the time to get back to doing fun or productive stuff is measured in seconds. And usually you only have to restart one time. Windows used to take ages, and often you’d reboot only find out that something else that requires a reboot only triggered because of the previous reboot, so you were sometimes in for 2-3 restarts.
It’s not like that anymore in my experience at least but the stigma stuck.
They dont care about security; only about control.
There are hundreds of millions of outdated Android devices that all Google attestation systems consider secure even though they all running Linux kernel that was never ever updated and can be rooted by anything.
Now try to install your own firmware on them without said outdated kernel... How dare you.
Technically the security works, just for their threat model. An exploit would need root and root means you likely cannot pass attestation AFAIK. The fact that this same exploiter can download all your contacts photos and texts is immaterial to, say, Disney, who want attestation only to prevent ripping of their content.
No it doesnt actually work because its possible to do privilege escalaction without tampering with firmware or filesystem or triggering other markera. OS will be practically rooted while passing attestation just fine.
Only things attestation do is security theater and messing up people ability to use software of their choosing.
Security, but not for you, is no security.
Have you read the android security model? It's a multi party security model which considers apps and users as equals. It's a legitimate security model and just because it's not what you want doesn't mean it's wrong.is it user hostile? Maybe. But that is different than saying it offers no security. It's also not worth bickering about every small decision that is made in line with that security model. If you want a different one, push for it via alternative OS.
Ask Jeeves toolbar disagrees.
It's not even "max security". We are talking about those big tech corps which are infamous for sharing all of your private information with the government, and analyzing it so as to manipulate you in to buying things, and possibly for other obscure commercial purpuses.
They securely share your private info with their advertising partners. You know that no hackers that didnt pay google would get access to that information.
Google doesn't want you to be able to skip YouTube ads. It's as simple as that.
More specifically apps and users have equal agency in the android security model. Which comes down to the fact that if you don't own the app you can't control its experience. This feels grounded to me. Push for more open source apps where you retain control and ownership.
No, I bought the device, I should be able to do whatever I want with it.
It's already hard enough that we can't mess with apps' internal storage without rooting IMO. It's my device. I should be able to inspect what every app is collecting about me. Just like I can on windows.
IMO the user should always be the top admin on a device they own.
It sounds like you are just at odds with the android security model: https://arxiv.org/pdf/1904.05572
Indeed I absolutely am. I don't believe in this model where we have to trust some big commercial party for our security and privacy. And they abuse this all the time, both Google and iOS.
The problem is though that I have no choice. iOS is even more locked down and distrusting of the user. It's never even had a bootloader unlock option for example. And not using a smartphone is not possible in this day and age.
And app developers have the right to not offer their services to users who don't give them the security model they want.
You are free to install a custom OS which provides you the security model you desire. You have choices.
No, when you can't participate in modern society without specific apps, I would argue those developers, in fact, don't have the right to not offer me their services.
No one's requested the config switch from A to B with a restriction that's acceptable to those seeking B. Idealism doesn't tend to offer compromises, and so Idealism tends to lose when it doesn't make a convincing case to regulators. Here's a simple and easy to implement example compromise that could be offered today:
"Changing between A and B requires a device reset."
Most people are going to flat out refuse to wipe their device for a phisher, especially since it'll log them out of everything and trigger all sorts of "new device on your account" warnings everywhere if it's done without their knowledge.
Sure, this is mildly annoying for the 1% that have good reason for A — but it's annoying once per device rather than losing A for good as is happening now. Sure, Google will deny service to A. They're doing that no matter what, either b/c they remove A or b/c they deny A, but this forces them to construct and defend a case for why users who went through the hassle of wiping their device to switch to A ought to be denied access to the app store, and that's a critically absent case in regulatory circles right now. (See also Graphene vs. the EU age check app.)
That's all it would take to protect B from A, but no one asks for it, and no one presses Google publicly for it, and so of course Google isn't doing it. No megacorp will help you walk off the Golden Path without some sort of extrinsic pressure. I see a great deal of clamor around wanting A, but absolutely none of the 'here's a mild annoyance that we came up with as a valid and safe compromise' clamor that would make them look incompetent in the public eye, provide further leverage for EU antitrust steps regarding Android itself, and give them a way to continue to protect users who need B for safety, while allowing those of us who want A to pursue it.
Perhaps other styles of compromise exist, too? As far as I can determine, no one else is thinking about this in terms of "what compromises will developers offer that continue to protect non-developers?", and so I have no other examples to offer. I'd sure love to see more ideas, more effort invested into offering serious and real compromises rather than inflexible resistance of every real safety improvement.
>a config switch between A and B is never considered
And why should modern corpo maintain additional complexity to pander to 1% of privacy-aware tech-savvy users?
Every time I want to connect ADB to a device, it takes me far more time than it should. Having different ports for pairing and connecting is already a pain. I wonder what new hurdles will come up once they restrict adb to wlan0, even though atm I can't see any problems for my use cases (like pushing APKs, reading logs or connecting dev tools).
Not being able to use VPNs might be a problem in corporate setups (e.g. debugging an issue in production environments).
Dies this affect GrapheneOS or CalyxOS?
I assume Sailfish and Ubuntu Touch are completely unimpacted?
Call me crazy but that actually makes sense. ADB is clearly meant for one device to control another, otherwise it's just a hack to bypass sandboxes.
That would make sense if they hadn't first taken away the user's ability to control their own device directly. Some people were OK with that because users could still use this hack, but are presumably less OK with it in retrospect now that this second step finishes the job.
I'd be interested to see whether this comes with a replacement for legitimate use cases. Removing a capability without offering an alternative tends to push developers toward even more fragile or in some cases "rule breaking" workarounds
The On-Device ADB work-arounds and a lot of open-source apps related to it are already in that fragile workarounds "zone".
For most, this is the last resort / only way possible. As AOSP refuse to add secure permission or services to allow third-party application to do specific actions.
If this get fixed, it will be the end of thoses project on-device for non-rooted ROMs. Sure, you could still run it via a computer, or to be far fetched, start Shizuku via a computer. But that's no longer "on-device". It kill a lot of usages, including developers who need it "on-the-fly".
I switched to a MacBook b/c I couldn't find a comparable PC laptop
I feel like an iPhone will be next. Good Android phones are already pricey
why not cut to the chase and simply remove user access to devices? preventing non playstore installs and restricting adb are addressing symptoms, user behaviour, not actual security issues.
RIP android.
I just installed CachyOS on one of my laptops. I like Open Suse a bit more, but my vpn and a few other applications work better on Arch.
Android is turning into the iOS/OSX/Win11 model. It’s not your device, you’re just renting it.
You need permission to install applications, or do anything else outside of consuming subscription services.
Where are the Linux phones ?
Linux phones exist but work on a limited number of devices (see PostMarketOS) or Linux primary devices like Purism or Pinephone (which I've heard are expensive). That's the primary issue, you either need to buy an expensive and potentially underpowered phone OR have one that is supported most of the way with PostMarketOS (Wifi, SIM card, GPU, etc. sometimes may not work even though the phone can boot PostMarketOS).
I personally don't have a problem with a mediocre-performance phone but it should not be expensive. Not to mention app ecosystems - there aren't a lot of Linux apps for Linux phones.
I've paid 200€ for my PinePhone. It is underpowered, but at least it doesn't have to waste its resources on rendering ads.
Where Android/iPhone users have "apps", I mostly end up writing small shell scripts around existing linux tools. My alarm clock "app" is realized via cron jobs; my TOTP "app" is a one-liner around `oathtool`.
Messenger apps are a bit tricky; I'll probably end up hosting my own matrix homeserver and then have bridges running for Signal and the likes.
There are plenty of apps for Linux phones because you get all of the Linux software automatically. What there isn’t plenty of is commercial pop culture apps from social media companies, banks, and other businesses but for some of those you can run an android emulator or use their website.
LEA, Customs and intelligence agencies regularly use GDB to hack and extract information from an Android phone. So in that sense it may be a valid concern and reason to restrict this.
However, I'm pretty sure these entities will already have negotiated exemptions from the restrictions so in that sense they don't add much security.
Yeah, and they regularly use USB cables to do that too.
Can they ruin it faster i am sick of it already. Need to root the phone to get basic functionality, i need like 6-7 magisk modules to do basic things. I can't access file system on device i paid 250$. I have to use adb to change basic things, i rather use symbian.
Symbian pioneered this bullshit. Having to sign apps with Nokia keys just to install them was a thing since the days of S60. And it all went downhill from there.
> on device i paid 250$
It doesn't get better even if you pay 2500$, which is extra silly.
This is about control, not security. As in, Google's control over your device, your experience, your features and choices. This and Google just isn't interested in supporting an open OS anymore. Maybe they think it makes them liable.
Either way the writing is on the wall, and has been for a while.
Apple did this since day one on 2007, no one bat an eye. If we want this to be fixed, IMO, we have to do this in politics.
Locked down hardware vendor's proprietary ROMs maybe, true open source Android not so much. Unfortunately one of these matters more then the other.
IIRC 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.
Guess it's time to contact support for the few necessary apps that still don't work on GrapheneOS.
So glad we're becoming as locked down as iOS
use encryption and keys for all socket connections to adb, listen on 0.0.0.0 and unify the wifi thing with the socket thing, add an app level permission that allows apps to access an ephemeral system key via the binder to enable libadb style usecases?
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.
> The internet, as it has been, is quite an anomaly
It's not an anomaly, it was the data grabbing infrastructure, and now that enough data is vacuumed in from it to train AI, it is now time to turn this dangerously conductive communication network into a control-only one, by all logic of the process and those who funded it all the way.
What's ironic is that these news are something you'd expect to hear from China or former Soviet countries. But frogs still believe that "putting America in the same sentence as Russia" is stupid
I'm sick of having my shit be locked down because of "security".
Do these people even know tech illiterate people? They couldn't enable ADB even with instructions.
I'm so done with Android and iOS. I already carry around 2 phones because neither will give me exactly what I want, maybe it's time for a 3rd running Linux..?
Linux phone is already a thing that exists and is at a point where it can be used by tech illiterate people within the confines of what is possible normally.
It's just that few people bother using it. But that number might increase if Android continues it's war against its users.
i am not running stock ROMs and neither should you
We will end up having a gov phone and a personal phone at this rate.
Would rooted phones still be game? I am fearful as this ruins all of my home built AI apps
Looks like some developer just suggested an idea. Doesn’t seem concrete.
If they stop sideloading and adb why should I even stay with Android?
adb is not being stopped, the bug is talking about a niche way folks use it without a secondary device. There is also no conclusion from the bug on what action will actually be taken.
TINA - https://en.wikipedia.org/wiki/There_is_no_alternative
And people wonder why we're in the rut that we are.
Sidenote: The poster in that article is insane to me. Imagine advertising yourself as the only alternative. I'd rather vote for an empty seat than for someone who's that arrogant! Then again, I don't really have to imagine it, since there have been quite a few politicians within the last 10 years who have functionally done that same, just without actually saying those words out loud.
Increasing constraints will turn people into marionettes.
In this scenario, it means shutting off more possibilities.
goodbye shizuku i guess, and maybe termux
Shizuku has a big banner on the PlayStore telling me it can't be installed on Samsung S26, it's not old enough.
RIP phones
And I might soon restrict use of Android and iOS in my life. Because of this nonsense, how will I get around the app issue is something I am still trying to figure out but I won't pay money to companies that make my products(I own them after I bought them) worse bit by bit anymore.
All this is happening in a country where it's legal and OK to make unsubscribing from a paid service nearly impossible.
I mean it's OK for the crowd here, because amongst us are people who created the technical backends to let these rackets going.
Do you want your smart TV to become a persistent access point to your home network? If not, you should prefer to have an explicit unbypassable confirmation before another device is allowed to install arbitrary apps on it and pregrant them arbitrary permissions.
I'm sorry but F* Google.
They started with "we love open" and when became virtual monopoly they extort the position :/
> Scenario 3: A Developer Using ADB over TCP/IP
- You install a malicious application.
- You enable USB debugging, starting ADBD.
- You connect via USB ADB to enable TCP/IP, then disconnect the USB cable.
- ADBD continues running and listens on all network interfaces.
- The application initiates a connection, causing an authorization prompt to appear on the screen. If the user selects No, the connection is rejected. No silent exploitation attempts are possible.
I understand the author's rationale and think the reasons why that whole ecosystem is accessing ADB are legitimate - but I have some questions here.
The above flow is basically what apps that use Shizuku have to do as well, right? Only that in that case, the user would deliberately install the app and have the knowledge it uses ADB features and therefore would also confirm the permission prompt.
However, ADBD in this situation only sees a connection attempt, not which app made the attempt, right?
So it also cannot remember that a particular app was already authorized by the user and has to display the prompt again on each connection attempt?
Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?
This seems honestly like Shizuku itself would increase the risk of a user granting ADB access to a bad actor (i.e. a second app or external connection that is different from the app the user wanted to authorize).
Thinking of "scenario 3" if a Shizuku-enabled app is already running on the device and something else wants to connect to ADB:
- I'm assuming a malicious app was already installed (without privileges) or something tries to connect to port 5555 from outside or via proxyware.
- ADBD is already running and listening for TCP to serve the Shizuku app, so those steps can be taken for granted.
- The malicious app or connection triggers a permission prompt from ADBD. However, by that time, the user has grown used to those prompts, because the Shizuku triggers them frequently, so they are more likely to select "yes".
If ADBD has no information about who is connecting, it also can't show any meaningful information in the prompt. So it cannot really help the user distinguish prompts from the legitimate Shizuku app from malicious prompts. A user still has the timing and context to distinguish prompts, i.e. prompts that appear out of the blue when they aren't using the app are suspicious.
> However, ADBD in this situation only sees a connection attempt, not which app made the attempt, right?
Every ADB connection has some kind of certificate / key that is saved locally. This means that a new application would have a different certificate. That certificate is shown in the yes/no prompt.
> Does that mean that a Shizuku-enabled app would prompt the user again for ADB access any time it's started?
You can tell android to remember that certificate and allow the connection next time. There is a bug that make it not work on certains specific version of Android 12 I think, but outside of that, it always works.
Ah, that makes more sense and then of course the scenario would not work that way. Thanks for clearing that up!
Another day of AI another day of AI not being able to maintain useful features people used to take for granted
These are not accidents. Google declared total war against open source. You only need to remember how it declared war against ublock origin. In the long run this will also fail, but until then Google causes a lot of damage. Legislation needs to control this tyrant but unfortunately the oligarchs run the country of the mad orange king right now.
Louis Rossman will have a field day with Google here. I think it is time to end Evil - that is, to end Google. This company serves no more useful purpose on this planet anymore.
It's frankly amazing how many Google developers will associate their real identities and contact info with such hostility, believing they're invincible.
Perhaps they should be subjected to the full force of the First Amendment.
I'm more curious to see how the second ammendment could factor into this.
lol, keep hoping
...why? Android is the holy grail of freedom, since iOS never was. It's gotten worse since ~2024, despite the lawsuit.
Or maybe Google is genuinely about thinking this in good faith. I can't see how, though.
To quote Scott McNealy, then CEO of Sun microsystems, circa 1999:
"You have zero privacy anyway. Get over it".
It has become truer every year that has passed since then.
The 2026 version : "If you believe you will be allowed to keep any kind of control over the devices you "own", you are deluding yourself".
The article overlooks security implications from spyware, which is a huge problem not only for financial applications, but personal safety, too [0].
Per FTC, a stalkerware will: geo locate, read call list & record calls, read notifications, texts, & possibly emails, access gallery, camera, & files, and monitor network activity. [1]
You could do all of those with "on-device adb" (in some cases, with just the appropriate permissions), without root access. Stalkerware & financial fraud enabled merely due to the scale & reach of Android (half of humanity uses it!) and lack of basic security literacy warrants such protective measures, as (Thaler & Sunstein would like to remind us) defaults matter.
With conspiracies abound, we must not lose sight of tech safety and related issues, which almost exclusively affect the most vulnerable & the most disadvantaged.
[0] https://www.techsafety.org/spyware-and-stalkerware-phone-sur...
[1] https://consumer.ftc.gov/articles/stalkerware-what-know
Spyware using ADB could be a thing (assuming someone has full access to your phone, including the password). However, it is impractical, as a reboot, system update, or Wi-Fi change would likely break everything.
It is much easier for spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps as a one-time setup.
At that point, ADB no longer matters. The spyware is already configured and ready to run. Even if on-device ADB were patched, anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.
As for attacks without physical access, as explained in the article with the 3 scenario, this is neither practical nor realistic. It only affects a very small subset of users (primarily Android developers) under very specific circumstances and during limited time windows.
> spyware to be installed as a device administrator, granted accessibility privileges, and then given every possible Android permission via AppOps
Correct, and apps using these setups (even for genuine reasons) have been under the cosh.
> At that point, ADB no longer matters.
"on-device adb" wasn't meant for scenarios it is being used for (via Shizuku, for example). It is a pointless attack surface.
> anyone with physical access to the phone would still be able to install and configure their spyware via a USB cable.
This same case can be made in support of removing on-device adb. Anyone with physical access can install & configure for their use cases. If you claim that's more hassle than worth, then you have your answer (that is, added hassle for stalkerware sellers, too).
Disallowing on-device adb is restrictive (I co-develop a security app that can absolutely make more from elevated permissions, via Shizuku or Device Admin; let alone root), but I don't think Google will do so because they want to close Android (the platform) more than they need to. To me, given the very human costs of stalkerware & financial fraud, it is an understandable, even if disappointing, security decision. Otoh, I do get that the road to hell is paved with good intentions...
> Per FTC, a stalkerware will: geo locate, read call list & record calls, read notifications, texts, & possibly emails, access gallery, camera, & files, and monitor network activity.
Like Google Mobile Services on stock Android?
No.
adb connecting a device to itself is just bad design and a hack. Either the capabilities should just be granted directly to the app or it should all be blocked.
Same can be said about loopback device in general. Why do you need to use networking when you are literally on the same device and can use binder/dbus and friends with native apps?
Shizuku uses Binder AFAICS[^1]. Looking deeper it seems that Shizuku does not connect to the device itself per se, but rather it has a privileged server launched manually through adb. Never used Shizuku, so can't say for sure.
[1]: https://github.com/rikkaapps/shizuku#how-does-shizuku-work
Shizuku essentially implements an API that your OS creator should have implemented via using adb access to have more privileges than a regular app could have access to. If your OS creator implemented these APIs they could properly implement them without this hack or requiring adb to be used.
bullish on google stock
revenue must go up
"AI ... please create a very efficient emulator which will take an Android app, and convert it to any other operating system"
Anyone up for the challenge? Or a better solution.
Fuck this bullshit. It's only going to get worse.
If only it were that simple. Anything important like banking apps will require attestation.
that seems pretty reasonable actually
To only use ADB through a WLAN? No, it is not that reasonable
or over USB, from another device? this is about maybe restricting the wireless variant to only work on wlan0
To iPhone users, perhaps.
I'm afraid in a few years iOS will actually (not as a joke) be the more open and customizable option
That seems rather unlikely given the the ways of the fruit factory. They don't stand to gain anything from loosening their stranglehold on their flock while they could lose substantially if someone were to open the gate and let the sheep escape. Nope, keeping them penned in is the best way to reliably fleece them.
i'm running graphene
I think one attack vector this sort of overlooks in the first point, regular users installing malicious apps.
My elderly mum has an Android phone. She is not very tech-literate.
She might see a full page ad "your phone has a virus, clean it now", or somehow end up on something like it (e.g. a scam email).
She then dutifully clicks on it, which prompts to download an apk. The webpage provides clear instructions for how to install the just-downloaded APK.
That APK (app) then walks her though enabling ADB, so it can "clean the phone". The app gave very good instructions (customized to reflect the UI that her device manufacturer would use), so she manages to click through to the hidden settings menu and enable ADB.
The app can now exfiltrate all sorts of data, without needing any scary permissions prompt which will tell the user what is being accessed.
I think this sort of pattern is very real, and many users are being affected by these scams. And undoubtedly more android users than iOS ones.
Finding a balance that allows power users like me to use my device as I wish, and protecting regular users, is quite hard. I think the solution Google came up with of requiring a 24 hour wait, + some extra scary warnings, for unsigned apps is a step in the right direction, it helps less tech literate users avoid scams, and power users just have to be patient for 24h. But of course it's still not satisfactory for everyone, mum might still get scammed, and power users get annoyed at it.
Your post switched half-way from "this hypothetical app your mum might hypothetically install" to "this apparently real app doing these specific things". Which way is it? Are you describing an actual threat in the wild, or just speculating about possibility?
FWIW, similar kinds of attacks is exactly why side-loading apps is about to require a reboot and 24 hour cooldown. Which you mention at the end. It sucks, but it's a decent compromise; power users like me will just do the dance and pick the "indefinite" option the moment they unpack their new phone, and rest of the people will never even know about it until they're half-way through being scammed.
I personally don't believe doing anything more in this direction is warranted.