CDN, fuentes y embeds: cómo decidir qué es “necesario”, qué exige consentimiento y cómo documentarlo sin autoengaños

Subtítulo: un método práctico para clasificar terceros “silenciosos”, evitar llamadas innecesarias y construir un mini-expediente defendible.

En el post anterior hablamos de vendors fantasma y terceros silenciosos. Este es el punto donde más se atasca la gente: no tanto con los píxeles o la analítica “obvia”, sino con lo que se cuela como “infraestructura” o “contenido”.

  • CDN / WAF: “solo acelera y protege”
  • Fuentes externas: “solo tipografías”
  • Embeds: “solo un vídeo / un mapa”

Y sin darte cuenta, eso se traduce en llamadas a terceros, IPs, cabeceras, a veces cookies, y en ocasiones transferencias o accesos fuera del EEE. No es que todo sea ilegal. El problema es otro:

Si no lo gobiernas, no lo puedes explicar. Y si no lo puedes explicar, no lo puedes defender.

Este artículo te da un método sencillo para decidir y documentar. Con ejemplos claros, dos gráficos y un listado de lecciones para no repetir los fallos típicos.

Gráfico 1 — Árbol de decisión rápido (para clasificar sin pelearse)

Descárgalo e insértalo en el artículo justo después de esta sección:

Árbol de decisión (PNG):

1) Primero: una aclaración que te ahorra discusiones

En cookies/trackers, muchas guías y actuaciones regulatorias acaban convergiendo en una idea: la elección debe ser real y el efecto debe ser real. La CNIL lo recuerda expresamente cuando actúa contra banners con “patrones oscuros”: rechazar debe ser tan fácil como aceptar. (cnil.fr)

En España, la AEPD insiste en el enfoque “en producción” cuando la analítica es prestada por un tercero: roles, configuración real y evidencias. (AEPD)

¿Traducción GRC? Da igual cómo lo cuentes: hay que poder probar lo que ocurre.

 

2) Qué significa “necesario” (en web/app) sin trampas semánticas

En la práctica, “necesario” es lo mínimo imprescindible para:

  • prestar una funcionalidad que el usuario ha pedido de forma clara (ej.: mantener sesión tras login, carrito en checkout, balanceo básico), o
  • garantizar seguridad/estabilidad que sin ella el servicio no funciona razonablemente.

Lo que no es “necesario” (aunque sea útil para negocio):

  • medición de audiencia “por comodidad”,
  • personalización y marketing,
  • replay/heatmaps,
  • A/B testing,
  • fuentes externas “porque quedan mejor”.

Lección 1: “necesario” no es “me viene bien”. Es “sin esto, el servicio que el usuario pidió no se presta”.

 

3) Tres “familias” que confunden mucho y cómo tratarlas

A) CDN/WAF: lo técnico también se documenta

Un CDN/WAF puede tratar IPs, cabeceras, tokens de sesión, y logs. Puede ser crítico por seguridad, pero eso no significa que se ignore.

Qué preguntas debes poder responder:

  1. ¿Qué proveedor es y qué producto exacto?
  2. ¿Qué datos pasan (IPs, cabeceras, cookies, logs)?
  3. ¿Dónde opera y dónde hay soporte/acceso?
  4. ¿Qué retención aplica?
  5. ¿Qué evidencias tengo de que está justificado como “necesario”?

Evidencia mínima recomendada:

  • ficha del proveedor (producto/función, finalidad, datos)
  • registro de retención/logs (si aplica)
  • trazas Pre/Reject que muestren que no “engancha” trackers opcionales

Lección 2: incluso lo “infra” se gobierna. Si no, se convierte en “tercero silencioso”.

B) Fuentes externas: el caso típico que la gente subestima

Cargar fuentes externas (p. ej., desde un proveedor) genera una llamada a un tercero cada vez que alguien abre una página (salvo caché). Eso implica al menos IP y cabeceras. En Alemania se litigó el caso de Google Fonts por transferencia de la IP al cargar fuentes dinámicamente, con decisión del tribunal regional de Múnich (LG München I, 3 O 17493/20) y debate ampliamente documentado por firmas y análisis legales. (activeMind.legal)

Qué hacer en la práctica (orden de preferencia):

  1. Self-host (alojar localmente fuentes/recursos)
  2. Si no se puede: proxy/minimización y documentación
  3. Evitar dependencias de terceros “solo estética” en páginas críticas

Evidencia mínima:

  • prueba en Network mostrando que las fuentes no se descargan desde un tercero (o, si lo hacen, justificación y medidas)

Lección 3: “solo es una fuente” es el tipo de frase que se cae sola cuando miras Network.

C) Embeds (vídeo, mapas, widgets): el riesgo está en “cargar por defecto”

Un embed suele traer scripts de terceros que pueden:

  • cargar cookies,
  • ejecutar tracking,
  • comunicar datos al proveedor,
  • activar servicios asociados (ads, medición, recomendaciones).

Patrón de riesgo: el embed se carga automáticamente en la página, incluso antes de elegir en el banner.

Alternativas prácticas (muy defendibles):

  • Click-to-load: el vídeo/mapa no carga hasta que el usuario hace clic.
  • Placeholder con explicación (y botón “cargar contenido de terceros”).
  • Versión sin cookies cuando exista (p. ej., “modo privacidad” en algunos servicios).

Evidencia mínima:

  • HAR Pre mostrando que no se llama al tercero hasta que el usuario interactúa (o consiente, según tu diseño).

Lección 4: el embed “bonito” puede ser el primer tercero que rompe el Pre.

Gráfico 2 — Mapa de “terceros silenciosos” que se cuelan sin que nadie los liste

Mapa (PNG):

4) Método operativo: “clasificar → decidir → probar → documentar”

Este es el método que recomiendo como rutina trimestral o por release:

Paso 1 — Clasifica cada elemento externo (en 1 tabla)

ElementoTipo¿Necesario?¿Activa antes de elegir?¿Identificadores/cookies?¿Fuera del EEE?Decisión
CDN/WAFInfraNo/dependeDependeDocumentar + TPRM
Fuentes externasEstéticaNoNo (pero IP)PosibleSelf-host
Mapa embebidoContenidoNoSí/dependePosibleClick-to-load
Vídeo embebidoContenidoNoSí/dependePosiblePlaceholder + click

Paso 2 — Define la decisión

Para cada elemento, solo hay cuatro decisiones útiles:

  1. Mantener como necesario (con justificación)
  2. Condicionar por consentimiento (CMP + Tag Manager)
  3. Click-to-load / activación por acción
  4. Eliminar / sustituir / self-host

Paso 3 — Prueba Pre / Accept / Reject

Este post se apoya en el protocolo ya fijado en la serie:

  • Pre (sin tocar banner)
  • Accept
  • Reject

Evidencia mínima: HAR o lista de dominios por escenario.

Paso 4 — Documenta en un mini expediente

  • tabla de clasificación
  • decisión adoptada y responsable
  • evidencia Pre/Accept/Reject
  • control de cambios (qué se modificó)

5) Ejemplos prácticos

Ejemplo 1 — Google Fonts cargando desde tercero

Situación: en Network aparece una llamada a dominios de fuentes cada vez que abres la home.
Riesgo: contacto con tercero “por defecto” sin necesidad funcional.
Solución recomendada: self-host.
Evidencia: captura Network antes/después (y el HAR Pre ya no muestra ese dominio).

Ejemplo 2 — Mapa embebido en página de contacto

Situación: el mapa carga en Pre y dispara múltiples scripts de terceros.
Solución: placeholder con botón “cargar mapa” (click-to-load).
Evidencia: HAR Pre sin llamadas al proveedor del mapa; HAR tras clic sí las muestra.

Ejemplo 3 — CDN/WAF con soporte global

Situación: imprescindible para seguridad y disponibilidad.
Decisión: “necesario”, pero con expediente: proveedor, producto, retención, ubicaciones, cadena, medidas.
Evidencia: ficha + contrato + configuración + revisión trimestral.

6) Lecciones

  1. Si algo se carga antes de elegir, lo vas a tener que explicar.
  2. “Necesario” requiere justificación, no intuición.
  3. Fuentes y embeds son el sitio donde más se cuelan terceros “sin intención”.
  4. Click-to-load es tu aliado: reduce fricción legal y técnica sin matar UX.
  5. La tabla “clasificar → decidir → probar” vale más que 10 páginas de política.
  6. Lo que te salva en inspección es evidencia repetible, no promesas.

7) Cierre

CDN, fuentes y embeds no son el enemigo. El enemigo es que existan como “zona gris”.

Si los conviertes en: inventario + decisión + prueba + evidencia, dejan de ser un susto y pasan a ser control.

Siguiente post (Post 5)

El “modo rechazo” de verdad

Cómo probar que al rechazar desaparecen terceros, cómo evitar “carga diferida” tramposa y qué evidencia guardar (sin convertirte en técnico)

Bibliografía y recursos (selección)

  • CNIL — acciones contra banners con patrones oscuros y recordatorio de equivalencia (cnil.fr)
  • AEPD — Guía sobre el uso de las cookies (marco general, LSSI art. 22) (AEPD)
  • AEPD — Guía de cookies analíticas externas (evidencias y configuración real) (AEPD)
  • EDPB — Website Auditing Tool (auditoría y evidencia repetible) (edpb.europa.eu)
  • Caso Google Fonts (análisis y referencia del fallo LG München I, 3 O 17493/20) (activeMind.legal)