Android Pode Em Breve Restringir o ADB no Dispositivo

Artigo original ↗ Discussão no Hacker News ↗

A aparente intenção do Google de restringir o ADB no dispositivo do Android — um recurso frequentemente usado por ferramentas como o Shizuku para conceder capacidades elevadas aos apps sem root — é vista por muitos como parte de uma tendência mais ampla de fechar a plataforma. Comentadores argumentam que os verdadeiros beneficiados são o Google e grandes fornecedores de aplicativos, citando a repressão ao bloqueio de anúncios, novos atrasos no sideloading, attestation remota e controles no nível do Play Services como evidência de que “segurança” está sendo usada para justificar controle mais rígido e menor liberdade do usuário. Uma minoria rebate que remover capacidades obscuras e de alto risco ajuda a proteger usuários não técnicos de malware e stalkerware, mas mesmo eles reconhecem que o Google oferece poucas alternativas oficiais para os fluxos de trabalho de usuários avançados e desenvolvedores que essas mudanças quebrariam.

Que Mudança Está Sendo Discutida

  • O tópico gira em torno de uma issue do Google em que um funcionário sugere restringir o ADB sem fio a interfaces específicas (por exemplo, wlan0), porque apps podem se conectar a localhost e escalar privilégios.
  • Isso ameaça o uso de “ADB no dispositivo” (apps no telefone falando com o ADB via loopback), usado por ferramentas como Shizuku, gravadores de chamadas e outros utilitários para usuários avançados.
  • Alguns observam que isso vem de uma CVE real na autenticação TLS do ADB, já corrigida; a restrição de loopback é uma ideia posterior e separada, ainda não uma decisão final.

Justificativa de Segurança e Contexto da CVE

  • Argumentos a favor da mudança:
    • O ADB é uma porta de depuração poderosa; permitir que apps o utilizem por túnel contorna o modelo de permissões do Android e deve ser tratado como uma vulnerabilidade.
    • Botnets (por exemplo, via proxyware e TV boxes inseguras) e stalkerware podem abusar de ADB aberto ou APIs elevadas para exfiltrar dados.
    • Muitos usuários seguirão instruções passo a passo perigosas que não entendem; os padrões precisam proteger essas pessoas.
  • Contra-argumentos:
    • Explorar o ADB no dispositivo normalmente exige várias ações explícitas do usuário (ativar o modo de desenvolvedor, ativar ADB via TCP, aceitar a chave), então o risco para usuários “normais” é baixo.
    • Malware existente abusa mais facilmente de acessibilidade, administrador do dispositivo e permissões amplas de apps.

Críticas: Controle vs. Liberdade do Usuário

  • Uma grande parte vê isso como parte de um padrão: Manifest V3 no Chrome, sideloading mais rígido (atraso de 24 horas), Play Integrity/attestation, attestation do recaptcha, etc.
  • A visão é que a “segurança” está sendo usada para:
    • Fechar os dispositivos contra seus proprietários, bloquear bloqueio de anúncios e gravação de chamadas, e impor interesses de DRM/bancos/conteúdo.
    • Empurrar todos para a Play Store e os serviços do Google, transformando o Android em um jardim murado semelhante ao iOS.
  • Outros respondem que o modelo de segurança multipartes do Android dá explicitamente aos apps tanta agência quanto aos usuários; se você quer trocas diferentes, use sistemas operacionais alternativos.

Impacto para Desenvolvedores e Usuários Avançados

  • O ADB no dispositivo é usado como API de último recurso para coisas que o SO não expõe: controles avançados de tela, AppOps granulares, gravação de chamadas, automação, ferramentas de privacidade sem root.
  • Remover o ADB via loopback sem substituição quebraria esses fluxos em dispositivos sem root e empurraria os desenvolvedores para truques ainda mais frágeis.
  • Alguns argumentam que o ADB nunca foi feito para isso e que APIs adequadas deveriam ser adicionadas em seu lugar.

Usuários Não Técnicos, Golpes e Stalkerware

  • Um lado enfatiza danos reais: parentes enganados para ativar opções de desenvolvedor ou instalar APKs maliciosos; stalkerware com amplas capacidades de vigilância.
  • Outros contra-argumentam que não dá para “resolver” completamente a engenharia social; se você trancar tudo o suficiente para proteger os usuários menos experientes, destrói a utilidade para todos os demais.
  • As sugestões incluem avisos mais altos e persistentes e modos “à prova de idiota”, em vez de remoção total.

Alternativas e Contornos

  • Muitos mencionam ou usam sistemas sem Google ou alternativos: GrapheneOS, LineageOS, postmarketOS, Sailfish, Librem 5, PinePhone.
  • No entanto, o suporte a hardware é limitado, o desempenho muitas vezes piora, e apps críticos (bancos, transporte, algumas mensagens) exigem cada vez mais attestation do Google ou Play Services, o que limita a praticidade.
  • Alguns sugerem construir e aplicar patches em ROMs personalizadas por conta própria, mas outros observam que isso falha na attestation e pode te “desbancarizar”.

Regulação e Tendências Mais Amplas

  • Há uma forte sensação de que contornos técnicos não serão suficientes se o Google continuar apertando o controle; há pedidos por antitruste na UE/EUA ou regras específicas por setor (por exemplo, exigir que bancos suportem autenticação não baseada em telefone ou baseada na web).
  • Há ceticismo de que as multas até agora tenham mudado o comportamento; alguns veem isso como parte de uma trajetória rumo a dispositivos totalmente travados, vinculados à identidade, e a uma divisão entre uma “nova web” (atestada, paga para jogar) e uma “web antiga” acessível apenas de sistemas abertos.