Android 17 y un nuevo nivel de privacidad de red: ECH, protección de la red local y bloqueo del fraude mediante 2G
Android 17, lanzado el 16 de junio de 2026 y disponible inicialmente para la mayoría de los dispositivos Pixel compatibles, incorpora varios cambios de seguridad de red que van mucho más allá del aspecto o del funcionamiento cotidiano de un smartphone. Google ha centrado parte de sus esfuerzos en la información que puede quedar expuesta cuando un teléfono se conecta a sitios web, aplicaciones, equipos Wi-Fi domésticos y redes móviles. Tres cambios son especialmente importantes: Encrypted Client Hello, o ECH, que puede ocultar el dominio solicitado durante una conexión cifrada; un control más estricto del acceso de las aplicaciones a los dispositivos de una red local; y una mayor protección frente a ataques que intentan obligar al teléfono a utilizar conexiones 2G vulnerables. Ninguna de estas medidas hace que un dispositivo Android sea inmune al seguimiento o al fraude, pero en conjunto cierran varias brechas que durante años permitieron que observadores de la red, aplicaciones intrusivas y delincuentes que utilizan equipos celulares falsos pudieran conocer más datos de la actividad del usuario de los estrictamente necesarios.
Encrypted Client Hello hace que las conexiones web revelen menos información
HTTPS ya cifra la información intercambiada entre un smartphone y un sitio web seguro, incluidas contraseñas, mensajes y la mayor parte del contenido de las páginas. Sin embargo, hasta hace poco, una parte de la fase inicial de la conexión todavía podía revelar qué dominio de Internet intentaba visitar el teléfono. El problema está relacionado con Server Name Indication, normalmente abreviado como SNI. Un navegador o una aplicación utiliza esta información para que un servidor que aloja varios sitios web sepa cuál debe mostrar. En las conexiones TLS tradicionales, ese nombre podía quedar expuesto antes de que se estableciera por completo la sesión cifrada, lo que significaba que un operador de Wi-Fi, un proveedor de Internet o alguien que observara el tráfico de red podía llegar a ver el dominio aunque no pudiera leer el contenido de la conexión.
Android 17 incorpora compatibilidad integrada con Encrypted Client Hello para reducir esa exposición. ECH cifra información sensible durante la fase inicial de una conexión TLS, incluido el nombre del servidor. Como resultado, un observador situado entre el teléfono y el destino dispone de menos información útil para determinar exactamente con qué sitio web o servicio compatible está contactando el usuario. Esto resulta especialmente relevante en redes que el usuario no controla, como las de hoteles, aeropuertos, cafeterías o puntos Wi-Fi públicos, donde el tráfico pasa por equipos gestionados por otra organización. También puede reducir la cantidad de información sobre la navegación visible para un proveedor de acceso a Internet.
Existe una limitación importante. Android 17 no oculta automáticamente todos los dominios solicitados por todas las aplicaciones. En las aplicaciones dirigidas a Android 17, correspondiente al nivel de API 37, ECH puede utilizarse cuando el software de red integrado en la aplicación es compatible y el servidor de destino también está configurado para ECH. Google menciona componentes como WebView, HttpEngine y versiones compatibles de OkHttp entre las soluciones capaces de proporcionar esta compatibilidad. Si el extremo remoto de la conexión no admite ECH, Android no puede cifrar simplemente información que el servidor no está preparado para procesar. Por tanto, ECH representa una mejora significativa de la privacidad, aunque su alcance seguirá aumentando a medida que desarrolladores y administradores de sitios web adopten esta tecnología.
Qué cambia ECH en el uso cotidiano de Android
Para un usuario habitual de Android, una de las principales ventajas es que ECH funciona en gran medida en segundo plano. No es necesario activar un modo de privacidad independiente cada vez que una aplicación compatible se conecta a un sitio web. Cuando los componentes necesarios de la conexión admiten ECH, la información queda protegida como parte de la sesión cifrada normal. Esto es importante porque las funciones de privacidad resultan más eficaces cuando no dependen de que el usuario modifique constantemente ajustes o comprenda los detalles de las conexiones TLS antes de poder beneficiarse de ellas.
ECH no debe confundirse con el anonimato completo. Una red todavía puede ver que el teléfono está intercambiando datos y normalmente puede conocer la dirección IP a la que se conecta. En algunos casos, una misma dirección IP es compartida por muchos dominios, lo que reduce su utilidad para identificar el destino exacto, mientras que en otros puede seguir proporcionando pistas relevantes. Las consultas DNS también necesitan una protección adecuada, ya que una solicitud DNS sin cifrar puede revelar un dominio antes de que ECH tenga la oportunidad de ocultarlo. Por ello, la función DNS privado de Android y otros métodos de DNS cifrado siguen siendo importantes junto con ECH, en lugar de quedar sustituidos por esta tecnología.
El cambio práctico consiste en reducir la exposición innecesaria, no en hacer desaparecer todos los identificadores de red. Esta diferencia es importante al valorar las mejoras de privacidad de Android 17. Una persona conectada a una red Wi-Fi pública podía proteger anteriormente el contenido de una sesión HTTPS y, al mismo tiempo, seguir revelando el dominio solicitado durante el establecimiento de la conexión. ECH puede cerrar ese punto de exposición cuando existe compatibilidad. Los usuarios siguen necesitando mantener unas prácticas de seguridad razonables, como instalar actualizaciones, evitar certificados que no sean de confianza y mantener navegadores y aplicaciones actualizados, ya que ECH protege una parte concreta de la comunicación de red, no todas las vías posibles mediante las que se puede recopilar información.
La protección de la red local somete el acceso al Wi-Fi doméstico a permisos
Una red Wi-Fi doméstica puede contener mucha más información de la que los usuarios suelen imaginar. Los teléfonos comparten con frecuencia la misma red local con televisores, impresoras, altavoces, dispositivos de streaming, ordenadores, cámaras de seguridad y equipos para el hogar inteligente. Una aplicación capaz de explorar esa red puede llegar a conocer qué dispositivos están presentes y utilizar su combinación como una señal adicional para identificar un hogar. Antes de las nuevas restricciones de Android, la comunicación dentro de la red local se trataba de manera diferente al acceso a información claramente sensible, como la cámara o la ubicación precisa, a pesar de que un inventario detallado de los dispositivos conectados también puede revelar información sobre el usuario.
Android 17 cambia esta situación para las aplicaciones dirigidas al nivel de API 37 mediante la aplicación obligatoria de medidas de protección para la red local. Una aplicación de este tipo ya no puede obtener sin más acceso ilimitado a los dispositivos de una red de área local cuando desea buscarlos o comunicarse con ellos. Android introduce el permiso en tiempo de ejecución ACCESS_LOCAL_NETWORK para las aplicaciones que realmente necesitan un acceso amplio a la LAN. Este permiso pertenece al grupo ya existente de permisos de dispositivos cercanos. Este detalle influye en la forma en que se presenta la solicitud al usuario: una persona que ya haya concedido un permiso compatible de dispositivos cercanos no necesariamente verá una nueva solicitud únicamente porque la aplicación empiece a utilizar el nuevo permiso de red local.
La norma desarrolla un trabajo iniciado en Android 16, versión en la que los desarrolladores podían probar y adoptar voluntariamente las restricciones de la red local antes de que se hicieran obligatorias para las aplicaciones dirigidas a Android 17. El objetivo no es impedir la comunicación legítima entre los teléfonos y los equipos situados en el hogar. Android busca, en cambio, separar las aplicaciones que tienen un motivo real para acceder a la red local de aquellas cuya función principal puede realizarse sin un acceso tan amplio. Esta distinción dificulta el escaneo silencioso de la red y proporciona a Android una base más clara para limitar las aplicaciones que no tienen una razón convincente para inspeccionar los dispositivos cercanos.
Transmitir contenido y controlar dispositivos inteligentes sin exponer toda la red
Muchas funciones legítimas de Android dependen de equipos cercanos. Una aplicación de vídeo puede necesitar enviar contenido a un televisor, una aplicación de hogar inteligente puede controlar una luz o un termostato y una herramienta puede comunicarse con una impresora o un dispositivo de almacenamiento en red. Exigir acceso ilimitado a la red para cada una de estas acciones generaría su propio problema de privacidad. Por ese motivo, Android 17 admite métodos de selección de dispositivos gestionados por el sistema que permiten que una aplicación trabaje con un dispositivo elegido por el usuario sin tener que recibir primero permiso para inspeccionar todos los demás equipos conectados a la misma red.
La transmisión de contenido es un ejemplo sencillo. Si un usuario quiere enviar un vídeo a un televisor, la decisión relevante es qué televisor debe recibirlo. La aplicación de vídeo no necesita necesariamente mantener una lista permanente de todos los ordenadores, cámaras, altavoces y demás dispositivos accesibles del hogar. Un selector del sistema diseñado para preservar la privacidad puede gestionar la elección y conceder a la aplicación acceso al dispositivo seleccionado. Las aplicaciones que realmente necesitan una comunicación más amplia y continua con equipos locales pueden solicitar ACCESS_LOCAL_NETWORK y explicar por qué ese acceso es necesario.
Para los usuarios, el cambio convierte el acceso a la red local en algo que merece atención en lugar de ser una consecuencia invisible de instalar una aplicación. Una solicitud puede ser razonable en un software destinado a gestionar dispositivos inteligentes, realizar diagnósticos de red o controlar determinados equipos, mientras que la misma solicitud puede resultar mucho más difícil de justificar en una aplicación cuyas funciones no tienen relación alguna con el hardware cercano. Android 17 no puede determinar por el usuario si cada solicitud concreta es legítima, pero aplicar un límite basado en permisos reduce el acceso automático y ofrece a los desarrolladores un incentivo para solicitar únicamente las capacidades de red que su software realmente necesita.
Android 17 refuerza la protección contra el fraude por SMS basado en 2G
A pesar del uso generalizado de 4G y 5G, la compatibilidad con 2G sigue suponiendo un problema de seguridad porque un teléfono capaz de conectarse a esta tecnología antigua puede, en determinados casos, ser obligado a abandonar una red más segura. Los delincuentes pueden utilizar estaciones base falsas, conocidas también como simuladores de estaciones celulares o dispositivos de envío masivo de SMS, para emitir una señal móvil potente cerca de posibles víctimas. Un teléfono vulnerable puede verse forzado a pasar de LTE o 5G a 2G, donde las protecciones de seguridad son más débiles. Los atacantes pueden aprovechar entonces la conexión para introducir mensajes de texto fraudulentos o realizar otras formas de interceptación que resultarían considerablemente más difíciles en las redes móviles modernas.
Los dispositivos de envío masivo de SMS resultan especialmente problemáticos porque los mensajes fraudulentos enviados mediante equipos celulares falsos pueden eludir algunas de las medidas de seguridad aplicadas normalmente por las redes móviles legítimas. Un mensaje puede hacerse pasar por una comunicación de un banco, una empresa de reparto, un servicio público u otra organización conocida y dirigir al destinatario hacia una página de phishing. El ataque tiene carácter local: los delincuentes necesitan disponer de equipos de radio adecuados dentro del alcance de los teléfonos objetivo. Google ha señalado ejemplos de equipos portátiles y montados en vehículos utilizados en zonas urbanas concurridas, lo que demuestra por qué la posibilidad de que los smartphones modernos recurran a 2G sigue siendo útil para los atacantes incluso en lugares donde los operadores están reduciendo progresivamente el servicio 2G convencional.
Android permite desde Android 12 que los dispositivos compatibles desactiven 2G a nivel de radio celular, lo que impide el escaneo y la conexión normales a redes 2G. Android 17 amplía esta medida al permitir que los operadores móviles configuren la protección de manera que 2G esté desactivado de forma predeterminada para sus abonados. No se trata de un interruptor universal que Google active automáticamente en todos los teléfonos con Android 17. Esta configuración más segura depende de la participación del operador y de la compatibilidad del dispositivo. Sin embargo, cuando se aplica, el beneficio de seguridad es considerable porque el teléfono evita la conexión vulnerable antes de que un dispositivo fraudulento de envío masivo de SMS tenga la oportunidad de aprovechar una degradación forzada de la red.
Qué deben saber los usuarios sobre la protección frente a redes 2G
En primer lugar, los usuarios deben entender que desactivar 2G no es lo mismo que bloquear los mensajes de spam convencionales. Esta medida elimina una vía que puede aprovechar una categoría concreta de ataques celulares. Si un teléfono rechaza las conexiones 2G normales, una estación base falsa no puede limitarse a degradar ese dispositivo a 2G y aprovechar después las vulnerabilidades de la tecnología antigua de la forma habitual. Esto resulta especialmente útil en países donde el servicio 2G legítimo ya ha sido retirado o está cerca de desaparecer, ya que un teléfono moderno puede tener pocos motivos prácticos para mantener la conectividad 2G durante su uso cotidiano.
Existen situaciones en las que 2G todavía puede resultar útil. Algunas regiones continúan dependiendo de una cobertura móvil más antigua y los viajeros pueden encontrarse con redes de itinerancia donde no haya servicio 4G o 5G disponible. La documentación de Android advierte de que un dispositivo con 2G desactivado puede perder la conectividad móvil ordinaria en estas circunstancias hasta que el usuario vuelva a activarla. Las llamadas de emergencia reciben un tratamiento diferente: Android indica que desactivar 2G por motivos de seguridad no impide realizar llamadas de emergencia, ya que el dispositivo todavía puede buscar y utilizar una red 2G cuando sea necesario para acceder a estos servicios. Esta diferencia permite reforzar la protección durante el uso habitual sin eliminar de forma intencionada una vía de respaldo crítica para las comunicaciones de emergencia.
En conjunto, la compatibilidad de Android 17 con ECH, los controles obligatorios de red local para las aplicaciones dirigidas a la nueva versión y las opciones mejoradas de los operadores para desactivar 2G responden a tres formas diferentes de exposición de información. ECH reduce los datos sobre el destino visibles durante las conexiones cifradas compatibles; los permisos de red local limitan la inspección silenciosa de los equipos que comparten una red Wi-Fi; y los controles reforzados de 2G dificultan los ataques basados en la degradación de la conexión cuando el operador y el dispositivo son compatibles. Ninguna de estas medidas sustituye a las actualizaciones de software, a una gestión cuidadosa de los permisos ni a la precaución ante mensajes inesperados. Su importancia reside en reducir determinados riesgos antes de que el usuario tenga que reaccionar ante ellos, haciendo que varias áreas de las conexiones de Android que antes eran más permisivas ofrezcan una mayor privacidad de forma predeterminada.
