Revelan una técnica encubierta de rastreo web-app usando localhost en Android
(localmess.github.io)- Se reveló que apps importantes como Meta (Facebook) y Yandex usaban puertos locales (127.0.0.1) en Android para compartir en secreto identificadores y cookies entre el navegador web y apps nativas
- Scripts de Facebook Pixel y Yandex Metrica incrustados en sitios web enviaban directamente sesiones de navegación e identificadores desde navegadores Android hacia apps nativas (Facebook, Instagram y apps del ecosistema Yandex), haciendo posible la identificación del usuario y su desanonimización
- Este método elude por completo las protecciones de privacidad existentes, como borrar cookies, modo incógnito, ajustes de permisos o reinicio del ID de publicidad; además, si una app maliciosa solo escucha en el puerto correcto, también puede recopilar el historial de visitas del navegador
- Tras su divulgación el 3 de junio de 2025, Facebook eliminó la mayor parte del código relacionado, pero la técnica se usó durante años en cientos de millones de dispositivos Android en todo el mundo. Yandex sigue usando un método similar de forma continua desde 2017
- Navegadores importantes como Chrome, Firefox y Brave introdujeron bloqueos de emergencia, pero las limitaciones estructurales de la plataforma impiden una solución de fondo completa, por lo que se subraya la necesidad de reforzar la seguridad de Android IPC y de la red local
Disclosure: técnica encubierta de rastreo web-app a través de localhost
- El equipo de investigación descubrió que Meta y Yandex, afectando a miles de millones de usuarios Android, mantenían apps nativas con puertos locales predefinidos abiertos en segundo plano (por ejemplo, 12580~12585, 29009~30103) para comunicarse con JavaScript ejecutado desde la web
- Con esto, cookies, metadatos e historial de uso del navegador web se transferían a apps nativas y se combinaban con información de cuentas de la app y el Android Advertising ID para vincular la identidad del usuario con sus visitas web
How does this work?
Abuso de puertos locales en Android
- En Android, cualquier app con el permiso INTERNET puede abrir un socket en 127.0.0.1 (loopback)
- Los navegadores también pueden acceder a esa interfaz sin consentimiento adicional del usuario
- El JavaScript incrustado en sitios web puede enviar y recibir datos entre el navegador y apps nativas usando Web APIs estándar
Cómo se vinculaban web y app en Meta/Facebook Pixel
- Cuando el JavaScript de Meta Pixel se cargaba en un navegador Android, enviaba el valor de la cookie _fbp a la app nativa mediante paquetes STUN de WebRTC (UDP puertos 12580–12585)
- Las apps de Facebook e Instagram en el dispositivo (según versión, por ejemplo 515.0.0.23.90/382.0.0.43.84) escuchaban en esos puertos, recibían el valor de _fbp enviado por el navegador y lo remitían a sus propios servidores vía GraphQL
- _fbp es una cookie clave presente en aproximadamente el 25% del millón de sitios más importantes; antes era difícil rastrear entre sitios porque cada uno la gestionaba por separado, pero con este método se podían asociar múltiples _fbp de un mismo usuario a una sola cuenta
- Desde mayo de 2025, el script añadió además el método TURN de WebRTC para evitar la técnica de SDP Munging
- La cookie _fbp dura 90 días y es extremadamente común, al usarse en cerca del 25% de los principales sitios web
- Tras la respuesta de navegadores como Chrome, el código fue eliminado el 3 de junio
Cómo se vinculaban web y app en Yandex Metrica
- El script de Yandex Metrica envía solicitudes por HTTP(S) a puertos locales (29009, 29010, 30102, 30103, etc.) desde 2017
- Apps de Yandex (Yandex Maps, Navigator, Browser, Search, etc.) mantienen esos puertos abiertos y responden con datos codificados en Base64 que incluyen el Android Advertising ID (AAID), otros identificadores del dispositivo y UUID
- El script del navegador recopila esa información y la vuelve a enviar a los servidores de Yandex, completando así la vinculación de identificadores entre navegador, app y servidor
- El dominio yandexmetrica.com se resolvía a 127.0.0.1 para evitar la detección y ocultar el flujo de recolección
- Debido al uso de HTTP en localhost, si otra app estuviera escuchando en el mismo puerto, también existiría el riesgo de exponer el historial de visitas del usuario
Riesgo real: filtración del historial de navegación
- Si se usa comunicación local basada en HTTP, cualquier app Android que escuche en ese puerto puede obtener el historial, incluidas URLs visitadas desde el navegador
- Se desarrolló una app de prueba de concepto y se demostró en Chrome, Firefox y Edge que también son vulnerables la navegación privada y el modo incógnito
- Solo algunos navegadores como Brave y DuckDuckGo se defendían mediante listas de bloqueo propias y requisitos de consentimiento del usuario
Affected Sites
- Meta Pixel: usado en 5.8 millones de sitios web; en rastreos reales se observó intercambio de IDs locales en 15 mil sitios de la UE y 17 mil de EE. UU. dentro del top 100 mil
- Yandex Metrica: usado en 3 millones de sitios web; con el mismo método se confirmó comunicación con puertos locales en 1,260 sitios de la UE y 1,312 de EE. UU.
- En muchos de estos sitios, el rastreo se ejecutaba automáticamente incluso sin procedimiento de consentimiento de cookies
History
- Yandex: comenzó a usar puertos HTTP/HTTPS desde 2017
- Meta: cambió gradualmente de HTTP en septiembre de 2024, a WebSocket en noviembre de 2024, a WebRTC STUN en 2025 y a TURN en mayo
Abuse Vectors
- La causa principal es la falta de restricciones al acceso a sockets de localhost en Android y políticas de sandbox insuficientes
- Se eluden todas las protecciones existentes, como ajustes de permisos, modo incógnito del navegador o reinicio del ID de publicidad
- Aunque es difícil distinguirlo de usos legítimos para desarrollo web, queda como un caso comprobado de rastreo a gran escala
- Navegadores como Chrome, Firefox, DuckDuckGo y Brave están aplicando parches de emergencia, pero a nivel estructural sigue siendo necesario reforzar permisos, advertencias, sandbox y políticas de IPC en la plataforma
Disclosure
- Se solicitó divulgación responsable y cooperación a proveedores de navegadores como Chrome, Firefox, DuckDuckGo y Brave
- Chrome (versión 137), Firefox (versión 138) y Brave ya aplicaron medidas de corto plazo como bloqueo de puertos vulnerables y de SDP Munging
- A largo plazo, se enfatiza la necesidad de mejoras estructurales como control de acceso a la red local, refuerzo del sandbox e información al usuario
| Navegador | Versión | Yandex | Estado de mitigación/bloqueo | |
|---|---|---|---|---|
| Chrome | 136.0+ | Afectado | Afectado | Desde 137 bloquea puertos y SDP munging; implementación gradual en curso |
| Edge | 136.0+ | Afectado | Afectado | No claro (basado en Chromium) |
| Firefox | 138.0.2 | Afectado | No afectado(1) | Bloqueo de SDP munging; el bloqueo de UDP llegará después |
| DuckDuckGo | 5.233.0 | Parcialmente afectado(2,3) | No afectado(2,3) | Bloqueo basado en lista negra |
| Brave | 1.78.102 | No afectado(3,4) | No afectado(3,4) | Desde 2022 requiere consentimiento del usuario para solicitudes a localhost y aplica lista negra |
- 1: SDP Munging bloqueado; los puertos TURN aún no están bloqueados (previsto para más adelante)
- 2,3,4: Diversas defensas como listas negras, bloqueo de puertos y consentimiento del usuario
Estado de conocimiento entre usuarios y operadores
Operadores de sitios web
- La documentación oficial de Meta y Yandex no había revelado este método
- Desde septiembre de 2024, en foros de desarrolladores de Facebook comenzaron a repetirse preguntas como "¿por qué el script de Pixel accede a localhost?", pero no hubo respuesta oficial
- La mayoría de operadores de sitios y usuarios finales no lo sabían. El rastreo era posible incluso si el usuario no había iniciado sesión, usaba modo incógnito o había borrado las cookies
Usuarios generales
- El rastreo funciona independientemente de si el usuario ha iniciado sesión o no
- Se neutralizan protecciones como el modo incógnito y el borrado de cookies
- Hay muchos casos donde funciona incluso en sitios sin consentimiento de cookies
Resumen de preguntas frecuentes
- P: ¿Por qué Meta dejó de usar este método justo después de hacerse público?
R: No hubo respuesta oficial, pero se confirmó que dejó de enviar paquetes a usuarios Android tras la divulgación - P: ¿La investigación fue peer-reviewed?
R: Algunas instituciones la verificaron, pero antes de la revisión formal del paper se decidió publicarla rápidamente por la magnitud potencial del abuso - P: ¿Aparece en documentación oficial de Meta/Yandex?
R: No existe documentación técnica oficial; solo hay preguntas en foros de desarrolladores - P: ¿iOS u otras plataformas también están afectadas?
R: Hasta ahora solo se confirmó en Android, aunque técnicamente iOS, escritorio y Smart TV también podrían estar en riesgo
11 comentarios
Qué raro, consumía mucha batería, así que había borrado todas las apps de Meta, y resulta que estaba pasando algo así... Creo que también voy a tener que borrar con
adbtodas las demás apps del sistema integradas en mi Galaxy.Yo tampoco confío en la app de Meta, así que no la uso; en su lugar, solo la uso desde Chrome dentro de la carpeta segura.
La mayoría de los frameworks que se suelen llamar apps web híbridas levantan un servidor web en
localhost(aunque con otro propósito). Lo usan para resolver, del lado del servidor web levantado enlocalhost(la parte nativa), cosas que no se pueden solucionar ni con la configuración de la biblioteca de navegador integrada (WebKit...) ni con personalizaciones (la parte web). Se podía aprovechar también de esta manera... qué lástima.En mi opinión, en las apps híbridas la forma común de comunicación entre web y app es mediante APIs proporcionadas por el SO y el navegador, también llamadas bridges. No creo que un servidor web local sea indispensable.
Creo que el problema de usar un servidor web local ahí es que, por ejemplo, se pueden dar vulnerabilidades como acceder a un puerto de localhost desde Chrome en modo incógnito y romper el anonimato del usuario. Si esta tecnología fuera indispensable en las apps híbridas... entonces las apps híbridas deberían desaparecer.
Es común abrir y usar un servidor web dentro de la app para manejar funciones que requieren un nombre de dominio de forma obligatoria,
localStoragey cosas por el estilo.Si no pago por el servicio, entonces yo soy el producto. Cada vez habrá más intentos de rastrear a las personas a través de sus datos, y no parece que haya forma de revertir esa tendencia. Necesitamos una alternativa mejor, pero bajo el capitalismo no se me ocurre muy bien cuál podría ser.
Me pregunto si el acceso a
localhostdentro y fuera de la Carpeta Segura de Galaxy está aislado.No está aislado. Si ejecuto
python http.servercon Termux fuera de la Carpeta Segura y entro desde Chrome dentro, sí se conecta.¿Esto no es una vulnerabilidad de seguridad? -_-??
Parece que la respuesta correcta es no usar redes sociales...
Comentarios en Hacker News
Resumiendo el proceso general de rastreo que usa Meta según lo entendí yo, tomando como referencia el blog de Localmess:
Incluso en modo incógnito sigue siendo posible rastrear.
Esta parte del proceso ni siquiera aparece en las herramientas para desarrolladores del navegador.
La app envía la información de _fbp y el ID de usuario a los servidores de Meta.
Además, hay varios puntos importantes:
Esta forma de compartir IDs de la web a la app elude protecciones de privacidad comunes como borrar cookies, el modo incógnito o los controles de permisos de Android.
Incluso abre la posibilidad de que apps maliciosas espíen la actividad web del usuario.
Desde mediados de mayo, el script de Meta Pixel también empezó a enviar la cookie _fbp mediante WebRTC TURN, método adoptado después de que el equipo de Chrome bloqueara SDP Munging.
Hasta el 2 de junio de 2025, no se ha observado que las apps de Facebook/Instagram realmente reciban nada por ese nuevo puerto.
Si uno de los usos principales de WebRTC es obtener información como la IP local del usuario para desanonimizarlo, no entiendo por qué algo así puede ejecutarse sin pedir permisos aparte.
Según el país, visitar un sitio como something-embarassing.com puede tener consecuencias mucho más serias que solo pasar vergüenza.
No lo termino de entender, pero me pregunto si esto también implica abusar de los avisos obligatorios de consentimiento de cookies del GDPR para rastrear a la gente de forma encubierta.
Quisiera simplemente prohibir la publicidad y el rastreo en internet.
Por culpa de esto sale demasiada basura sin sentido.
Todo esto existe porque los CEO quieren comprarse un yate más.
Reddit también recolecta bastantes huellas digitales del dispositivo.
Además está vendiendo esos datos para entrenar modelos de IA.
Me imagino que pronto llegará el día en que vendan activamente hasta datos privados que solo deberían existir dentro de apps premium.
Sigue quedando la pregunta de cómo se podría prohibir esto, y cómo demostrarías que alguien violó esa ley.
El impulso por sacar las cookies de terceros del navegador era, en la práctica, el primer paso más realista.
Pero Google lo saboteó el año pasado usando su dominio sobre Chrome.
Tal vez no fue ilegal, pero sí fue una manipulación de mercado poco ética que debió provocar indignación entre los consumidores.
Parece que los ejecutivos de Google al principio creían que podían mantener los ingresos sin cookies, y en realidad o nunca entendieron qué significaban las cookies, o nunca tuvieron intención de quitarlas.
Este tipo de conducta es pura codicia.
Los empresarios tradicionales exitosos durante siglos evitaban este nivel de obsesión excesiva por el beneficio propio.
Incluso líderes mediocres normalmente pueden elevarse por encima de conductas tan bajas y dirigir mejor la empresa.
Pero en un mundo donde solo queda la codicia, no queda más que reírse de la situación.
Ojalá hubiera CEO más honestos y además mejores.
Sumándome al chiste del “yate del CEO”, la verdad es que a la mayoría de los consumidores les gustan los servicios/productos que no tienen que pagar, y por eso eligen el modelo con publicidad.
De hecho, cuando hay versiones de pago y con anuncios, la opción con anuncios suele ganar 10:1.
El bloqueo de anuncios en realidad empeora la situación: la verdadera resistencia debería ser boicotear el servicio o pagar directamente por alternativas.
Una estructura como BAT (Brave Attention Token), que distribuye micropagos directamente a los sitios, me parece mucho más razonable.
La teoría sería: pago por lo que uso y yo soy el verdadero cliente, no el anunciante.
Reporte técnico real: blog de Localmess
Google dice que está investigando casos de abuso, pero paradójicamente Google mismo rastrea a todo el mundo usando varios canales laterales, como los nombres de los AP Wi‑Fi.
Las grandes empresas de apps siguen recolectando datos con métodos parecidos para esquivar las restricciones del sistema operativo.
Otra razón más para no instalar apps de big tech y usar sus sitios web solo cuando sea indispensable.
Los sitios son más lentos e incómodos, pero gracias al sandbox son mucho más seguros.
Por ejemplo, en teléfonos Samsung varias apps de Meta vienen preinstaladas, y aunque borres solo la app de Facebook, a veces quedan servicios ocultos como com.facebook.services.
Esos servicios solo se pueden eliminar con herramientas de desarrollador (ADB/UAD).
Si no, recomendaría un iPhone o un Pixel.
Información técnica relacionada con el script de Meta Pixel:
Hasta octubre de 2024, Meta Pixel enviaba por HTTP, y las apps de Facebook/Instagram siguen escuchando en ese puerto todavía hoy.
También están escuchando en el nuevo puerto 12388, pero todavía no se ha encontrado ningún script que envíe nada a ese puerto.
Sobre eso, existe la curiosidad científica (?) de si otra app podría mandar mensajes falsos a ese puerto.
Una es no enviar nada, y la otra es enviarles montones de datos falsos.
Incluso estaría bien tener un dispositivo que comparta cookies de rastreo publicitario por P2P.
Me pregunto si este rastreo puede cruzarse entre perfiles.
Si fuera así, para una empresa sería un problema de seguridad enorme.
Probé levantando un servidor en el puerto 8080 desde una app userland, y ambos perfiles podían acceder.
Eso significaría que una app infectada en un perfil podría intercambiar datos con sitios visitados desde otro perfil.
Me pregunto si, si una persona recopilara información del computador de otra de esta manera, podrían castigarla bajo la CFAA (Computer Fraud and Abuse Act).
Este método requiere controlar el código de un lado (el sitio que se visita) y del otro lado (la app que corre en el teléfono).
No es una técnica mágica de hackeo para robar historial arbitrario del navegador.
Por eso cuesta verlo claramente como hacking, y aunque Google/Meta hagan rastreo sin consentimiento, probablemente no encajaría en la CFAA.
En realidad, bajo la CFAA hubo gente procesada simplemente por usar “ver código fuente” en el navegador.
Parece que importa menos el acto en sí que a quién molestaste y cuál era tu relación con la red.
Sí podría haber castigo.
Ese sistema de IDs era demasiado fácil de abusar, y supongo que Google lo sabía y sabía también que tenía que crear reglas obligatorias contra ese abuso.
Es algo que podría terminar en sanciones como baneo permanente de Play Store, acciones legales e incluso denuncias penales.
Pero en la práctica, cuando se trata de una empresa tan grande como Meta, parece casi imposible aplicar sanciones reales.
(Y aunque no fuera Meta, también cabe la posibilidad de que este tipo de movimientos sospechosos cuenten con la aprobación tácita de agencias de inteligencia o fuerzas del orden; detener algo así es muy difícil y hasta hablar del tema cuesta.)
Tienen más de 50 formas propias de rastrear.
Otras empresas también ganan mucho dinero renegociando cláusulas de intercambio de datos de usuarios con grandes corporaciones.
Los acuerdos ya están cerrados y los permisos ya fueron concedidos; lo único que pasa es que algunos usuarios están armando escándalo por ello.
En Firefox se puede bloquear WebRTC cambiando la opción
media.peerconnection.enabledafalseenabout:config.Combinando Netguard y Nebulo en modo non-VPN se pueden bloquear conexiones innecesarias a los servidores de Meta.
Creo que la Unión Europea debería imponer multas de nivel récord por problemas como este.
También estaría bien introducir un impuesto progresivo que aumente de 1~X% cada vez que reincidan.
Y haría falta además un sitio web donde se puedan ver de un vistazo las infracciones de cada empresa.
Meta sigue registrando alrededor de 70 mil millones de dólares de ganancia neta al año incluso pagando multas.
No solo multas: en algunos casos, a personas las han metido en la cárcel por infracciones mucho menores, así que harían falta medidas todavía más duras.