5 ms·

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 develop

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.

pigggg 3mo ago
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?
- xg15 3mo ago
  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?
  - londons_explore 3mo ago
    Yes, but users are told to allow it if they want to get free coins etc.
    - xg15 3mo ago
      Told by whom though? If it's through proxyware, then there are three parties who mostly don't know each other: - the app embedding the proxyware SDK for money - the proxy operators - the attackers/botnets using the proxy to access ADB. The botnet has no access to the app, so it can't show any messages. The app can show messages, but probably has no connection to the botnet. (I hope) The proxy operators could show a message by abusing the SDK even more, but that would mean they actively colluded with the botnet. Is that likely? Then they could just give the botnet direct access to the app, no need to do the whole proxy thing.
      - londons_explore 3mo ago
        It isn't being done behind-the-back of proxy operators. It's one more revenue stream to be able to remote control real android phones to pass device attestation checks etc. It's marketed to users with phrases like "earn money from your phone whilst you sleep".
        xg15 3mo ago
        Ok, that makes more sense. Hooray for stuff getting even worse...
        TeMPOraL 3mo ago
        Remote attestation itself being a questionable idea at best, so it's bad things creating a market for even worse workarounds.
        xg15 3mo ago
        No objection there. Also telling that advertising and locking down devices are driven by the same companies...
        inigyou 3mo ago
        And it's entirely Cloudflare's and Google's fault. When you say you need to have X to do Y, people are going to find ways to get X.
    - TeMPOraL 3mo ago
      You can't fully protect people from the risk of taking bad advice from malicious strangers. Not the least because most of our industry relies on it to make money. Marketing and advertising themselves are institutionalized forms of "do this thing that's actually harmful to you to get free coins / be safe / get laid".
      - xg15 3mo ago
        > Not the least because most of our industry relies on it to make money. I mean, this seems more like one of the root causes for a lot of bad things in the industry me...
- crote 3mo ago
  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.
  - II2II 3mo ago
    > In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. Have you ever worked with someone who barely knows how to use a mobile phone? They will hand their phone over to someone they barely even know to do something they don't understand. They will follow instructions from a stranger over the phone, without understanding what the phone is warning them about. I have worked with such a person. They did have someone walk them through a dubious process. Thankfully they realized what was going on before the process was complete, but who knows how much damage was done by the initial steps. There are legitimate security reasons here. Whether there are reasons beyond that is an open question.
    - g-b-r 3mo ago
      Can we freaking sell them dumbphones, then, and stop destroying portable computers for everyone else with that excuse? Which incidentally is often just a pretense for other motives? If computers have suddenly become so dangerous for normal people, and they want smartphones nonetheless, add to them a dumb-mode encouraged at the initial setup, and requiring some third party assistance to turn it off once enabled..! (and forbid apps to change their behavior if it's not enabled)
- franga2000 3mo ago
  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.
  - pigggg 3mo ago
    Millions of Superboxes and various digital picture frames say different. https://synthient.com/blog/a-broken-system-fueling-botnets https://synthient.com/blog/a-broken-system-fueling-botnets
    - microtonal 3mo ago
      Kimwolf exploits vulnerable Android Debug Bridge (ADB) services. Many low-cost TV boxes come "pre-infected" with proxy SDKs; Kimwolf then scans these residential proxy networks and exploits the devices within minutes as it propagates. https://www.cloudflare.com/learning/ddos/glossary/aisuru-kimwolf-botnet/ https://www.cloudflare.com/learning/ddos/glossary/aisuru-kim... This is like saying that SSH is insecure because some device vendors install SSH, permitting root login with a default password of 'root'.
      - BiteCode_dev 3mo ago
        Yeah let's block port 80, too many people expose unprotected api.
        ValdikSS 3mo ago
        This is what several cellular ISP to (block ports <1024 and 5555) to protect the users on IPv6. You can unlock it with additional free option.
    - franga2000 3mo ago
      Well yes, but those won't get Google's new updates either. Open ADB on 5555 was a problem we solved almost a decade ago and these devices are still vulnerable. Even further restricting ADB in the latest version won't do anything to prevent that.
- jambalaya8 3mo ago
  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.
- kitsumed 3mo ago
  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.
izacus 3mo ago
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.
- TeMPOraL 3mo ago
  > 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.
  - dns_snek 3mo ago
    Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.
    - TeMPOraL 3mo ago
      Yes, but what about allowing me to run adb commands on my phone with my consent, and especially delegating that privilege to "strangers", again, with my (one-time) consent - by which I mean authorizing apps to run with elevated privileges and/or reestablish the debugging bridge once it invariably disconnects (for other more or less legitimate security reasons)? It's not like those threats silently turn on ADB on people's phones without their knowledge. You have to opt in to a rather obscure, hidden by default, and very fickle feature to become potentially vulnerable in the first place.
      - dns_snek 3mo ago
        They're 3 separate issues. There's a genuine vulnerability (CVE) which has been fixed, there's a follow-up proposal to allow the user to choose which interfaces to bind to, and there's another proposal to disallow ADB over loopback which would cut you off from using ADB on-device. Your problem is with the last one which has nothing to do with the CVE itself.
PunchyHamster 3mo ago
It's not because of security. It's to slowly close any avenues for side-loading stuff
- miroljub 3mo ago
  It's not side loading. Word you are looking for is called "installing".
  - PunchyHamster 3mo ago
    Not on android https://www.reddit.com/r/explainlikeimfive/comments/1k824n8/eli5_sideloading_in_a_simple_term_why_it_is_so/ https://www.reddit.com/r/explainlikeimfive/comments/1k824n8/...
    - wolvoleo 3mo ago
      I think the OP means that calling it sideloading gives it a sneaky dark connotation which it doesn't deserve because installing software is simply a normal thing for a user to do. It's Google that's branding it as such because they want people to only trust the play store, and thus protect their 30% stake and other benefits like deciding what goes in the store.
m132 3mo ago
> 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.
- sigmoid10 3mo ago
  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-fight-against-record-41-billion-eu-antitrust-fine-2026-07-02/ https://www.reuters.com/world/eu-top-court-dismisses-google-...
  - oblio 3mo ago
    The EU shouldn't be regulating Google like this. The US should.
    - 3form 3mo ago
      Why not both? Countries should be able to signal which business practices are undesirable.
      - _blk 3mo ago
        Yes, laws are laws but one affects a branch, the other a root.
        froggit 3mo ago
        Cut off enough branches and the roots die.
      - oblio 3mo ago
lucideer 3mo ago
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.
- wahnfrieden 3mo ago
  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
  - ordu 3mo ago
    I think that these victims are paid by the likes of Google to create a precedent. It is unbelievable stupid scheme to fall to.
    - JoshTriplett 3mo ago
      While I certainly think we should not be taking features away from people just because there exist people who will let themselves be social-engineered through arbitrary hoops, don't go creating wild conspiracy theories to explain something that supports much simpler explanations instead. It's easy enough to imagine that Google is trying to fix something they see as a problem, and not caring about the developer case rather than specifically seeking to destroy it. When Apple fixed security issues that allowed for jailbreaking, they weren't doing it specifically because people use it for jailbreaking, they were doing it because it was a security issue. We should have 100% control of our own devices. But we should have it by design, in a fashion that makes sure that we control them rather than other people.
      - kelnos 3mo ago
        I think there's very plausible a middle ground too: Google does want to remove these features for business reasons, and is using the real problem of social engineering as an excuse.
a2128 3mo ago
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/?filter=most_trackers 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.
- transcriptase 3mo ago
  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.
  - JoshTriplett 3mo ago
    They wouldn't have been able to if people didn't use a browser created by an advertising company.
  - Cider9986 3mo ago
thewebguyd 3mo ago
> why not allow developers to restrict access localhost? Ads and tracking, obviously (https://localmess.github.io/ 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.
zaptheimpaler 3mo ago
"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.
- CamperBob2 3mo ago
  I really think the IT security industry ought to be ashamed of itself. See Pournelle's Iron Law of Bureaucracy.
- sgt 3mo ago
  Don't forget "Remember for 30 days" checkboxes that don't do anything.
- deleted 3mo ago
  [deleted]
- therein 3mo ago
  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.
asveikau 3mo ago
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.
- petre 3mo ago
  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.
  - hnlmorg 3mo ago
    > 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.
- Cider9986 3mo ago
  Hard disagree. iPhones are some of the most secure devices available. They are much more secure than desktop computers. This is a good thing because it protects users private data. With how much personal data phones, it seems reasonable to secure them extensively. That's why I use GrapheneOS.
  - bluebarbet 3mo ago
    >iPhones are some of the most secure devices available How do you know? We're not allowed to see the source code.
miohtama 3mo ago
"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.
GrandfatherTECH 3mo ago
It's just to restrict us all from using our devices in any way we want. Phone breands are already refusing to unlock bootloaders so that we can't just slap on a pirated version of their firmware and keep the updates flowing in.

pigggg 3mo ago

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?

xg15 3mo ago
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?
- londons_explore 3mo ago
  Yes, but users are told to allow it if they want to get free coins etc.
  - xg15 3mo ago
    Told by whom though? If it's through proxyware, then there are three parties who mostly don't know each other: - the app embedding the proxyware SDK for money - the proxy operators - the attackers/botnets using the proxy to access ADB. The botnet has no access to the app, so it can't show any messages. The app can show messages, but probably has no connection to the botnet. (I hope) The proxy operators could show a message by abusing the SDK even more, but that would mean they actively colluded with the botnet. Is that likely? Then they could just give the botnet direct access to the app, no need to do the whole proxy thing.
    - londons_explore 3mo ago
      It isn't being done behind-the-back of proxy operators. It's one more revenue stream to be able to remote control real android phones to pass device attestation checks etc. It's marketed to users with phrases like "earn money from your phone whilst you sleep".
      - xg15 3mo ago
        Ok, that makes more sense. Hooray for stuff getting even worse...
        TeMPOraL 3mo ago
        Remote attestation itself being a questionable idea at best, so it's bad things creating a market for even worse workarounds.
        xg15 3mo ago
        No objection there. Also telling that advertising and locking down devices are driven by the same companies...
      - inigyou 3mo ago
        And it's entirely Cloudflare's and Google's fault. When you say you need to have X to do Y, people are going to find ways to get X.
  - TeMPOraL 3mo ago
    You can't fully protect people from the risk of taking bad advice from malicious strangers. Not the least because most of our industry relies on it to make money. Marketing and advertising themselves are institutionalized forms of "do this thing that's actually harmful to you to get free coins / be safe / get laid".
    - xg15 3mo ago
      > Not the least because most of our industry relies on it to make money. I mean, this seems more like one of the root causes for a lot of bad things in the industry me...
crote 3mo ago
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.
- II2II 3mo ago
  > In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. Have you ever worked with someone who barely knows how to use a mobile phone? They will hand their phone over to someone they barely even know to do something they don't understand. They will follow instructions from a stranger over the phone, without understanding what the phone is warning them about. I have worked with such a person. They did have someone walk them through a dubious process. Thankfully they realized what was going on before the process was complete, but who knows how much damage was done by the initial steps. There are legitimate security reasons here. Whether there are reasons beyond that is an open question.
  - g-b-r 3mo ago
    Can we freaking sell them dumbphones, then, and stop destroying portable computers for everyone else with that excuse? Which incidentally is often just a pretense for other motives? If computers have suddenly become so dangerous for normal people, and they want smartphones nonetheless, add to them a dumb-mode encouraged at the initial setup, and requiring some third party assistance to turn it off once enabled..! (and forbid apps to change their behavior if it's not enabled)
franga2000 3mo ago
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.
- pigggg 3mo ago
  Millions of Superboxes and various digital picture frames say different. https://synthient.com/blog/a-broken-system-fueling-botnets https://synthient.com/blog/a-broken-system-fueling-botnets
  - microtonal 3mo ago
    Kimwolf exploits vulnerable Android Debug Bridge (ADB) services. Many low-cost TV boxes come "pre-infected" with proxy SDKs; Kimwolf then scans these residential proxy networks and exploits the devices within minutes as it propagates. https://www.cloudflare.com/learning/ddos/glossary/aisuru-kimwolf-botnet/ https://www.cloudflare.com/learning/ddos/glossary/aisuru-kim... This is like saying that SSH is insecure because some device vendors install SSH, permitting root login with a default password of 'root'.
    - BiteCode_dev 3mo ago
      Yeah let's block port 80, too many people expose unprotected api.
      - ValdikSS 3mo ago
        This is what several cellular ISP to (block ports <1024 and 5555) to protect the users on IPv6. You can unlock it with additional free option.
  - franga2000 3mo ago
    Well yes, but those won't get Google's new updates either. Open ADB on 5555 was a problem we solved almost a decade ago and these devices are still vulnerable. Even further restricting ADB in the latest version won't do anything to prevent that.
jambalaya8 3mo ago
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.
kitsumed 3mo ago
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.

izacus 3mo ago

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.

TeMPOraL 3mo ago
> 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.
- dns_snek 3mo ago
  Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.
  - TeMPOraL 3mo ago
    Yes, but what about allowing me to run adb commands on my phone with my consent, and especially delegating that privilege to "strangers", again, with my (one-time) consent - by which I mean authorizing apps to run with elevated privileges and/or reestablish the debugging bridge once it invariably disconnects (for other more or less legitimate security reasons)? It's not like those threats silently turn on ADB on people's phones without their knowledge. You have to opt in to a rather obscure, hidden by default, and very fickle feature to become potentially vulnerable in the first place.
    - dns_snek 3mo ago
      They're 3 separate issues. There's a genuine vulnerability (CVE) which has been fixed, there's a follow-up proposal to allow the user to choose which interfaces to bind to, and there's another proposal to disallow ADB over loopback which would cut you off from using ADB on-device. Your problem is with the last one which has nothing to do with the CVE itself.

PunchyHamster 3mo ago

It's not because of security. It's to slowly close any avenues for side-loading stuff

miroljub 3mo ago
It's not side loading. Word you are looking for is called "installing".
- PunchyHamster 3mo ago
  Not on android https://www.reddit.com/r/explainlikeimfive/comments/1k824n8/eli5_sideloading_in_a_simple_term_why_it_is_so/ https://www.reddit.com/r/explainlikeimfive/comments/1k824n8/...
  - wolvoleo 3mo ago
    I think the OP means that calling it sideloading gives it a sneaky dark connotation which it doesn't deserve because installing software is simply a normal thing for a user to do. It's Google that's branding it as such because they want people to only trust the play store, and thus protect their 30% stake and other benefits like deciding what goes in the store.

m132 3mo ago

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

sigmoid10 3mo ago
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-fight-against-record-41-billion-eu-antitrust-fine-2026-07-02/ https://www.reuters.com/world/eu-top-court-dismisses-google-...
- oblio 3mo ago
  The EU shouldn't be regulating Google like this. The US should.
  - 3form 3mo ago
    Why not both? Countries should be able to signal which business practices are undesirable.
    - _blk 3mo ago
      Yes, laws are laws but one affects a branch, the other a root.
      - froggit 3mo ago
        Cut off enough branches and the roots die.
    - oblio 3mo ago

lucideer 3mo ago

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.

wahnfrieden 3mo ago
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
- ordu 3mo ago
  I think that these victims are paid by the likes of Google to create a precedent. It is unbelievable stupid scheme to fall to.
  - JoshTriplett 3mo ago
    While I certainly think we should not be taking features away from people just because there exist people who will let themselves be social-engineered through arbitrary hoops, don't go creating wild conspiracy theories to explain something that supports much simpler explanations instead. It's easy enough to imagine that Google is trying to fix something they see as a problem, and not caring about the developer case rather than specifically seeking to destroy it. When Apple fixed security issues that allowed for jailbreaking, they weren't doing it specifically because people use it for jailbreaking, they were doing it because it was a security issue. We should have 100% control of our own devices. But we should have it by design, in a fashion that makes sure that we control them rather than other people.
    - kelnos 3mo ago
      I think there's very plausible a middle ground too: Google does want to remove these features for business reasons, and is using the real problem of social engineering as an excuse.

a2128 3mo ago

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/?filter=most_trackers 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.

transcriptase 3mo ago
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.
- JoshTriplett 3mo ago
  They wouldn't have been able to if people didn't use a browser created by an advertising company.
- Cider9986 3mo ago

thewebguyd 3mo ago

> why not allow developers to restrict access localhost? Ads and tracking, obviously (https://localmess.github.io/ 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.

zaptheimpaler 3mo ago

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

CamperBob2 3mo ago
I really think the IT security industry ought to be ashamed of itself. See Pournelle's Iron Law of Bureaucracy.
sgt 3mo ago
Don't forget "Remember for 30 days" checkboxes that don't do anything.
deleted 3mo ago
[deleted]
therein 3mo ago
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.

asveikau 3mo ago

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.

petre 3mo ago
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.
- hnlmorg 3mo ago
  > 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.
Cider9986 3mo ago
Hard disagree. iPhones are some of the most secure devices available. They are much more secure than desktop computers. This is a good thing because it protects users private data. With how much personal data phones, it seems reasonable to secure them extensively. That's why I use GrapheneOS.
- bluebarbet 3mo ago
  >iPhones are some of the most secure devices available How do you know? We're not allowed to see the source code.

miohtama 3mo ago

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

GrandfatherTECH 3mo ago

It's just to restrict us all from using our devices in any way we want. Phone breands are already refusing to unlock bootloaders so that we can't just slap on a pirated version of their firmware and keep the updates flowing in.