Android Podría Restringir Pronto ADB en el Dispositivo

Artículo original ↗ Discusión en Hacker News ↗

El aparente movimiento de Google para restringir ADB en el dispositivo de Android —una función a menudo usada por herramientas como Shizuku para conceder a las apps capacidades elevadas sin root— es visto por muchos como parte de una tendencia más amplia hacia el bloqueo de la plataforma. Los comentaristas sostienen que los verdaderos beneficiarios son Google y los grandes proveedores de apps, citando la represión del bloqueo de anuncios, los nuevos retrasos en el sideloading, la attestation remota y los controles a nivel de Play Services como evidencia de que la “seguridad” se usa para justificar un control más estricto y menos libertad para el usuario. Una minoría responde que eliminar capacidades oscuras y de alto riesgo ayuda a proteger a los usuarios no técnicos del malware y el stalkerware, pero incluso ellos reconocen que Google ofrece pocas alternativas oficiales para los flujos de trabajo de desarrolladores y usuarios avanzados que estos cambios romperían.

Qué Cambio Se Está Debatiendo

  • El hilo se centra en un issue de Google en el que un empleado sugiere restringir ADB inalámbrico a interfaces específicas (por ejemplo, wlan0) porque las apps pueden conectarse a localhost y escalar privilegios.
  • Esto amenaza el uso de “ADB en el dispositivo” (apps en el teléfono hablando con ADB a través de loopback), empleado por herramientas como Shizuku, grabadoras de llamadas y otras utilidades para usuarios avanzados.
  • Algunos señalan que esto proviene de una CVE real en la autenticación TLS de ADB, ya corregida; la restricción del loopback es una idea derivada separada, no todavía una decisión final.

Razonamiento de Seguridad y Contexto de la CVE

  • Argumentos a favor del cambio:
    • ADB es un puerto de depuración potente; permitir que las apps lo usen como túnel elude el modelo de permisos de Android y debería tratarse como una vulnerabilidad.
    • Botnets (por ejemplo, mediante proxyware y cajas de TV inseguras) y stalkerware pueden abusar de ADB abierto o de APIs elevadas para exfiltrar datos.
    • Muchos usuarios seguirán instrucciones peligrosas paso a paso que no entienden; los valores predeterminados deben protegerlos.
  • Contraargumentos:
    • Explotar ADB en el dispositivo normalmente requiere varias acciones explícitas del usuario (activar el modo desarrollador, activar ADB por TCP, aceptar la clave), así que el riesgo para los usuarios “normales” es bajo.
    • El malware existente abusa con más facilidad de la accesibilidad, del administrador del dispositivo y de permisos de aplicaciones amplios.

Críticas: Control vs. Libertad del Usuario

  • Una facción grande ve esto como parte de una tendencia: Manifest V3 en Chrome, sideloading más estricto (retardo de 24 horas), Play Integrity/attestation, attestation de recaptcha, etc.
  • La visión es que la “seguridad” se usa para:
    • Bloquear dispositivos frente a sus propietarios, impedir el bloqueo de anuncios y la grabación de llamadas, y hacer cumplir intereses de DRM/banca/contenido.
    • Empujar a todo el mundo a través de Play Store y los servicios de Google, convirtiendo Android en un jardín vallado al estilo iOS.
  • Otros responden que el modelo de seguridad multipartito de Android da explícitamente a las apps tanta agencia como a los usuarios; si se quieren distintas compensaciones, hay que usar sistemas operativos alternativos.

Impacto en Desarrolladores y Usuarios Avanzados

  • ADB en el dispositivo se usa como una API de último recurso para cosas que el sistema operativo no expone: controles avanzados de pantalla, AppOps granulares, grabación de llamadas, automatización, herramientas de privacidad sin root.
  • Quitar ADB por loopback sin reemplazo rompería estos flujos de trabajo en dispositivos sin root y empujaría a los desarrolladores hacia hacks aún más frágiles.
  • Algunos sostienen que ADB nunca estuvo pensado para esto y que, en su lugar, deberían añadirse APIs adecuadas.

Usuarios No Técnicos, Estafas y Stalkerware

  • Un lado enfatiza el daño real: familiares engañados para habilitar opciones de desarrollador o instalar APK maliciosos; stalkerware con amplias capacidades de vigilancia.
  • Otros replican que no se puede “eliminar” por completo la ingeniería social; si bloqueas todo lo suficiente para proteger a los usuarios menos hábiles, destruyes la utilidad para todos los demás.
  • Las sugerencias incluyen advertencias más visibles y persistentes y modos “a prueba de idiotas” en lugar de una eliminación total.

Alternativas y Soluciones Temporales

  • Muchos mencionan o usan sistemas deGoogle o alternativos: GrapheneOS, LineageOS, postmarketOS, Sailfish, Librem 5, PinePhone.
  • Sin embargo, el soporte de hardware es limitado, el rendimiento suele ser peor y las aplicaciones críticas (banca, transporte, algunas mensajerías) requieren cada vez más attestation de Google o Play Services, lo que limita su viabilidad práctica.
  • Algunos sugieren construir y parchear ROM personalizadas por tu cuenta, pero otros señalan que eso falla la attestation y puede dejarte “sin banco”.

Regulación y Tendencias Más Amplias

  • Se percibe fuertemente que los rodeos técnicos no bastarán si Google sigue endureciendo el control; se piden leyes antimonopolio de la UE/EE. UU. o normas específicas por sector (por ejemplo, exigir a los bancos que admitan autenticación no basada en teléfono o basada en la web).
  • Hay escepticismo de que las multas hasta ahora hayan cambiado el comportamiento; algunos lo ven como parte de una trayectoria hacia dispositivos totalmente bloqueados y vinculados a la identidad, y una división entre una “nueva web” (attested, de pago) y una “web antigua” solo accesible desde sistemas abiertos.