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.
There is a simple and highly accurate heuristic to tell if a security measure is reasonable:
Is it an open standard that anyone can permissionlessly implement?
When the answer is yes, there is a high probability that it's something reasonable, e.g. TOTP.
When the answer is no, what you will find behind the curtain is either a fool or a crook.
This heuristic is not covering the dimensions of interest here, because it fails to address the key security questions (that the industry usually wants people to not even think about):
Who is doing the securing, whose interests are being secured, and against who/what?
Security isn't an unqualified good thing to have. It's just an instrument of control. Who wields it and how are the paramount questions. You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner. In fact, that describes many, if not most, security measures introduced in computing over the past 20 years, especially on the web and mobile devices.
All this boils down to governments wanting security from their citizens and corporations wanting security from their customers. It's not going to stop, ever.
Don't forget "Remember for 30 days" checkboxes that don't do anything.
> 2FA on every trivial site
But it helps against account sharing, err I mean they make database leaks irrelevant except for private info of the customer, err I mean that we can now send more mail to the customer about new AI features without risking they think it is phishing, err I mean this is the easiest measure for the auditor findings so since we implemented this we don't need to fix all the crappy internal api auth problems and atrocious out of date dependencies, err I mean...
> But it helps against account sharing
This is actually a feature, very common in real world, that security maximalists keep insisting is a bug.
> This attack vector requires both that the user enabled developer settings and that they have remote adb enabled.
Not just that. A non-development Android build will also prompt the user when a connection is made to authorize the client's key.
This once again isn't about security of users, this is about security of the company's interests.
Google just got hit by yet another record antitrust fine by the EU [1]. But as long as they see these fines as cost of doing business, nothing will change. Especially if it always takes almost a decade to push this through the judicial system. Their net income last year alone was $130 Billion.
[1] https://www.reuters.com/world/eu-top-court-dismisses-google-...
Eh, that is if they pay. Trump already made threats for tariffs in regards to those fines.
The EU shouldn't be regulating Google like this.
The US should.
In the post iPhone era, a lot of what gets sold as security features is actually just removing functionality from the device.
In early days of this, I honestly think it was rooted in the famous Steve Jobs paranoia, the one that shipped without an app store and told users to use Safari, the same Steve Jobs that was said to not want certain medical devices during cancer treatment to touch him because they weren't beautifully designed. It was fundamentally about not wanting "dirty" things coming in contact with his "perfect" device. They dressed it up in language about security as a post hoc justification.
I remember in those days people would say they didn't want it to be like malware ridden Windows 98. But they omitted the weak security behind Windows at that time, which modern systems had long ago exceeded, even in the Windows world.
It's a security theater but you should at least respect that the guy was willing to die for beautifully designed devices and rid us of Adobe Flash.
> you should at least respect that the guy was willing to die for beautifully designed devices
I donât think that kind of stupidity warrants respect.
This. I'm a developer, I've published Android apps, & I've still managed to lose access to a device that had dev settings enabled purely because remote adb enablement is a (extremely fiddly) toggle that happened to be off on the device at the time the screen broke. Having these two enabled simultaneously is such a rare case in the wild as to be entirely negligible as a vector.
Sometimes attacks happen from users being instructed to enable settings in order to achieve something regardless of whether youâd expect them to have a reason to use the setting
Sure, sometimes people get social engineered into taking money from their bank account and giving it to criminals. Should banks stop allowing withdrawals?
If someone is willing to click on build version 5 times and then gets a mystery prompt about dev mode, and still goes along with the next 4 steps I think they were gonna get hacked a billion different other ways
The solution to social engineering can't be to remove useful features - you can socially engineer people to do literally anything, you can have someone walk to their bank, withdraw cash & fly to you with it with a dating scam: there are literally no boundaries once you get into that area of security. Digitally, you combat that through UX, messaging & education.
Then maybe the best course of action is Google adding a warning before enabling certain settings that help normies avoid these attacks.
Along the lines of "Are you being asked to do this by someone else? Be cautious, as your device could become compromised."
Limiting ADB is the obvious next step. Even if this one specific feature request does not come to pass, Google has cornered everyone into relying on a developer interface for any normal personal computing tasks, whether running on-device or through USB/wireless. It's quite clear at some point in the future you will either be required to surrender your identity to them and pay a yearly fee or be severely limited to continue using it in any meaningful capacity, because Google does not want you to develop applications on Android outside their controlled channels -- and it's a developer bridge, the battle was already lost when they did not back down from the changes forbidding normal, legitimate ̶s̶i̶d̶e̶l̶o̶a̶d̶i̶n̶g̶ installation.
>Donât even get me started on OEMs that force an audio warning such as âThis call is being recorded,â when itâs in places where itâs not legally required.
This is also Google's fault. Their dialer--that OEMs increasingly pick over their own, despite their always being much better, see old MIUI one for example--just blanket applies the rule almost everywhere. Especially annoying on all MediaTek SoCs that do not support the feature on an hardware level at all through proper, reliable third-party applications. As if you didn't need any more proof you don't own "your" devices. But maybe in a couple years Gemini will be able to listen to the calls and summarize them for you, just need to go through the approved surveillance channel.
> As if you didn't need any more proof you don't own "your" devices.
Speak for yourself. Sent from my GNU/Linux phone Librem 5.
> As if you didn't need any more proof you don't own "your" devices.
Can you install your own OS? If yes, you own it. And Google consistently lets you do that. It other OEMs don't then direct your outrage at them.
>Can you install your own OS? If yes, you own it.
Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0). Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1) And without developers pouring tens of thousands of work hours into making projects such as GrapheneOS viable despite Google, you wouldn't even be able to do much that requires anything to do with SafetyNet and all successors delivered through Google Play Services, which is functionally the core component of any Android device for the near entirety of typical use-cases. And I'm not excusing OEMs, but they did not build their market share off of being "open" then start to close every door and trap you in it.
0. https://www.fitzsim.org/blog/?p=545
1. https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...
> Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0)
oookay? Hardly seems like a big deal? It would indeed be nice if the unlocked phones were set from the factory as such instead of all being the same system image as the ones that locked carriers use, sure, but hardly significant since it's not like you have to sign in or anything?
> Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)
Why are you even asking Google at all? Just use Firefox? Don't even need to root or use a custom ROM for that, even.
>Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0).
What's the problem here? Are you roaming all the time and that imposes a unreasonable cost on you? You want to stay totally off the grid and using VPN/tor isn't enough?
>Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)
Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.
As far as I can tell, this is a big overreaction to a misunderstanding.
I'm a developer with remote adb enabled, using it in the normal intended way (to install new builds of an Android project I'm developing, retrieve log files related to it, etc). Currently, I access this via VPN (tailscale), but it's exposed to connections (and any pre-auth security vulnerability risks) on any random public wifi network I connect to. Adding the ability to restrict this to just tailscale will be an improvement, for me.
The proposal at the top of the thread is that you specify which interface you want it to bind to, when you set up remote adb, rather than binding to every interface. Nothing in that proposal suggests that "localhost" would be rejected as a choice of interface. One person suggested binding only to "wlan0", but that was a short throwaway comment that is obviously wrong (wlan0 is less-trusted than VPNs) and obviously not what they're going to do.
Thanks for clarifying, if your read is correct and they're just putting more control in the user's hand then this isn't an issue at all
> Spamming the thread will only cause Google developers to lock the issue, ignore valuable community feedback, or stop sharing public updates about this change entirely.
So nothing would change (they can also lock away your "valuable community feedback" because what bothers them is the criticism itself), thus feel free to express your approval
> because what bothers them is the criticism itself
I think there's a difference between criticism of a policy and being brigaded by a reddit mob.
Google pushes a new feature to Android where phones wake up at 2:22 AM every night to play a blood-curdling scream at maximum volume, regardless of settings. An issue is created and gets assigned, into which Google employees regularly butt in to explain the feature exists to keep users safe from night break-ins. Nothing changes. People have to start modifying their lives around this problemâmost have to shut off their phones during the night, many had to buy a separate alarm clockâand masses of disappointed customers eventually make their way to the bug tracker to voice their concern. The issue gets locked as "too heated".
Apple has had this feature for three years on iOS. What else should they have done?
>What else should they have done?
Use an AOSP fork like grapheneos or lineageos. Barring that, voting with their wallets and buying a HarmonyOS phone. If for whatever reason they're doing that too, there's probably more powerful forces behind this change (eg. government mandates) that won't be helped by spamming an issue tracker.
You think wrong, "mob" is a collective way of criticizing a policy.
Sure, there are differences in types criticisms, but then try to actually articulate those and address whatever you think the issues with those are
The implication in the blog post that Google developers somehow âoverlookedâ or âmisunderstoodâ important use cases here, and if only they were informed about them they would reconsider, is frankly insulting.
Every single time any story has the words "Google developers" in it, they're behaving like arrogant, disconnected, anti-consumer jerks. From constant GCP breakage, to not acknowledging obvious Android bugs, to intentionally braking Chrome. It's a stark contrast to behind the scenes interactions with them.
If I didn't word it like that (I'm the author) the "reddit mob" would have exploded the thread. That's the last thing I want. I want valuable feedback there, for now its somehwat working.
Most of the users who saw the post on reddit didn't even open the blog post anyways, according to analytics.
Yeah, my favorite one is how Chrome users are not smart enough to handle case-aware web-page search toggle. Although to be fair their Chrome team is very arrogant even by Google standards.
Exhibit A: https://issues.chromium.org/issues/40093420
Decades of people desperate for a fix, utter stonewall from Google
Some PM somewhere decided that autocomplete belongs on all your fields, and who are you, the poor site developer, to disagree?
[flagged]
The moment an article like this hits HN or Reddit or any other such forum, any hope of changing anyone's mind is lost. The same happens to Github issues too. I haven't checked the isue myself, but seeing it here means it's probably already too late at this point, it'll probably get flooded.
Google does take feedback from app developers every now and then, but obviously their own teams' feelings on the subject are more important to them than some open source developers relying on a hack like in this article.
I think it should be quite obvious that the ADB daemon wasn't designed to enable call recording from an app initiating an adb session over a loopback address. https://xkcd.com/1172/ strikes again.
That doesn't mean the developer who wrote this is wrong to dislike the change: Google themselves have added call recording to their dialer a while ago so it's clearly a feature they stand behind. That doesn't mean the adb team shouldn't do a little security hardening, though.
In 2008 Sergey Brin and Larry Page saw the limo waiting, and instead chose to rollerblade to the Android unveiling. Sergey Brin, during the presentation, threw his G1 in the air to show off how his homemade application leveraged the accelerometer to see how high he'd thrown it
That use-case was never designed for when the sensor was added, and is every bit as hacky and fun as adding call recording with a loopbakc address
And that's the first problem: Android is no longer fun, and it's no longer for trying this hilariously stupid hacky method of doing what we, the users, want.
The second problem is an attitude of "Google's dialer has it built-in, why would one want a third-party dialer instead of Google's?"
Because we fucking can - or could, at least. The OS was designed to be as modular as possible, to the point where, while iOS still can't change their launcher, Android has had that option since day one. Setting aside Google casting themselves as the (not so) benevolent dictator of "Just use our apps exclusively. Life will be easier that way", closing off the modularity is antithecal to the Android experience that so many geeks fell in love with, and arguably made the platform what it is
When Google first announced sideloading restrictions, somebody told âbut we have ADBâ, and who disagreed with them was criticized harshly.
Now, Iâm waiting for a workaround to enable ADB, so sideloading can be handled now, too.
Android is not more open that iOS for a very long time now. The trend will continue.
Again, this is not a technical problem (the mindset of Google), so technological solutions wonât help.
Android became a lost cause the second they introduced hardware remote attestation.
Even if there was a way to install your own software, there's no point in doing so. You're "tampering" with the device. Fail attestation and you're untrusted. You get banned from everything. If you hack, you're ostracized from digital society. You're a second class citizen. Can't communicate. Can't bank. Can't stream. Can't play video games. Can't do pretty much anything.
That's the future of Android. GrapheneOS is quite literally the last hope for Android, and only because by some miracle there are companies out there who started trusting Graphene's attestation keys. If that hope ever dies then we might as well buy iPhones.
> 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?
>like uninstalling bloatware, denying apps internet access
All of these can be done with a computer.
>recording calls (legally)..
A second phone does the same thing.
>Hack for "escalating privileges" on my own device so I can do nefarious actions
Whether it's a "hack" is orthogonal to whether you control the device or not. I don't think anyone disputes that you "own" your linux PC, but using the well known `docker run --privileged ...`[1] method to get root on your machine is still a hack.
[1] random result: https://github.com/Volodishlav/Docker-Privilege-Escalation
Of course this was bound to happen, next you're telling me people will be surprised that the 24 hour limit for side loading will turn into some indefinite time period.
It can and will most probably turn to indefinite time depending on the answer to the question "will we have a viable alternative to jump ship before that happens ?".
We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.
Many alternative AOSP-based systems work fine today and do not have the new Android Developer Verifier (wow, already rolled out to 500M+ devices [1], though still dormant).
To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick your phone, etc.
[1] https://play.google.com/store/apps/details?id=com.google.and...
We used to call programs like this, that allow someone to remotely break your system, a Trojan horse...
> brick your phone, etc.
Apple can do the same for iPhones. In terms of dark shit they can do there's no difference anymore.
> To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones.
Are any commercial mobile phone vendors not able to do such a thing? Do remember that this giant kerfuffle is all over the seeming preparation for the apparent removal of a developer feature that iPhones have never had at all.
Wait till you hear that your OEM can remotely rollout full OS updates with full access to all your data and drivers... carrying Google software and most of it Google code.
I get the analogy but it's a false one. Google covers about 90% of Mozilla's funding. Firefox only survives because of Google, and that's so they don't hit antitrust problems.
> Firefox only survives because of Google, and that's so they don't hit antitrust problems.
Yes, that is what I meant. They should be hesitant to lockdown completely and (grudgingly even) allow alternative options and/or workarounds due to legal concerns like anti-trust.
Firefox was existing before Chrome, but in this case we either need a different OS or need an android based option like Graphene/3rd party stores gain enough marketshare to trigger anti-competitive laws.
Google is working on a new recaptcha strategy to counter that. Essentially any non Google flavor of Android OS will fail recaptcha validation
> will we have a viable alternative to jump ship before that happens ?
Here is a better question:
"Is the EU going to stop this?"
No because the EUDI Wallet needs Google Play Services. People need to come to the realization that the EU has no interest in regulating the freedom of devices because the EU itself is benefitting from the closed-down ecosystem.
Why would the EU stop it?
[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.
I always disable everything Google that comes preinstalled other than maps, including the App store. You can download stuff that you can only get there through Aurora, but really most of what I use comes from F-Droid.
Not that I trust a device running Android enough to do banking, mind you.
the situation is not ideal but this is the best we can do
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.