El problema de entrega de anuncios que The Trade Desk comunicó en Safari 27 ha entrado en una nueva fase de pruebas. En la incidencia pública de WebKit, John Wilander pidió al informante el 5 de octubre de 2026 que probara la nueva beta de iOS 27.2. Ian Meyers respondió que veía cambios en la compilación 24B5099f y que realizarían pruebas. El hilo consultado para este artículo sigue marcando la incidencia como NEW; no contiene un informe de pruebas terminado que confirme el funcionamiento de todos los flujos afectados.
La cobertura de Business Insider está fechada el 7 de octubre. Tanto la incidencia como la respuesta sobre la beta son anteriores. Para los editores que investigan la ausencia de anuncios, la novedad útil es disponer de una compilación identificada con la que comparar el comportamiento comunicado.
La queja afecta a una vía de entrega publicitaria
Meyers abrió la incidencia el 21 de septiembre y describió solicitudes bloqueadas durante navegación normal, no privada, en un iPhone o iPad con iOS 27. Identificó adsrvr.org como el dominio principal de The Trade Desk para solicitar y entregar anuncios, mientras que vinculó el subdominio match con las cookies tradicionales de terceros.
La distinción importa al investigar un anuncio que no aparece. Perder el identificador utilizado para reconocer una audiencia y perder la solicitud que entrega el anuncio son fallos distintos. Un cambio en la medición de audiencias no determina, por sí solo, si se cargó la creatividad. El informe es la descripción de un proveedor sobre un dominio y un entorno concretos, no una demostración de que Safari bloquea toda la publicidad.
Otro cambio de WebKit permite actualizar la lista de reglas
WebKit integró el pull request 74381 el 25 de septiembre. Su descripción indica que una lista de reglas de contenido suministrada por WebPrivacy sustituye a la lista estática de dominios del proceso de red. El navegador guarda la lista en caché y vuelve a cargarla cuando WebPrivacy comunica una actualización.
El cambio describe comprobaciones sobre solicitudes entre sitios distintas de la navegación del marco principal, cuando el ajuste correspondiente está activado. Ofrece un mecanismo concreto para estudiar, pero integrarlo en la rama principal de WebKit no acredita el comportamiento de todas las versiones de Safari distribuidas ni revela la lista activa completa.
La política de prevención del seguimiento de WebKit expone su objetivo de evitar el seguimiento encubierto y entre sitios. Esa política explica la finalidad de privacidad; el hilo de la incidencia aporta las pruebas sobre la queja concreta de entrega.
Comparar la solicitud antes de juzgar el resultado
Nuestra lectura práctica es reproducir la página afectada en la versión estable y en la beta identificada, registrando la compilación del sistema, el modo de navegación y la solicitud fallida. Después conviene comprobar si el anuncio se representa realmente, por separado de cualquier resultado de identificación o atribución.
Una prueba satisfactoria en una página acotaría esa incidencia; no resolvería todas las integraciones ni demostraría una retirada general de las protecciones de seguimiento. Los editores con un fallo reproducible pueden aportar los detalles de las solicitudes en la incidencia existente de WebKit. La siguiente prueba relevante será un resultado de ensayo documentado o unas notas de versión vinculadas a la compilación afectada.