Android may soon restrict on-device ADB

Original Article ↗ Hacker News Discussion ↗

Google’s apparent move to restrict Android’s on-device ADB (debug bridge) – a feature often used by tools like Shizuku to grant apps elevated capabilities without root – is seen by many as part of a broader trend toward locking down the platform. Commenters argue that the real beneficiaries are Google and large app vendors, citing ad blocking crackdowns, new sideloading delays, remote attestation, and Play Services–level controls as evidence that “security” is being used to justify tighter control and reduced user freedom. A minority counter that removing obscure, high‑risk capabilities helps protect non‑technical users from malware and stalkerware, but even they acknowledge that Google offers few official alternatives for power‑user and developer workflows that these changes would break.

What Change Is Being Discussed

  • Thread centers on a Google issue where an employee suggests restricting wireless ADB to specific interfaces (e.g., wlan0) because apps can connect to localhost and escalate privileges.
  • This threatens “on‑device ADB” use (apps on the phone talking to ADB over loopback), used by tools like Shizuku, call recorders, and other power‑user utilities.
  • Some note this stems from a real CVE in ADB TLS auth, already patched; the loopback restriction is a separate follow‑on idea, not yet a final decision.

Security Rationale & CVE Context

  • Pro‑change arguments:
    • ADB is a powerful debug port; letting apps tunnel through it bypasses Android’s permission model and should be treated like a vulnerability.
    • Botnets (e.g., via proxyware and insecure TV boxes) and stalkerware can abuse open ADB or elevated APIs to exfiltrate data.
    • Many users will follow dangerous step‑by‑step instructions they don’t understand; defaults must protect them.
  • Counter‑arguments:
    • Exploiting on‑device ADB typically requires multiple explicit user actions (enable dev mode, enable ADB over TCP, accept key), so risk to “normal” users is low.
    • Existing malware more easily abuses accessibility, device admin, and broad app permissions.

Critiques: Control vs User Freedom

  • Large faction sees this as part of a pattern: Manifest V3 in Chrome, stricter sideloading (24‑hour delay), Play Integrity/attestation, recaptcha attestation, etc.
  • View: “security” is being used to:
    • Lock down devices against owners, block ad‑blocking and call recording, and enforce DRM/banking/content interests.
    • Push everyone through Play Store and Google services, turning Android into an iOS‑like walled garden.
  • Others reply that Android’s multi‑party security model explicitly gives apps as much agency as users; if you want different tradeoffs, use alternative OSes.

Impact on Developers & Power Users

  • On‑device ADB is used as a last‑resort API for things the OS won’t expose: advanced display controls, granular AppOps, call recording, automation, rootless privacy tools.
  • Removing loopback ADB without replacement would break these workflows on non‑rooted devices and push devs toward even more fragile hacks.
  • Some argue ADB was never meant for this and proper APIs should be added instead.

Non‑technical Users, Scams, and Stalkerware

  • One side emphasizes real harm: relatives tricked into enabling developer options or installing malicious APKs; stalkerware with broad surveillance capabilities.
  • Others counter that you cannot fully “engineer out” social‑engineering; if you lock everything down enough to protect the least savvy users, you destroy utility for everyone else.
  • Suggestions include louder, persistent warnings and “idiot‑proof” modes instead of outright removal.

Alternatives & Workarounds

  • Many mention or use de‑Googled or alternative systems: GrapheneOS, LineageOS, postmarketOS, Sailfish, Librem 5, PinePhone.
  • However, hardware support is narrow, performance often worse, and critical apps (banking, transport, some messaging) increasingly require Google attestation or Play Services, limiting practicality.
  • Some suggest building and patching custom ROMs yourself, but others note this fails attestation and can “un‑bank” you.

Regulation and Broader Trends

  • Strong sense that technical workarounds won’t be enough if Google keeps tightening control; calls for EU/US antitrust or sector‑specific rules (e.g., requiring banks to support non‑phone or web‑based auth).
  • Skepticism that fines so far have changed behavior; some see this as part of a trajectory toward ID‑tied, fully locked‑down devices and a split between a “new web” (attested, pay‑to‑play) and an “old web” only reachable from open systems.