Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • finally my children will be secure and my bank account impenetrable!
  • /s
  • 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.

  • 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).
    by chii
  • 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
  • The person who made that suggestion (sa...@google.com) is presumed to be the one of the main maintainer of ADB as their name (Fabien Sanglard) showed up in non-redacted in the history and CC here (https://android-review.googlesource.com/c/platform/packages/...) after it was linked in the original Google IssueTracker. We can confirm they are a Google employee as per their @google.com top domain name. (For users reading, please don't target this person, it won't change anything AT ALL, i'm stating this since its public informations, and for proof)

    Their email is also in the CODEOWNER of ADB, and they made the recent ADB Wifi 2.0 presentation at Droid-Con Paris.

    They stated, "Connection to localhost has also been the source of exploits where apps are using that socket to adbd to escalate their privileges," which suggests that internally they viewed it primarily as an exploit bad actor uses. Without feedback, they would most lickly not consider changing their point of view, this is why the blog post was made.

    The article shows that this is technically possible for bad actors to use it, assuming the user allow it, but highly unlikely in practice: https://kitsumed.github.io/blog/posts/android-may-soon-restr...

    I do agree, however, that many of the comments, mainly on Reddit, blow the issue way out of proportion. Based on the website analytics, I can also confidently say that most people didn't even open or read the blog post. That's fine with me, though. My goal was to get the attention of actual developers and more technical users.

    I have been very carful in the blog post not to write something too dramatic like some news outlets do, but if no one read it, I can't do anything about it.

    EDIT: I have purposefully left that person name out of the blog post I originally made to avoid encouraging people to message them directly. However, if I need to update the blog or publish some kind of follow-up with supporting evidence, I may end up linking it. I'm not sure tbh.

  • 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.
  • GrapheneOS is what you're looking for
  • Android is Linux on phones ;)
  • We need unlockable bootloaders on ALL phones. Then many more OSes will come
  • 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.

  • 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 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)

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

  • we can just fork android

    edit: I not realizing that I been replying to wrong comment

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

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

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

  • This is huge, Android getting locked down to such levels should be sounding alarm bells. They are slowly removing everything that makes Android good.
  • 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.

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

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

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

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