Las permacookies de Telefónica y la inyección de cabeceras

Permacookies y supercookies: cuando tu operadora te espía

En 2015, la Agencia Española de Protección de Datos (AEPD) sancionó a Telefónica Móviles España por una práctica que afectaba a millones de usuarios de telefonía móvil: la inyección de cabeceras HTTP con identificadores únicos de rastreo, conocidos como supercookies o permacookies. Esta técnica permitía a la operadora —y potencialmente a terceros— rastrear la navegación web de los usuarios sin su conocimiento ni consentimiento.

A diferencia de las cookies convencionales, que el usuario puede eliminar desde el navegador, las permacookies operan a nivel de red: se inyectan en cada petición HTTP que sale del dispositivo antes de que llegue al servidor de destino. El usuario no puede verlas, no puede borrarlas y, en la mayoría de los casos, ni siquiera sabe que existen. En este artículo analizamos en profundidad cómo funciona esta técnica, por qué es tan invasiva, qué decidió la AEPD y qué puedes hacer para proteger tu privacidad en la navegación móvil.

¿Qué es la inyección de cabeceras HTTP?

Para comprender el problema, es necesario entender cómo funciona la comunicación entre tu teléfono móvil y los sitios web que visitas. Cada vez que accedes a una página web, tu dispositivo envía una petición HTTP al servidor que aloja esa página. Esa petición incluye una serie de cabeceras (headers) con información técnica: el tipo de navegador, el idioma preferido, las cookies almacenadas, etc.

En una conexión normal, estas cabeceras las genera exclusivamente tu navegador. Sin embargo, cuando navegas a través de la red móvil de tu operadora, todo el tráfico HTTP pasa por los servidores proxy de la operadora antes de llegar a su destino. Esto crea una oportunidad para que la operadora modifique las peticiones en tránsito, añadiendo cabeceras adicionales que el usuario no ha solicitado.

Cómo funciona la inyección paso a paso

El proceso de inyección de cabeceras HTTP por parte de una operadora se puede describir en cinco pasos:

1. El usuario solicita una página web: El dispositivo móvil genera una petición HTTP estándar (por ejemplo, GET /pagina HTTP/1.1) con las cabeceras normales del navegador.
2. La petición pasa por el proxy de la operadora: Todo el tráfico de datos móviles se enruta a través de la infraestructura de red de la operadora, incluyendo servidores proxy y gateways.
3. El proxy inyecta una cabecera adicional: Antes de reenviar la petición al servidor web de destino, el proxy de la operadora añade una cabecera personalizada con un identificador único asociado a la línea del usuario. Por ejemplo: X-UIDH: a]4fkQ3fhJOp.
4. El servidor de destino recibe la petición modificada: El sitio web recibe tanto las cabeceras originales del navegador como la cabecera inyectada por la operadora. Si el sitio está preparado para leerla, puede identificar al usuario de forma unívoca.
5. El identificador persiste en cada petición: A diferencia de una cookie, que se almacena en el dispositivo, la cabecera se inyecta en cada petición HTTP que sale de la red móvil. No importa si el usuario borra las cookies, usa el modo incógnito o cambia de navegador: el identificador sigue ahí.

Para visualizarlo de forma sencilla, imaginemos el flujo de una petición:

Dispositivo del usuario → envía petición HTTP normal → Proxy de la operadora (intercepta y añade cabecera X-UIDH) → Servidor web de destino (recibe la petición con el identificador inyectado)

Este esquema convierte a la operadora en un intermediario activo que modifica las comunicaciones del usuario, una práctica que plantea serios problemas tanto técnicos como legales.

¿Qué hizo Telefónica Móviles exactamente?

Según la investigación de la AEPD y los análisis técnicos publicados por investigadores independientes, Telefónica Móviles España inyectaba cabeceras HTTP personalizadas en las peticiones de sus usuarios de datos móviles. Estas cabeceras contenían identificadores únicos que permitían vincular toda la actividad de navegación de un usuario a su línea telefónica.

La práctica se realizaba de forma silenciosa y sistemática: no se informaba al usuario, no se solicitaba su consentimiento y no existía un mecanismo para desactivarla. Los identificadores inyectados funcionaban como una suerte de DNI digital invisible que acompañaba al usuario en cada página que visitaba a través de la conexión de datos móviles.

Implicaciones técnicas de la inyección

La gravedad de esta práctica radica en varios factores técnicos:

• Persistencia: El identificador no se almacena en el dispositivo, por lo que el usuario no puede eliminarlo. Borrar cookies, caché o historial de navegación no tiene ningún efecto.
• Invisibilidad: Las cabeceras inyectadas no son visibles para el usuario en la interfaz normal del navegador. Solo un análisis técnico de las peticiones HTTP permite detectarlas.
• Ubicuidad: La cabecera se añade a todas las peticiones HTTP que salen por la red de datos móviles, no solo a las dirigidas a servicios de Telefónica.
• Uso por terceros: Cualquier servidor web que recibiese la petición podía leer la cabecera inyectada. Esto significaba que redes publicitarias, sitios de analítica y cualquier tercero podían utilizar el identificador para rastrear al usuario sin necesidad de instalar cookies propias.
• Correlación cruzada: El identificador permitía vincular la actividad en diferentes sitios web, creando un perfil de navegación completo del usuario: qué páginas visita, con qué frecuencia, en qué horarios, qué intereses tiene.

Cookies, supercookies y permacookies: diferencias fundamentales

Para comprender por qué las permacookies son especialmente peligrosas, es necesario compararlas con otros mecanismos de tracking en la navegación móvil y de escritorio.

Cookies convencionales (first-party y third-party)

Las cookies HTTP son pequeños archivos de texto que un sitio web almacena en el navegador del usuario. Las cookies de primera parte (first-party) las establece el propio sitio visitado y son necesarias para funciones legítimas como mantener la sesión iniciada. Las cookies de terceros (third-party) las establecen dominios distintos al visitado (típicamente redes publicitarias) y se utilizan para rastrear al usuario entre sitios.

Control del usuario: Las cookies se almacenan en el navegador y pueden ser eliminadas, bloqueadas o gestionadas por el usuario. Los navegadores modernos permiten bloquear cookies de terceros y muchos lo hacen por defecto.

Supercookies (almacenamiento alternativo)

El término supercookie se ha utilizado históricamente para referirse a mecanismos de almacenamiento que son más difíciles de eliminar que las cookies convencionales. Incluyen técnicas como:

• Flash LSOs (Local Shared Objects): Cookies almacenadas por el plugin Adobe Flash, que no se eliminaban al borrar las cookies del navegador. Con la desaparición de Flash en 2020, esta técnica quedó obsoleta.
• Almacenamiento HTML5: localStorage, sessionStorage, IndexedDB y el caché del navegador pueden utilizarse para almacenar identificadores de rastreo que sobreviven a la eliminación de cookies estándar.
• ETags del caché HTTP: Un servidor puede asignar un identificador único a un recurso en caché mediante la cabecera ETag. Cuando el navegador solicita de nuevo el recurso, envía el ETag almacenado, lo que permite identificar al usuario.

Control del usuario: Aunque más difíciles de eliminar que las cookies convencionales, las supercookies basadas en almacenamiento local pueden eliminarse borrando todos los datos del navegador o usando herramientas especializadas.

Supercookies HSTS

Una variante particularmente ingeniosa es la supercookie basada en HSTS (HTTP Strict Transport Security). HSTS es un mecanismo de seguridad por el cual un sitio web indica al navegador que solo debe conectarse mediante HTTPS. Un sitio malicioso puede configurar múltiples subdominios con distintas políticas HSTS, creando un patrón binario (subdominio con HSTS = 1, sin HSTS = 0) que actúa como un identificador único del navegador.

Control del usuario: Eliminar el caché HSTS del navegador borra este identificador, aunque la mayoría de usuarios desconoce su existencia.

Browser fingerprinting (huella digital del navegador)

El browser fingerprinting no utiliza almacenamiento de ningún tipo. En su lugar, recopila características técnicas del navegador y del dispositivo —resolución de pantalla, fuentes instaladas, plugins, configuración de idioma, canvas fingerprint, WebGL renderer— para generar una «huella digital» estadísticamente única.

Control del usuario: Es extremadamente difícil de evitar. Las técnicas anti-fingerprinting (como las implementadas por Tor Browser o Brave) intentan homogeneizar las respuestas del navegador para que todos los usuarios parezcan iguales, pero no son infalibles.

Permacookies (inyección de cabeceras por la operadora)

Las permacookies, como las empleadas por Telefónica, operan a un nivel completamente distinto. No dependen del navegador ni del dispositivo: son inyectadas por la infraestructura de red de la operadora en cada petición HTTP.

Control del usuario: Prácticamente nulo dentro de la conexión de datos móviles. Ninguna acción en el navegador puede prevenir ni eliminar la inyección. Las únicas defensas efectivas son el uso de HTTPS (que impide la modificación de las cabeceras al ir cifrado el tráfico) o una VPN (que encapsula el tráfico antes de que la operadora pueda manipularlo).

Tabla comparativa de mecanismos de tracking

Mecanismo	¿Dónde opera?	¿El usuario puede eliminarlo?	¿Funciona con HTTPS?	¿Funciona entre sitios?
Cookie first-party	Navegador	Sí, fácilmente	Sí	No
Cookie third-party	Navegador	Sí, fácilmente	Sí	Sí
Supercookie (Flash/HTML5)	Navegador/Plugin	Sí, con esfuerzo	Sí	Varía
Supercookie HSTS	Navegador (caché)	Sí, borrando caché HSTS	Sí	Sí
Browser fingerprinting	Navegador (sin almacenamiento)	No directamente	Sí	Sí
Permacookie (inyección ISP)	Red de la operadora	No	No (HTTPS lo impide)	Sí

No solo Telefónica: operadoras de todo el mundo atrapadas

Telefónica no fue la única operadora en implementar este tipo de rastreo. La inyección de cabeceras HTTP ha sido una práctica documentada a nivel global, afectando a millones de usuarios en distintos países.

Verizon y el escándalo X-UIDH (Estados Unidos)

El caso más conocido internacionalmente es el de Verizon Wireless, la mayor operadora móvil de Estados Unidos. En 2014, investigadores de la Electronic Frontier Foundation (EFF) y otros analistas descubrieron que Verizon inyectaba una cabecera denominada X-UIDH (Unique Identifier Header) en todas las peticiones HTTP de sus clientes móviles.

El identificador, bautizado como «perma-cookie» por la prensa, se asignaba de forma persistente a cada línea y no podía ser desactivado por el usuario. La Federal Communications Commission (FCC) investigó el caso y en 2016 impuso a Verizon una multa de 1,35 millones de dólares. Además, la FCC obligó a Verizon a obtener el consentimiento explícito de los usuarios antes de compartir datos de navegación con terceros y a ofrecer un mecanismo de exclusión (opt-out).

Lo particularmente grave del caso Verizon fue que la empresa publicitaria Turn Inc. utilizó los identificadores inyectados por Verizon para «resucitar» cookies que los usuarios habían borrado deliberadamente: si un usuario eliminaba las cookies de Turn, esta empresa podía recrearlas asociándolas al mismo X-UIDH, anulando así cualquier intento del usuario de proteger su privacidad.

AT&T (Estados Unidos)

AT&T, la segunda operadora de Estados Unidos, también fue descubierta inyectando cabeceras similares en las peticiones de sus clientes. Tras la presión mediática y regulatoria generada por el caso Verizon, AT&T cesó la práctica de forma más discreta, pero no antes de que investigadores documentasen la existencia de cabeceras inyectadas en su red.

Otras operadoras documentadas

Investigaciones realizadas por organizaciones como Access Now y análisis técnicos publicados por investigadores independientes identificaron prácticas de inyección de cabeceras en operadoras de diversos países:

• Bharti Airtel (India): Documentada inyectando cabeceras de identificación en peticiones HTTP.
• Vodafone (varios países europeos): Se detectaron cabeceras inyectadas en algunas redes nacionales de Vodafone.
• Cricket Wireless y Bell Canada: También fueron identificadas en estudios académicos sobre inyección de cabeceras en operadoras de América del Norte.

Estos casos demuestran que la inyección de cabeceras HTTP por parte de operadoras no fue un incidente aislado, sino una práctica sistemática de la industria de las telecomunicaciones a nivel mundial durante la primera mitad de la década de 2010.

La sanción de la AEPD a Telefónica

La Agencia Española de Protección de Datos inició un procedimiento sancionador contra Telefónica Móviles España tras recibir denuncias y evidencias técnicas sobre la inyección de cabeceras. La resolución de la AEPD abordó varios aspectos fundamentales.

Los hechos probados

La AEPD determinó que Telefónica Móviles inyectaba en las peticiones HTTP de sus clientes de datos móviles una cabecera con un identificador único asociado a cada línea. Este identificador se añadía de forma automática, sin intervención del usuario, a todas las peticiones HTTP (no HTTPS) que transitaban por la red de datos móviles de la operadora.

La investigación confirmó que:

• El identificador era único por línea telefónica, lo que permitía asociar toda la navegación HTTP a un usuario concreto.
• No se había informado a los clientes sobre la existencia de esta práctica ni sobre su finalidad.
• No se había obtenido el consentimiento de los usuarios para el tratamiento de sus datos de navegación mediante este mecanismo.
• No existía un mecanismo para que el usuario pudiera oponerse o desactivar la inyección de cabeceras.

La base jurídica de la sanción

La AEPD consideró que la práctica de Telefónica vulneraba la Ley Orgánica de Protección de Datos (LOPD, entonces vigente) en varios puntos:

• Principio de información (art. 5 LOPD): Telefónica no informó a sus clientes de que estaba inyectando identificadores de rastreo en sus comunicaciones.
• Consentimiento (art. 6 LOPD): No se obtuvo el consentimiento de los usuarios para el tratamiento de sus datos personales (los identificadores de navegación constituyen datos personales al permitir identificar a un individuo concreto).
• Secreto de las comunicaciones: La inyección de cabeceras implica una modificación activa de las comunicaciones del usuario, lo que plantea además cuestiones sobre la integridad del tráfico de datos.

La AEPD impuso una sanción económica a Telefónica y le exigió cesar la práctica de inmediato. Aunque el importe exacto de la sanción varió según las fuentes y el procedimiento específico, el caso sentó un precedente importante en España sobre los límites del tracking de operadoras móviles y la obligación de respetar la privacidad de los usuarios en el tratamiento de datos de navegación.

Relevancia del caso bajo el RGPD

Es importante señalar que los hechos sancionados ocurrieron bajo el régimen de la LOPD anterior al Reglamento General de Protección de Datos (RGPD), que entró en vigor en mayo de 2018. Bajo el RGPD, las sanciones habrían sido potencialmente mucho más severas: el reglamento europeo permite multas de hasta el 4% de la facturación global anual de la empresa infractora, lo que en el caso de Telefónica podría haber supuesto cientos de millones de euros.

Además, el RGPD refuerza el principio de privacidad por defecto y por diseño (privacy by default and by design), lo que hace que una práctica como la inyección silenciosa de cabeceras de rastreo sea aún más claramente incompatible con la normativa vigente.

Cómo HTTPS mitigó el problema de la inyección de cabeceras

Uno de los factores que más ha contribuido a reducir el impacto de las permacookies ha sido la adopción masiva de HTTPS. Para entender por qué, es necesario comprender la diferencia fundamental entre HTTP y HTTPS en relación con la inyección de cabeceras.

HTTP: tráfico en texto plano

En una conexión HTTP convencional, todo el tráfico viaja sin cifrar entre el dispositivo del usuario y el servidor web. Esto significa que cualquier intermediario —incluida la operadora— puede leer y modificar el contenido de las peticiones y respuestas. La inyección de cabeceras es técnicamente trivial en este escenario: el proxy de la operadora simplemente añade una línea de texto a la petición antes de reenviarla.

HTTPS: conexión cifrada de extremo a extremo

En una conexión HTTPS, el tráfico se cifra mediante TLS (Transport Layer Security) entre el dispositivo del usuario y el servidor web. La operadora puede ver que existe una conexión con un servidor determinado (mediante el Server Name Indication o SNI), pero no puede leer ni modificar el contenido de las peticiones ni las cabeceras HTTP. Cualquier intento de inyección provocaría un error en la verificación de integridad del protocolo TLS, alertando al navegador.

La revolución de Let's Encrypt

Cuando Telefónica y Verizon implementaban sus sistemas de inyección de cabeceras (aproximadamente entre 2012 y 2015), la adopción de HTTPS era aún minoritaria. Según datos de Mozilla Firefox, en enero de 2014 solo el 29% de las páginas web cargadas por los usuarios utilizaban HTTPS.

La situación cambió drásticamente gracias a varios factores:

• Let's Encrypt (2015): La autoridad de certificación gratuita y automatizada lanzada por la Internet Security Research Group eliminó la barrera económica para obtener certificados TLS. Antes de Let's Encrypt, los certificados SSL costaban entre 50 y varios cientos de euros anuales.
• Iniciativa «HTTPS Everywhere» de los navegadores: Google Chrome comenzó a marcar los sitios HTTP como «No seguros» en 2017, y Firefox siguió poco después. Esto incentivó masivamente la migración a HTTPS.
• HTTP/2 y HTTP/3: Los nuevos protocolos de transferencia web requieren o favorecen fuertemente el uso de HTTPS.

En 2026, según las estadísticas de transparencia de Google, más del 95% del tráfico web en Chrome utiliza HTTPS. Esto significa que la ventana de oportunidad para la inyección de cabeceras HTTP se ha reducido drásticamente. Sin embargo, no ha desaparecido por completo: el tráfico HTTP residual, las consultas DNS no cifradas y ciertos protocolos de aplicación todavía pueden ser manipulados por intermediarios.

Técnicas modernas de tracking que reemplazan a las supercookies

La desaparición progresiva de las supercookies basadas en inyección de cabeceras no ha significado el fin del rastreo de usuarios. La industria publicitaria y tecnológica ha desarrollado técnicas más sofisticadas que operan dentro de los límites del tráfico cifrado.

CNAME cloaking

El CNAME cloaking es una técnica de rastreo que explota la resolución DNS para eludir los bloqueadores de cookies de terceros. Funciona así:

1. Un sitio web (por ejemplo, tienda.ejemplo.com) crea un subdominio como analytics.tienda.ejemplo.com.
2. Este subdominio se configura como un alias DNS (registro CNAME) que apunta al servidor de una empresa de rastreo (por ejemplo, tracker.empresa-rastreo.com).
3. Desde la perspectiva del navegador, las cookies establecidas por analytics.tienda.ejemplo.com son cookies de primera parte (pertenecen al mismo dominio que el usuario está visitando), por lo que no son bloqueadas por los filtros de cookies de terceros.
4. Sin embargo, los datos los recibe y procesa la empresa de rastreo externa.

Esta técnica ha sido documentada en estudios académicos y es utilizada por plataformas de analítica y publicidad programática. Navegadores como Safari han implementado medidas para detectar y limitar el CNAME cloaking, pero su detección no es trivial.

Bounce tracking (rastreo por rebote)

El bounce tracking elude las restricciones de cookies de terceros mediante una técnica de redirección:

1. Cuando un usuario hace clic en un enlace, en lugar de ir directamente al destino, se le redirige brevemente a un dominio de rastreo.
2. Este dominio establece una cookie de primera parte (porque, durante la fracción de segundo que dura la redirección, es el dominio «visitado» por el usuario).
3. Inmediatamente después, el usuario es redirigido a su destino original, sin percibir la redirección intermedia.

Google Chrome ha anunciado medidas para combatir el bounce tracking, y navegadores como Brave y Firefox ya implementan protecciones contra esta técnica. Sin embargo, su uso sigue siendo frecuente en la industria publicitaria.

Topics API (Privacy Sandbox de Google)

La Topics API es la propuesta de Google para reemplazar las cookies de terceros dentro de su iniciativa Privacy Sandbox. En lugar de asignar un identificador único a cada usuario, Topics API funciona de la siguiente manera:

1. El navegador Chrome analiza los sitios que visita el usuario y le asigna automáticamente una serie de «temas de interés» (por ejemplo, «deportes», «tecnología», «viajes»).
2. Cuando un sitio web solicita información para publicidad, Chrome comparte tres temas seleccionados de las últimas tres semanas, con un componente aleatorio.
3. Los anunciantes reciben información sobre intereses generales, no un identificador único del usuario.

Aunque Topics API representa una mejora respecto a las cookies de terceros en términos de privacidad, ha recibido críticas por parte de organizaciones como la EFF y defensores de la privacidad, que argumentan que sigue permitiendo la categorización de usuarios con fines publicitarios y que la definición de «temas» puede ser lo suficientemente granular como para identificar a usuarios individuales en combinación con otros datos.

Server-side tracking

Otra tendencia creciente es el rastreo del lado del servidor, donde la lógica de seguimiento se ejecuta en el servidor del propio sitio web en lugar de en el navegador del usuario. Plataformas como Google Tag Manager Server-Side y la API de conversiones de Meta (Facebook) permiten enviar datos de los usuarios directamente desde el servidor del anunciante a las plataformas publicitarias, eludiendo completamente los bloqueadores de anuncios y las restricciones de cookies del navegador.

¿Cómo protegerte del rastreo de tu operadora?

Aunque la adopción de HTTPS ha mitigado significativamente el problema de la inyección de cabeceras, existen medidas adicionales que todo usuario debería considerar para proteger su privacidad en la navegación móvil.

Usa siempre HTTPS

La primera línea de defensa contra la inyección de cabeceras es asegurarse de que toda la navegación utilice HTTPS. La mayoría de navegadores modernos ofrecen una opción para forzar HTTPS:

• Firefox: Activar el «Modo solo HTTPS» en Ajustes → Privacidad y Seguridad.
• Chrome: Activar «Usar siempre conexiones seguras» en Configuración → Privacidad y seguridad.
• Brave: Fuerza HTTPS por defecto.

Si un sitio web solo está disponible en HTTP, tu navegador te advertirá. En ese caso, considera si realmente necesitas visitar ese sitio, ya que cualquier información que envíes (incluidas contraseñas) viajará sin cifrar.

Utiliza una VPN de confianza

Una VPN (Red Privada Virtual) cifra todo el tráfico entre tu dispositivo y el servidor VPN antes de que la operadora pueda inspeccionarlo o modificarlo. Desde la perspectiva de la operadora, todo tu tráfico es un flujo cifrado hacia la dirección IP del servidor VPN: no puede ver qué sitios visitas ni inyectar cabeceras en tus peticiones.

Consideraciones al elegir una VPN:

• Evita VPNs gratuitas: Muchas VPNs gratuitas financian su servicio vendiendo los datos de navegación de sus usuarios, lo que anula completamente el propósito de usarlas.
• Política de no-logs verificada: Busca proveedores que hayan sido auditados independientemente para verificar que no almacenan registros de actividad.
• Jurisdicción: Considera la legislación del país donde opera el proveedor VPN en relación con la retención de datos y las solicitudes gubernamentales.
• Protocolos modernos: Prioriza VPNs que soporten WireGuard o OpenVPN, protocolos de código abierto y auditados.

Configura DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT)

Las consultas DNS (Domain Name System) son otro vector de vigilancia por parte de las operadoras. Cada vez que visitas un sitio web, tu dispositivo envía una consulta DNS para traducir el nombre del dominio (por ejemplo, www.ejemplo.com) a una dirección IP. Tradicionalmente, estas consultas se envían sin cifrar, lo que permite a la operadora ver qué sitios visitas incluso si el tráfico posterior va por HTTPS.

DNS-over-HTTPS (DoH) y DNS-over-TLS (DoT) cifran las consultas DNS, impidiendo que la operadora las lea. Para configurarlos:

• Firefox: Ajustes → General → Configuración de red → Activar DNS sobre HTTPS. Puedes elegir proveedores como Cloudflare (1.1.1.1) o NextDNS.
• Chrome: Configuración → Privacidad y seguridad → Seguridad → Usar DNS seguro.
• Android (DoT nativo): Ajustes → Red e Internet → DNS privado → Introducir un proveedor como dns.google o one.one.one.one.
• iOS: Requiere instalar un perfil de configuración del proveedor DNS elegido.

Usa navegadores con protección anti-tracking integrada

Algunos navegadores ofrecen protecciones avanzadas contra diversas formas de rastreo:

• Firefox con Enhanced Tracking Protection en modo estricto: bloquea cookies de terceros, criptomineros, fingerprinters y contenido de rastreo.
• Brave: Bloquea anuncios y rastreadores por defecto, incluye protección contra fingerprinting y fuerza HTTPS.
• Tor Browser: Máxima privacidad al enrutar el tráfico a través de la red Tor, pero con penalización significativa en velocidad.

Revisa periódicamente tu tráfico de red

Para usuarios técnicamente avanzados, herramientas como mitmproxy, Wireshark o la consola de desarrollo del navegador (pestaña «Red» o «Network») permiten inspeccionar las cabeceras HTTP de las peticiones salientes y detectar posibles inyecciones. Si observas cabeceras desconocidas como X-UIDH, X-ACR u otras cabeceras no estándar que no fueron generadas por tu navegador, tu operadora podría estar inyectándolas.

Preguntas frecuentes sobre permacookies y rastreo de operadoras

¿Qué son las permacookies o supercookies de las operadoras móviles?

Las permacookies (también llamadas supercookies de operadoras) son identificadores únicos que las operadoras de telefonía móvil inyectan en las cabeceras de las peticiones HTTP de sus clientes. A diferencia de las cookies convencionales, no se almacenan en el dispositivo del usuario sino que se añaden en la red de la operadora, lo que las hace imposibles de borrar desde el navegador. Se denominan «permacookies» (cookies permanentes) porque persisten independientemente de las acciones del usuario.

¿Telefónica sigue inyectando cabeceras de rastreo en 2026?

No. Tras la sanción de la AEPD, Telefónica cesó la práctica de inyección de cabeceras de rastreo. Además, la adopción generalizada de HTTPS ha hecho que esta técnica sea inviable para la inmensa mayoría del tráfico web actual, ya que el cifrado TLS impide la modificación de las cabeceras por parte de intermediarios.

¿Puede mi operadora ver qué páginas visito si uso HTTPS?

Con HTTPS, tu operadora puede ver a qué dominios te conectas (mediante las consultas DNS y el campo SNI de la conexión TLS), pero no puede ver el contenido de las páginas, las URLs específicas, los datos que envías ni las cabeceras HTTP. Para ocultar también los dominios visitados, puedes usar una VPN combinada con DNS cifrado (DoH o DoT) y Encrypted Client Hello (ECH), una extensión de TLS que cifra el campo SNI.

¿Qué diferencia hay entre una supercookie y una permacookie?

El término supercookie es más amplio y se refiere a cualquier mecanismo de rastreo más difícil de eliminar que una cookie estándar, incluyendo Flash LSOs, almacenamiento HTML5 o supercookies HSTS. Una permacookie es un tipo específico de supercookie que es inyectada por la operadora a nivel de red, lo que la hace permanente desde la perspectiva del usuario. En la práctica, ambos términos se usan a menudo de forma intercambiable cuando se habla del rastreo por operadoras.

¿Es legal que una operadora inyecte cabeceras de rastreo?

En la Unión Europea, esta práctica es ilegal sin el consentimiento informado del usuario, tanto bajo la anterior LOPD como bajo el actual RGPD. La inyección de cabeceras de rastreo constituye un tratamiento de datos personales que requiere una base legal válida, típicamente el consentimiento explícito del interesado. Además, la Directiva ePrivacy protege la confidencialidad de las comunicaciones electrónicas, y la modificación de las peticiones HTTP puede considerarse una violación de dicha confidencialidad.

¿Una VPN protege completamente de las permacookies?

Sí, una VPN protege contra la inyección de cabeceras por parte de la operadora. Al cifrar todo el tráfico entre tu dispositivo y el servidor VPN, la operadora no puede inspeccionar ni modificar las peticiones HTTP. Sin embargo, ten en cuenta que el proveedor de VPN pasa a ser un nuevo intermediario de confianza: asegúrate de elegir uno con una política de privacidad verificada.

¿Cómo puedo comprobar si mi operadora inyecta cabeceras?

Puedes verificarlo visitando servicios de detección de cabeceras HTTP como amiunique.org o usando herramientas de línea de comandos como curl -v para inspeccionar las cabeceras que envía tu navegador. Compara los resultados desde tu conexión de datos móviles con los resultados desde una conexión WiFi: si aparecen cabeceras adicionales no estándar en la conexión móvil, tu operadora podría estar inyectándolas. También puedes usar la consola de desarrollador del navegador (F12 → pestaña Network) para examinar las cabeceras de las peticiones salientes.

¿Las operadoras pueden rastrearme de otras formas además de las permacookies?

Sí. Las operadoras tienen acceso inherente a ciertos metadatos de tráfico: saben a qué torres de telefonía se conecta tu dispositivo (y por tanto tu ubicación aproximada), los registros de llamadas, los SMS y los dominios que consultas vía DNS. En la UE, la Directiva de Retención de Datos (anulada por el TJUE pero parcialmente implementada en legislaciones nacionales) obligaba a las operadoras a almacenar estos metadatos durante un periodo determinado. Para minimizar este rastreo, el uso combinado de VPN, DNS cifrado y comunicaciones cifradas de extremo a extremo es la medida más efectiva.

Conclusión: la privacidad como derecho, no como opción

El caso de las permacookies de Telefónica ilustra una realidad incómoda: las empresas que gestionan nuestra infraestructura de comunicaciones tienen la capacidad técnica de vigilar y monetizar nuestra actividad online, y en ausencia de regulación y vigilancia, algunas lo harán.

La sanción de la AEPD fue un paso importante, pero la verdadera solución ha venido de la tecnología: la adopción masiva de HTTPS, impulsada por iniciativas como Let's Encrypt, ha cerrado la puerta a la inyección de cabeceras para la mayor parte del tráfico web. Sin embargo, como hemos visto, la industria del rastreo no se detiene: técnicas como el CNAME cloaking, el bounce tracking o el server-side tracking representan nuevos desafíos para la privacidad del usuario.

La lección del caso Telefónica es clara: no podemos confiar ciegamente en que los intermediarios de nuestras comunicaciones respetarán nuestra privacidad. Protegerse requiere una combinación de herramientas técnicas (HTTPS, VPN, DNS cifrado, navegadores con anti-tracking) y un marco regulatorio robusto que sancione de forma disuasoria las prácticas abusivas.

Si necesitas asesoramiento sobre protección de datos, privacidad digital o cumplimiento normativo para tu organización, no dudes en contactarnos. En nuestro blog encontrarás más análisis técnicos y jurídicos sobre ciberseguridad y protección de la información.