Cuando se habla de privacidad, y digo eso de «yo no tengo WhatsApp», la gente siempre contesta eso de «yo no tengo nada que ocultar»… y hay una frase que se podría usar mucho cuando alguien me pregunta por la seguridad de su web:
«Mi sitio no tiene nada que ocultar.»
Y casi siempre respondo con otra pregunta: ¿estás seguro de que tu servidor no está contando tu vida a extraños mientras hablamos?
Hace unas semanas volví a instalar un WordPress limpio para hacer pruebas. Abrí el escritorio, dejé el navegador quieto un minuto y revisé los logs de salida. En sesenta segundos, mi instalación (sin que yo hubiera hecho nada) había iniciado once conversaciones distintas con servidores de WordPress.org. No para descargar actualizaciones. Para informar. Y lo que contaba era mucho más detallado de lo que la mayoría imagina.
El problema: un parte médico que nadie pidió
Cuando WordPress comprueba si hay novedades, no pregunta «¿hay algo nuevo?». Envía un expediente. Lo he capturado todo con el logger de nuestro plugin Telemetry disabler (by ROBOTSTXT), y los números hablan por sí solos.
El version-check original: sesenta extensiones y tu dirección
La petición principal es un POST a api.wordpress.org/core/version-check/1.7/. En su forma original, el cuerpo de la petición incluye:
- La versión exacta del core:
7.2-alpha-63320(estoy usando la versión de desarrollo de WordPress, que conste). - La versión completa de PHP:
8.5.10. - El locale:
en_US. - La base de datos al completo:
11.8.9-MariaDB-ubu2404-log. Ese sufijo-ubu2404-logno es decorativo; dice que uso Ubuntu 24.04 y que el log de MariaDB está activo. - El número de blogs:
1. El número de usuarios:1. Si fuera multisitio, lo sabrían. - La versión inicial de la base de datos:
61833. - Una lista exhaustiva de extensiones PHP cargadas: sesenta y tres en total, desde
bcmathhastazlib, cada una con su versión. Algunas filtran más de la cuenta:imagickreportaba@PACKAGE_VERSION@, un artefacto típico de compilaciones concretas que delata cómo está construido el binario. - Flags de plataforma: sistema operativo
Linux, arquitectura64. - Soporte de imagen: qué formatos maneja GD (
webp,avif) y qué formatos maneja Imagick (webp,avif,heic,jxl). Es decir, un mapa completo de las capacidades gráficas del servidor. - Traducciones instaladas, con metadatos de GlotPress: fechas de revisión,
Project-Id-Version(WordPress - 7.1.x - Development - Administration) y el generador (GlotPress/4.1.0).
Todo esto viaja acompañado de dos cabeceras personalizadas: wp_install y wp_blog, ambas con la URL completa del sitio. Y el User-Agent no se queda atrás: WordPress/7.2-alpha-63320; https://robotstxt-telemetry.example.com/. Es una tarjeta de visita digital.
El resto del escritorio: navegador, eventos y noticias
Pero el version-check no viene solo. En la misma carga del dashboard aparecen:
browse-happy: unPOSTque envía eluseragentcompleto de tu navegador para decirte si está «desactualizado».serve-happy: unGETque informa de tu versión de PHP.stable-check: consulta el estado de la rama estable.- Feeds de noticias:
wordpress.org/news,make.wordpress.org/coreyplanet.wordpress.org, con la versión de WordPress en la cadena de búsqueda (?s=7.2). - Eventos de la comunidad: un
GETaapi.wordpress.org/events/1.0/que envía tu IP pública (ip=82.152.2.0) y la zona horaria del sitio (timezone=Atlantic/Reykjavik). Es una de las pocas peticiones del core que manda datos de geolocalización reales.
Y luego están las comprobaciones de plugins y temas. El POST a plugins/update-check/1.1/ no solo lista qué plugins tienes instalados y en qué versión. Enviaba también RequiresWP, RequiresPHP, UpdateURI, y en algunos casos dependencias como RequiresPlugins: woocommerce. Las traducciones de cada plugin incluían fechas de revisión que permiten inferir cuándo se actualizó por última vez el paquete de idioma.
En resumen: en menos de un minuto, una instalación vacía había emitido un perfil completo de su stack, su ubicación aproximada, su navegador, sus plugins y sus hábitos de traducción. Todo a una única entidad. Todo sin que el administrador lo hubiera autorizado explícitamente.
La explicación: de registrar a filtrar
El primer paso fue, como siempre, entender antes de actuar. Por eso Telemetry disabler empezó siendo un logger: intercepta cada petición HTTP saliente de WordPress mediante el filtro http_request_args, guarda método, URL, cabeceras, cuerpo y, lo más importante, la traza de llamadas (caller) que revela qué función (y qué plugin) originó la petición. Antes de escribir nada en base de datos se redactan secretos: authorization, token, api_key, cookies, contraseñas. Un registro de telemetría que filtre tokens es peor que no tener registro.
Pero registrar solo sirve para constatar el problema. La parte difícil era la segunda: reducir sin romper.
Cómo funciona el filtrado
El plugin añade controles granulares. No es un interruptor de «todo o nada», porque «nada» significa no recibir actualizaciones de seguridad. Lo que hemos hecho es definir, para cada tipo de petición, qué es estrictamente necesario y qué es ruido.
He pasado la misma instalación al modo estricto y he vuelto a capturar todo. La diferencia es abrumadora.
El version-check en modo estricto:
- Desaparecen los sesenta y tres campos de extensiones PHP.
- Desaparecen
blogs,users,multisite_enabled,initial_db_version. - Desaparecen
platform_flagseimage_support. - MySQL se reduce a
11.8.9-MariaDB: sin distro, sin sufijo de log. - Las traducciones conservan solo la fecha de revisión; se eliminan
Project-Id-VersionyX-Generator. - Se eliminan las cabeceras
wp_installywp_blog. - El User-Agent pasa a ser
WordPress/0.0.0. La URL del sitio desaparece por completo.
Curiosamente, la versión exacta del core (7.2-alpha-63320) sigue presente en la URL del version-check. Esto es deliberado: el API de WordPress.org necesita saber qué versión tienes para ofrecerte el paquete correcto, especialmente si estás en un canal de desarrollo. El plugin distingue entre dónde puedes anonimizar (el User-Agent) y dónde no puedes (el payload de actualización).
Plugins y temas:
En modo estricto, la comprobación de plugins envía solo Version, RequiresWP, RequiresPHP, UpdateURI y RequiresPlugins. Se eliminan nombres de autores, descripciones y metadatos extendidos. El locale se fuerza a en_US para evitar filtrar el idioma real del administrador. Las traducciones se recortan al mínimo.
Lo que desaparece por completo:
browse-happy: ya no se envía el navegador.serve-happy: ya no se envía la versión de PHP de forma aislada.stable-checky los feeds de desarrollo: innecesarios si no estás en el canal beta.- El widget de eventos: en modo estricto no se consulta
api.wordpress.org/events, así que tu IP y tu zona horaria no salen del servidor. - Los feeds de noticias de WordPress.org pueden sustituirse por alternativas neutrales.
Los otros: cuando el que habla no es el core
WordPress.org no es el único destino. Los plugins comerciales usan los mismos ganchos para enviar telemetría a sus propios servidores: Freemius, StellarWP, Themeisle, Mixpanel, Kadence, The Events Calendar… En el plugin hemos mapeado perfiles de comportamiento de cerca de noventa y nueve SDKs populares. Cada uno puede dejarse en modo Original o activarse su Safe mode, que reduce los datos a lo imprescindible para que la licencia o la funcionalidad sigan funcionando. Las claves de licencia, por cierto, nunca se tocan: bloquearlas rompería el servicio, y no es lo mismo ocultar tu stack que impedirte acceder a un producto de pago.
Las implicaciones: qué hay que pensar antes de tocar
El primer aviso obligado: ocultar un plugin del repositorio oficial implica dejar de recibir sus notificaciones de actualización automáticas. Es una consecuencia directa, no un bug. Si ocultas un plugin que vive en WordPress.org, el sistema no sabe que lo tienes instalado y no te avisará de vulnerabilidades. Es una decisión consciente: útil para plugins privados o de terceros, peligrosa para el plugin de un formulario de contacto que actualizan cada mes.
Segundo: un log de peticiones salientes es sensible por definición. Por eso el plugin redacta secretos antes de escribir, limita el tamaño de los cuerpos almacenados, rota los registros cada doce a setenta y dos horas y fija un máximo de mil entradas. Registrar para auditar no debe convertirse en crear una nueva fuente de filtración.
Tercero, y este es el que me motiva a escribir esto: la soberanía digital empieza en el propio servidor. Hablamos mucho de no depender de Google Analytics o de no usar CDNs extranjeros, pero a menudo ignoramos que nuestro CMS está haciendo un informe diario de nuestra infraestructura a servidores en Estados Unidos. No es que sea ilegal ni siquiera que sea oculto; está documentado en el código. Pero «documentado» no es lo mismo que «consentido», y el principio de minimización de datos del RGPD no debería aplicar solo a los formularios de contacto que rellenan tus clientes. También aplica a las conversaciones que tu servidor mantiene mientras duermes.
Conclusión
Después de años gestionando cientos de sitios WordPress, he aprendido que la privacidad no es un plugin que instalas y olvidas. Es un hábito de revisar qué sale antes de preocuparte por qué entra. Telemetry disabler nació de esa necesidad: primero ver, luego decidir, nunca romper.
Si tienes un WordPress y nunca has mirado los logs de salida, haz la prueba. Instala algo que registre las peticiones HTTP durante un minuto. Es probable que descubras que tu servidor es más parlanchín de lo que pensabas. Y si decides que prefiere callarse un poco, ahora al menos puedes hacerlo sin quedarte sin actualizaciones.
Porque la soberanía digital no es solo decidir dónde hospedas tus datos. También es decidir qué cuentas de ti mismo cuando nadie te está preguntando.
Deja una respuesta