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.
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...
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.
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.
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.
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
"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 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.
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.
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?
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.
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.
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 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.
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.
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.
"...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.
> 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?
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
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.
"Intended use" (as understood by Google) for my smartphone is apparently providing them with data, consuming their advertisements and overpaying for apps that display ads and where you need in-app purchases to unlock basic functionality.
> not as a hack for escalating privileges
Hack for "escalating privileges" on my own device so I can do nefarious actions like uninstalling bloatware, denying apps internet access, recording calls (legally).. how could that be?
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.
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.
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.
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.
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.
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.
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 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).
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.
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).
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.
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.
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.
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.
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.
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 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.
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?
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".
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
- 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.
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.
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.
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.
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...
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.
Don't forget "Remember for 30 days" checkboxes that don't do anything.
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.
> 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...
I really think the IT security industry ought to be ashamed of itself.
See Pournelle's Iron Law of Bureaucracy.
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.
> 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-...
13 replies →
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.
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
14 replies →
"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 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?
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.
31 replies →
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.
5 replies →
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?
9 replies →
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.
> 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 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".
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!
2 replies →
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.
4 replies →
> 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.
5 replies →
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.
15 replies →
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.
5 replies →
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?
1 reply →
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.
3 replies →
"...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.
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...
8 replies →
> 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?
6 replies →
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 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
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.
9 replies →
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.
> 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.
[flagged]
> which is the intended use
"Intended use" (as understood by Google) for my smartphone is apparently providing them with data, consuming their advertisements and overpaying for apps that display ads and where you need in-app purchases to unlock basic functionality.
> not as a hack for escalating privileges
Hack for "escalating privileges" on my own device so I can do nefarious actions like uninstalling bloatware, denying apps internet access, recording calls (legally).. how could that be?
3 replies →
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...
9 replies →
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
1 reply →
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?"
2 replies →
> "will we have a viable alternative to jump ship before that happens ?"
GNU/Linux phones already exist. Sent from my Librem 5.
[flagged]
This is huge, Android getting locked down to such levels should be sounding alarm bells. They are slowly removing everything that makes Android good.
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.
2 replies →
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.
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.
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.
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.
3 replies →
> many banks in the UK no longer offer a web portal
Same in Norway.
12 replies →
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.)
We need unlockable bootloaders on ALL phones. Then many more OSes will come
<https://puri.sm/products/librem-5/>
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.
2 replies →
I use my bank's website on my phone and desktop.
https://sailfishos.org/
GrapheneOS is what you're looking for
Android is Linux on phones ;)
And MacOS is Unix on Macs?
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).
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.
1 reply →
finally my children will be secure and my bank account impenetrable!
/s
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...
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).
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.
Guess it's time to contact support for the few necessary apps that still don't work on GrapheneOS.
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.
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.
https://archive.ph/gla4i
In case it is made private.
Dies this affect GrapheneOS or CalyxOS?
I assume Sailfish and Ubuntu Touch are completely unimpacted?
Google is going the Apple route. When will we get the year of the Linux Phone?
https://jolla.com/
I use postmarketOS btw...
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.
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
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.
1 reply →
Just use opensource phone os!
1 reply →
Locked down hardware vendor's proprietary ROMs maybe, true open source Android not so much. Unfortunately one of these matters more then the other.
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.
6 replies →
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.
4 replies →
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.
1 reply →
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.
3 replies →
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?
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/
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.
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.
So glad we're becoming as locked down as iOS
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.
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.
Looks like some developer just suggested an idea. Doesn’t seem concrete.
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.
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.
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.
Would rooted phones still be game? I am fearful as this ruins all of my home built AI apps
i am not running stock ROMs and neither should you
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.
Increasing constraints will turn people into marionettes.
In this scenario, it means shutting off more possibilities.
If they stop sideloading and adb why should I even stay with Android?
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.
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.
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.
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
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.
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.
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.
RIP phones
I'm sorry but F* Google.
They started with "we love open" and when became virtual monopoly they extort the position :/
Another day of AI another day of AI not being able to maintain useful features people used to take for granted
...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.
> 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!
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
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".
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
bullish on google stock
revenue must go up
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.
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.
"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.
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
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
1 reply →
i'm running graphene