Informe de comentarios - 2ᵉʳ trimestre de 2025

Informe trimestral del segundo trimestre de 2025 en el que se resume los comentarios del ecosistema recibidos sobre las propuestas de Privacy Sandbox y la respuesta de Chrome.

Google preparó este informe trimestral como parte de sus Compromisos con la Autoridad de Competencia y Mercados ('CMA') en virtud de los párrafos 12, 17(c)(ii) y 32(a). En este informe, se abarca el progreso de Google en las propuestas de Privacy Sandbox, las expectativas de tiempos actualizadas, las explicaciones sustantivas de cómo Google tuvo en cuenta las observaciones de terceros y un resumen de las interacciones entre Google y la CMA, incluidos los comentarios de la CMA y el enfoque de Google para abordar esos comentarios.

Google ha mantenido a la CMA al tanto del progreso de las propuestas de Privacy Sandbox en sus reuniones de estado periódicas programadas de conformidad con el párrafo 17(b) de los Compromisos. Además, el equipo mantiene la documentación para desarrolladores, que proporciona resúmenes de las funciones principales de la publicidad privada y los cambios en las cookies, junto con la implementación de la API y la información de estado. Las actualizaciones clave se comparten en el blog para desarrolladores, junto con las actualizaciones segmentadas que se envían a las listas de distribución de los desarrolladores individuales.

Tener en cuenta las observaciones realizadas por terceros

Glosario de acrónimos

ARA
API de Attribution Reporting
CHIPS
Cookies con estado particionado independiente
DSP
Plataforma orientada a la demanda
FedCM
Federated Credential Management
IAB
Interactive Advertising Bureau
IDP
Proveedor de identidad
IETF
Internet Engineering Task Force
IP
Dirección de Protocolo de Internet
openRTB
Licitaciones en tiempo real
TS
Prueba de origen
API de PA
API de Protected Audience (antes FLEDGE)
PatCG
Grupo privado de la comunidad de tecnología publicitaria
Acceso al
Usuario de confianza
RWS
Conjuntos de sitios web relacionados (anteriormente, conjuntos propios)
SSP
Plataforma de proveedores
UA
Cadena de usuario-agente
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
Ceguera intencional ante la IP

Comentarios generales, sin API o tecnología específica

Tema de los comentarios Resumen Chrome Response
El futuro de Privacy Sandbox En vista del anuncio de no proceder con la introducción de un mecanismo de elección del usuario para los 3PC, algunas APIs son más útiles que otras cuando hay 3PC presentes, y otras deberían evolucionar para ser útiles. Existen otras áreas potenciales de inversión para Chrome más allá de las APIs de Privacy Sandbox. Agradecemos los comentarios y seguimos interactuando con las partes interesadas para evaluar el papel que pueden desempeñar las APIs de Privacy Sandbox en el futuro, así como para explorar nuevas áreas de inversión futura, a la luz del anuncio de Google de abril de 2025 de que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Privacy Sandbox Algunos participantes del ecosistema se mostraron decepcionados por el anuncio de no continuar con la introducción de un mecanismo de elección del usuario para las 3PC, pero se enorgullecen del trabajo realizado, aprecian los desafíos técnicos dentro de Privacy Sandbox y enfatizaron el valor de su relación de trabajo colaborativa con Chrome y la utilidad del subsidio de pruebas de mercado. Agradecemos los comentarios y coincidimos en que Chrome puede y debe colaborar con los desarrolladores para crear tecnologías que mejoren la privacidad en línea y, al mismo tiempo, preserven una Internet con publicidad.
Uso compartido de datos del navegador El uso compartido de datos a través del navegador es una tecnología atractiva con el potencial de abordar las ineficiencias del mercado y los problemas de confianza. El navegador tiene valor como contexto de ejecución de terceros para la colaboración. Agradecemos los comentarios y coincidimos en que Chrome puede y debe desempeñar un papel para ayudar a los desarrolladores a crear tecnologías que mejoren la confianza entre los desarrolladores y los usuarios que colaboran.
Tráfico de Chrome ¿Cuál es el porcentaje de tráfico sin cookies en Chrome y el porcentaje de tráfico para el modo Incógnito? Como señaló la CMA en su "Aviso de intención de publicar compromisos", el modo Incógnito solo afecta a una fracción muy pequeña de la actividad de navegación. En el Reino Unido y el EEE, el modo Incógnito de Chrome representa menos del 10% de las navegaciones en dispositivos que ejecutan el sistema operativo Android y menos del 10% de las navegaciones en dispositivos que ejecutan el sistema operativo Windows. Estas métricas solo se refieren a la navegación en Chrome basado en Chromium en el Reino Unido y el EEE.
No compartimos datos sobre los navegadores que bloquean a terceros.
Los desarrolladores pueden determinar cuándo se particionan las cookies con los encabezados de acceso al almacenamiento y usar las mitigaciones disponibles según corresponda.
Etiquetas de Chrome Testing ¿Cuál es el plan de Chrome para el 1% del tráfico sin cookies que se habilitó para las pruebas en 2024? Por el momento, no tenemos planes para compartir, pero lo haremos públicamente en cuanto estén disponibles.
Chrome Testing ¿La configuración actual de etiquetas de prueba incluye un tratamiento para situaciones en las que ambos 3PCs están disponibles y las APIs de Privacy Sandbox están habilitadas? La configuración actual de etiquetas de prueba incluye el tratamiento para las APIs de 3PCs y de Privacy Sandbox en forma del modo A.
Privacy Sandbox Algunos anunciantes consideran que las APIs de Privacy Sandbox son complejas y sienten apatía debido a los ejercicios de preparación anteriores. Además, se preguntan cómo cuantificar la ventaja para los primeros usuarios y buscan información sobre los efectos de la segmentación, la captación de clientes potenciales y la medición. Agradecemos los comentarios y comprendemos las opiniones sobre la complejidad tecnológica y los ejercicios de preparación.
En cuanto a la comprensión del rendimiento de las tecnologías actuales de Privacy Sandbox, los resultados de nuestras pruebas indicaron que la participación del ecosistema es un factor fundamental para comprender el rendimiento de las soluciones de Privacy Sandbox. Las pruebas con volúmenes bajos no pudieron reproducir la dinámica del mercado ni los incentivos para usar las tecnologías a gran escala.

Inscripción y certificación

No se recibieron comentarios este trimestre.

Mostrar anuncios y contenido pertinentes

Temas

Tema de los comentarios Resumen Chrome Response
Rendimiento y utilidad de la API de Topics con mejoras Los comentarios de las partes interesadas del lado de la compra indican que la API de Topics es un indicador valioso y genera datos de costo por impresión (CPM) que son competitivos con los de los públicos de 3PC para las campañas de los anunciantes. Algunos publicadores consideran que el indicador de la API de Topics es de mayor calidad que los indicadores estándar de la Web abierta. Teniendo en cuenta estos comentarios sobre la utilidad de la API de Topics, las partes interesadas solicitan mejoras, como aumentar la fidelidad y la coherencia de la taxonomía, y expandir los controles de los publicadores para impulsar una adopción más amplia. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Utilidad para diferentes tipos de partes interesadas

 Dado que, actualmente, el clasificador de temas solo utiliza el nombre de host de la página para definir los temas correspondientes, los sitios grandes con contenido diverso aportan temas genéricos, mientras que los sitios pequeños aportan temas de nicho con más valor publicitario. Nuestra respuesta es similar a la de los trimestres anteriores:
Al igual que con las 3PC, existe una diferencia en el valor de la información que aportan los diferentes sitios. Los sitios de interés de nicho son incoherentes en su contribución de valor: no todos los sitios de interés de nicho tienen contenido valioso desde el punto de vista comercial y, por lo tanto, contribuyen menos valor. Estos son los sitios que se beneficiarán con la API de Topics. Consideramos la posibilidad de realizar clasificaciones a nivel de la página en lugar de a nivel del sitio, pero existen varios problemas importantes de privacidad y seguridad con este tipo de clasificación.
La taxonomía de Topics no es lo suficientemente detallada La API de Topics no proporciona la suficiente granularidad para los publicadores de noticias con diversas secciones de contenido dentro de un solo dominio, lo que podría limitar la utilidad de la API para la segmentación de anuncios. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Mejora del clasificador Permitir que los publicadores otorguen permisos a Chrome para clasificar temas según el contenido de la página (p. ej., encabezado, cuerpo) Estamos considerando esta solicitud y agradecemos los comentarios adicionales aquí.
Política Solicitud de aclaración sobre los lineamientos relacionados con el uso de la API de Topics junto con la información de terceros. No hay dificultades para usar la API de Topics y las 3PC, ya que la API de Topics proporciona un subconjunto de las funcionalidades de las 3PC.
Encabezado Observe-Browse-Topics Solicitud de aclaración sobre la implementación del encabezado Observe-Browse-Topics, específicamente si devolver el encabezado de forma continua causaría problemas. Devolver continuamente el encabezado Observe-Browse-Topics: ?1 no causará ningún problema técnico.
El navegador controla este indicador de manera eficiente, ya que solo registra que la visita a la página es apta para el cálculo de temas sin causar duplicación ni errores. Si bien no es obligatorio en todas las páginas, enviarlo como un encabezado estándar en todos los documentos de nivel superior es una estrategia válida y simple.
Categorías de taxonomía Solicitud para actualizar la taxonomía de Topics más reciente con temas nuevos. Estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema aquí.
Valores nulos Solicita orientación para mejorar el rendimiento de la API de Topics y comprender los motivos de las respuestas nulas, como el filtrado o la sensibilidad. Para mayor claridad, las respuestas null o vacías de la API de Topics son una función de privacidad esperada, no un error.
Una respuesta null puede deberse a lo siguiente:
• Reglas de privacidad: Hay un 5% de probabilidades aleatorias de obtener una respuesta null, o bien tu secuencia de comandos no "observó" al usuario en sitios relacionados con ese tema.
• Estado del usuario: Historial de navegación insuficiente, uso del modo Incógnito o el usuario inhabilitó la opción en la configuración de privacidad de anuncios de Chrome.
• Errores técnicos: Los sitios de publicadores deben enviar el encabezado Observe-Browse-Topics: ?1, y todos los iframes de llamada requieren el permiso allow="Browse-topics".
Para investigar, usa la página de depuración chrome://topics-internals para ver qué temas calculó tu navegador y por qué.
Si bien las funciones de privacidad impiden una tasa de relleno del 100%, puedes mejorar el rendimiento de las siguientes maneras:
• Trabaja con los publicadores: Asegúrate de que tus socios envíen correctamente el encabezado Observe-Browse-Topics: ?1 en sus sitios.
• Verifica tu código: Si usas iframes, confirma que la política allow="Browse-topics" esté vigente.

API de Protected Audience

Tema de los comentarios Resumen Chrome Response
La adopción de la API de PA se ve obstaculizada por el costo y la complejidad Los adoptantes están reduciendo la prioridad de las integraciones de la API de Protected Audience (API de PA) o revirtiéndolas, y citan los costos operativos, la falta de demanda de los anunciantes y el bajo volumen de inventario de los intercambios.
Algunos comentarios incluyeron los beneficios del potencial de la API de PA, como su capacidad de ofrecer públicos duraderos y un alcance superior debido a un alto porcentaje de coincidencias.		 Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Funcionalidad multiplataforma La funcionalidad multiplataforma debe ser compatible con la API de PA en todas las plataformas para desbloquear mayores capacidades de redireccionamiento y segmentación por público. Google debe habilitar los grupos de interés (IG) registrados en Chrome para que sean accesibles cuando se publican anuncios en entornos nativos o dentro de WebView, y los grupos de interés registrados en Android deben estar disponibles en las subastas de Chrome. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
directFromSellerSignals Al limitar la cantidad de información disponible en la subasta contextual, los participantes de la subasta siempre se dirigen a través del servidor de anuncios de Google. Un publicador primero debe llamar a todos sus socios de intercambio, luego a Google Ad Manager (GAM) para ejecutar la subasta contextual y, por último, permitir que GAM invoque las subastas de IG. Sin conocer el resultado de la subasta contextual en tiempo real, ningún competidor puede coordinar de manera justa una decisión de nivel superior.

Es posible que la función directFromSellerSignals de la API de PA no sea transparente en cuanto a la información de la subasta, lo que podría dificultar el acceso a los datos necesarios. Google debe quitar directFromSellerSignals o actualizarlo para que no se pueda usar para ocultar el precio de liquidación de la subasta del servidor de anuncios. Por ejemplo, el precio contextual se podría pasar a través de Chrome con un campo firmado, transparente e inmutable al que todos los participantes de la subasta (y el publicador) puedan acceder y verificar.		 Nuestra respuesta no cambió con respecto a los trimestres anteriores:
Respuesta de Chrome:
No se sabe si la información que se pasa a runAdAuction() proviene del vendedor, a menos que el vendedor llame a runAdAuction() desde su propio iframe. En una subasta de varios vendedores, es imposible que todos los vendedores creen el marco que llama a runAdAuction(). directFromSellerSignals abordó este problema cargando contenido desde un paquete de recursos secundarios cargado desde el origen de un vendedor. Esto garantiza que no se pueda manipular la autenticidad ni la integridad de la información que se pasa a una subasta desde las configuraciones de subastas del vendedor. Si los publicadores desean usar la API de PA para comprender la información que sus proveedores de tecnología pasan a las subastas de PA, pueden solicitarles a esos proveedores de tecnología que les proporcionen esta funcionalidad.
Respuesta de Google Ad Manager:
Durante años, nos hemos enfocado en la equidad de las subastas, lo que incluye nuestra promesa de que no se compartirá ningún precio de las fuentes publicitarias no garantizadas de un publicador, incluidos los precios de las líneas de pedido no garantizadas, con otro comprador antes de que realice una oferta en la subasta, lo que luego reafirmamos en nuestros compromisos con la Autoridad de Competencia de Francia.
En el caso de las subastas de Protected Audience, tenemos la intención de cumplir nuestra promesa aprovechando directFromSellerSignals y no compartir la oferta de ningún participante de la subasta con ningún otro participante antes de que se complete la subasta en las subastas de varios vendedores. Para ser claros, tampoco compartiremos el precio de la subasta contextual con nuestra propia subasta de componentes, como se explica en esta actualización.
Informes Solicitud para agregar una entidad de informes o análisis para habilitar los informes centralizados. Estamos analizando esta solicitud aquí y agradecemos cualquier comentario adicional.
K-anonimato en buyerReportingId Capacidad de descartar ofertas según la k-anonimización del "buyerReportingId" para facilitar la selección del público y las obligaciones de informes con proveedores de datos externos Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Se mejoró la depuración en la secuencia de comandos generateBid Solicitar un mecanismo para identificar rápidamente la etapa o el "punto de interrupción" específicos dentro de la secuencia de comandos generateBid en los que falla el proceso Sabemos que se desea usar las mediciones en tiempo real como un mecanismo de configuración de puntos de interrupción para las subastas en el dispositivo. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025 de que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Objetos de escucha de eventos para supervisar el estado de runAdAuction Propuesta para agregar compatibilidad con objetos de escucha de eventos a la función navigator.runAdAuction de la API de PA para mejorar la supervisión del ciclo de vida de la subasta de anuncios. Estamos evaluando esta solicitud y agradecemos los comentarios adicionales del ecosistema aquí.
Uso de API Solicitud para aclarar cómo la API de PA y la API de Attribution Reporting (ARA) pueden admitir casos de uso de publicidad web en ausencia de cookies de terceros, en particular para los usuarios que inhabilitaron las cookies de terceros, pero no las APIs de Privacy Sandbox, y en situaciones que involucran sincronizaciones de cookies fallidas y WebView Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Latencia La latencia asociada a la API de PA podría dificultar la adopción, ya que los publicadores podrían optar por inhabilitar la API de PA si la latencia es demasiado alta. En los últimos trimestres, se realizaron varias mejoras en la latencia del dispositivo. Se sigue creando y ampliando los servicios de ofertas y subastas (B&A) según sea necesario. Se actualizó nuestra guía de prácticas recomendadas sobre la latencia para incluir más información sobre cómo aprovechar estas funciones. También estamos explorando el desarrollo de nuevas mejoras en la latencia, algunas de las cuales se pueden consultar aquí.
Comportamiento del registro en B&A (prueba vs. producción) Aclaración sobre las diferencias en el comportamiento de registro entre los modos de prueba y producción para los servicios de B&A Específicamente, la disponibilidad de los registros de Cloud y el impacto del modo de producción en el registro. En primer lugar, es importante distinguir entre las compilaciones de producción y las que no son de producción, y el parámetro TEST_MODE independiente, que simplemente habilita una clave de encriptación de prueba codificada. La siguiente explicación se centra en los tipos de compilación.
En las compilaciones que no son de producción, los servidores de B&A incluyen un nivel de detalle configurable para el registro. Estos registros detallados se escriben en los flujos stdout/stderr estándares. En Google Cloud, se puede acceder a ellos a través de la interfaz de registro nativa, y en Amazon Web Services, se pueden encontrar en los registros de la consola adjunta.
En el caso de las compilaciones de producción, el comportamiento de registro es más restringido. El nivel de detalle es fijo y no se puede cambiar. Si bien algunos registros que no son relevantes para la privacidad, como los mensajes de inicio del servidor y la mayoría de los errores de bloqueo, aún se imprimen en stdout/stderr, no hay registros específicos de la solicitud disponibles a través de este canal. Los únicos registros por solicitud de una compilación de producción son para las solicitudes que contienen un token de depuración con consentimiento, y estos se exportan exclusivamente a través de OpenTelemetry. Es importante usar la depuración con consentimiento de forma moderada, ya que el tráfico intenso puede degradar el rendimiento del servidor y provocar fallas en las verificaciones de estado.
En cuanto a las métricas, todas se exportan a través de OpenTelemetry. Las métricas que no son sensibles a la privacidad siempre se exportan tal como están, sin ningún tipo de "ruido". Por el contrario, las métricas sensibles a la privacidad siempre se "distorsionan" cuando se exportan desde un servidor que se ejecuta en modo de producción. La configuración de telemetría específica determina si estas métricas sensibles a la privacidad se exportan con ruido, sin ruido o ambas.
Incluye la ruta de acceso a la página completa en los indicadores de ofertas de confianza para la seguridad de la marca Solicita una actualización de la API de PA para incluir la ruta de acceso de URL completa de la página de nivel superior, además del nombre de host, en la solicitud de recuperación de trustedBiddingSignals.
El caso de uso principal es habilitar controles de seguridad de la marca más detallados. A menudo, los anunciantes necesitan bloquear la aparición de anuncios en secciones específicas de un dominio (p.ej., sitio-de-noticias.com/política) y, al mismo tiempo, sentirse cómodos con el dominio en general. Como estas listas de bloqueo pueden tener millones de entradas, deben evaluarse en el servidor. La especificación actual, que solo envía el nombre de host, imposibilita que el servidor de trustedBiddingSignals realice esta evaluación necesaria a nivel de la ruta, lo que limita las capacidades de seguridad de la marca.		 Actualmente, estamos analizando este problema aquí, después de extensos debates anteriores que se pueden consultar aquí, y agradecemos los comentarios adicionales.
Sin embargo, queremos aclarar que solo consideramos agregar esta información cuando la recuperación de trustedBiddingSignals se dirige a un servidor que se ejecuta dentro de un entorno de ejecución confiable (TEE).

Subasta protegida (servicios de ofertas y subastas)

Tema de los comentarios Resumen Chrome Response
Cómo comprobar la disponibilidad Información sobre la disponibilidad de la versión 2 de Key/Value (KV) para pruebas en entornos de Chrome y de B&A. La versión 2 de KV está disponible en B&A y Chrome. Aquí encontrarás orientación adicional.
Implementación del servidor KV Solicitud de aclaración sobre el uso del servidor de KV, específicamente en relación con la asignación de URLs de renderización de creatividades a datos de solicitudes, la necesidad de coordinación entre las SSP y los DSP para definir parámetros en la URL de renderización, y la disponibilidad de documentación que describa la coordinación y el almacenamiento de datos necesarios en el modo KV. El servicio de KV usa renderURL como clave. Si la URL es nueva, se almacena. Si existe, se devuelve su valor para usarlo en scoreAd. El formato de devolución depende de la configuración: "Bring Your Own Server" (BYOS) permite cualquier valor, mientras que el servicio de KV de confianza requiere una función definida por el usuario.
Si bien no siempre es necesaria, la coordinación con las DSP es fundamental para funciones como el reemplazo de macros (p.ej., ${AD_WIDTH}) en el renderURL, lo que permite la personalización y verificación dinámicas de los anuncios.
Te recomendamos que comiences con una prueba simple con una DSP para determinar el nivel de coordinación necesario. También estamos en proceso de actualizar nuestra documentación de KV y la compartiremos públicamente cuando esté disponible.
BYOS para B&A ¿Por qué B&A no ofrece el modo BYOS similar al de KV? B&A requiere un TEE, lo que impide un modelo BYOS, porque maneja combinaciones de datos altamente sensibles que requieren la aplicación de mecanismos de privacidad, como se explica a continuación.
Para los DSP:
Los procesos de B&A combinan el contexto del publicador (posiblemente la URL completa si el vendedor la envía de forma explícita a través de auctionSignals o perBuyerSignals) con datos detallados de IG del usuario. El TEE es esencial para procesar de forma segura esta combinación y evitar la posible reidentificación del usuario. En KV BYOS, no se puede enviar la URL completa.
Para las SSP:
Conocer la combinación de IG participantes (y sus propietarios de DSP) en una subasta puede generar una firma de identificación. Aquí es donde entra en juego la solución de chaffing, que requiere el uso de un TEE.
Por lo tanto, el procesamiento seguro de estos indicadores sensibles combinados y la aplicación de mecanismos de privacidad exigen el entorno controlado y certificado de un TEE.

Medición de anuncios digitales

Attribution Reporting (y otras APIs)

Tema de los comentarios Resumen Chrome Response
Política de ruido La implementación del ARA ha sido valiosa para algunos participantes del mercado, y Google debería seguir manteniendo los informes a nivel del evento. Google debería considerar relajar la política de ruido en situaciones en las que estén disponibles tanto la ARA como los 3PCs. Los anunciantes de rendimiento utilizan cada vez más la implementación actual del campo "valor" del evento flexible de ARA, y una política de ruido menos restrictiva ayudaría a reducir los retrasos y los informes inexactos. Este mecanismo es una parte fundamental del diseño de la ARA, que tiene como objetivo proteger la privacidad del usuario evitando el seguimiento individual. Tenemos en cuenta los comentarios sobre los desafíos de informes que genera el ruido, a medida que seguimos evaluando el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, así como las posibles mejoras futuras, a la luz del anuncio de Google del abril de 2025 de que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Hoja de ruta y asistencia a largo plazo Solicitar una hoja de ruta del producto para la ARA, así como la confirmación de la inversión y la asistencia a largo plazo, dado el anuncio de no proceder con la introducción de un mecanismo de elección del usuario para el 3PC El equipo de Privacy Sandbox interactúa con el ecosistema para comprender el papel que desempeñarán las APIs de Privacy Sandbox en el futuro y evaluar cualquier inversión futura.
Medición multientorno (de la aplicación a la Web) Solicitud de una solución que implique el uso de ARA para facilitar la medición en diferentes entornos, lo que ofrece un flujo de datos más limpio y confiable, y mejora la capacidad de conectar las interacciones de los usuarios en diferentes plataformas. La ARA ya admite la función de App-to-Web en el mismo dispositivo. Puedes encontrar más detalles sobre la solución de medición entre apps y la Web aquí y aquí.
Atribución en múltiples navegadores Un enfoque unificado y compatible con todos los navegadores para la ARA mejoraría drásticamente la capacidad de medir el ROI en la Web abierta y proporcionaría una alternativa estable ante posibles cambios regulatorios. Chrome debería colaborar con el equipo de Safari en una solución como esta. Ya estamos explorando una API interoperable con otros proveedores de navegadores en los grupos PATCG y PATWG del W3C. Dado que este trabajo es preliminar, los interesados pueden consultar nuestro progreso aquí.
Medición multidispositivo y sin conexión La imposibilidad de admitir la medición de conversiones en dispositivos múltiples dentro de ARA es una limitación importante. Medir las conversiones en línea y fuera de línea también es muy importante, y el navegador podría desempeñar un papel en la colaboración con los proveedores de medición. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Atribución de múltiples puntos de contacto Solicitud para permitir que los anunciantes usen los datos de Privacy Sandbox como una "verdad fundamental" imparcial para validar y calibrar sus modelos de atribución existentes. Esto se puede lograr usando los datos proporcionados por el navegador de ARA como un indicador de calibración confiable, lo que crea un valor de referencia de verdad. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Medición del tráfico sin consentimiento o con exclusión Una solución que preserva la privacidad, como la atribución privada interoperable, permitiría la medición del tráfico sin consentimiento. Esto permitiría comprender mejor el rendimiento de las campañas, ya que se incluirían los datos de los usuarios que inhabilitaron el seguimiento, lo que abordaría una brecha importante en la medición creada por los requisitos de consentimiento. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Atribución de servidor a servidor Solicitud para permitir que las tecnologías publicitarias con infraestructura sofisticada del servidor se integren con la ARA de una manera más flexible, lo que permite abordar casos de uso que son difíciles de administrar solo del lado del cliente, sin dejar de mantener la privacidad del usuario. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Inscripción en varios dominios Se busca aclarar las limitaciones y advertencias al inscribir varios dominios en la ARA, en particular en lo que respecta al servicio de agregación y la atribución de origen cruzado. A continuación, se indican las limitaciones clave cuando se usa ARA con varios dominios:
• La atribución se limita a un solo origen. No puedes asociar un clic de uno de tus dominios a una conversión en otro. La atribución se ejecuta en un espacio aislado en el mismo origen para la fuente y el activador.
• El Servicio de agregación no admite el procesamiento por lotes de varios orígenes. Los informes de diferentes orígenes se deben procesar y agrupar por lotes de forma independiente. Estamos explorando formas de admitir esta función en el futuro.
En resumen, si bien se pueden inscribir varios dominios en una sola entidad, todas las funciones de la ARA, como la atribución y la agregación, actualmente se deben controlar por origen.

Servicio de agregación

No se recibieron comentarios este trimestre.

API de Private Aggregation

Tema de los comentarios Resumen Chrome Response
Límites y niveles de ruido Inquietudes sobre las limitaciones en los tamaños de las claves de agregación y los valores de agregación dentro de la API de Private Aggregation Los tamaños de la clave y el valor de agregación se eligieron para tener una alta granularidad y, al mismo tiempo, limitar los costos de red y almacenamiento. También recomendamos usar el hashing cuando asignes claves para maximizar la flexibilidad.
Si bien existen otros factores que protegen los datos del usuario, agregar ruido es un componente importante de las protecciones de privacidad de la API de Private Aggregation.
Tenemos en cuenta los comentarios y seguiremos evaluando las opciones de parámetros adecuadas, además de considerar el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025 sobre el mantenimiento del enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.
Privacidad vs. utilidad El enfoque de Privacy Sandbox puede priorizar la privacidad por sobre la utilidad, lo que podría dificultar su adopción. Sugerencia para permitir un uso compartido de datos más detallado con el consentimiento del usuario para mejorar la medición y la personalización de anuncios. Los tamaños de la clave y el valor de agregación se eligieron para tener una alta granularidad y, al mismo tiempo, limitar los costos de red y almacenamiento. También recomendamos usar el hashing cuando asignes claves para maximizar la flexibilidad.
Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025 de que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.

Limitar el seguimiento encubierto

Reducción de la cadena de usuario-agente o User-Agent Client Hints

Tema de los comentarios Resumen Chrome Response
Detección de spam Si la primera solicitud de un sitio web que usa un sistema de detección de spam se basa en sugerencias del cliente, es posible que el sistema de seguimiento o detección no pueda identificar o categorizar correctamente la solicitud. Los casos de uso que dependen del acceso a las Client Hints de usuario-agente (UA-CH) en la primera solicitud deben usar las Client Hints críticas.
Comentarios sobre la API Considera la posibilidad de desaprobar Sec-CH-USA-Wow64, ya que ya no es relevante para la Web moderna. Estamos considerando esta solicitud y agradecemos los comentarios adicionales aquí. También recibimos comentarios que indican que sería útil extender wow64 más allá de Windows.

Protección de IP (antes Gnatcatcher)

Tema de los comentarios Resumen Chrome Response
Controles Solicitud para activar o desactivar la Protección de IP para que los sitios la usen de forma selectiva fuera del modo Incógnito. Agradecemos tus comentarios y aceptamos cualquier opinión adicional sobre este problema aquí.
Conducta inapropiada ¿Los tokens de revelación probabilística (PRT) que dan como resultado un valor NULL impiden la identificación del infractor cuando la policía solicita la divulgación de la dirección IP por mala conducta en la plataforma? Si un dominio se usa exclusivamente para la detección de fraudes y abusos, es probable que no se incluya en la Lista de dominios enmascarados (MDL) y, por lo tanto, no se vea afectado por la Protección de IP. Por lo tanto, no se necesitarían PRT para esos dominios.
Si se incluye un dominio en la MDL, actualmente los PRT son la única forma de conocer la dirección IP original de una solicitud proxy. Como los PRT están diseñados específicamente para admitir el análisis agregado, no la identificación individual, es cierto que, en la mayoría de los casos, no contendrán una dirección IP. Sin embargo, esperamos que esto tenga un impacto limitado en la situación descrita, ya que la Protección de IP solo se aplica en el contexto de terceros, lo que significa que los publicadores seguirán recibiendo direcciones IP sin proxy para las interacciones propias, como los usuarios que visitan el sitio de una plataforma en línea.
Antifraude ¿Cuáles son los detalles de las medidas antifraude de Google para la Protección de IP, incluidos los detalles sobre el acceso con límite de velocidad a los proxies y la emisión de tokens de autenticación? ¿Cuáles son los casos de uso específicos de los PRT? Confirmamos que los tokens de autenticación y los límites de frecuencia de la Protección de IP están diseñados para evitar que los bots cometan fraude publicitario a través del acceso excesivo a proxies, como se detalla en la estrategia contra el fraude y el spam. En la documentación explicativa de los PRT, aquí, se describen otros casos de uso de los PRT.
Modo Incógnito ¿Se sigue planeando lanzar la IP Protection en el modo Incógnito en el tercer trimestre? Actualmente, no hay cambios en el cronograma del tercer trimestre para el lanzamiento de la Protección de la IP en el modo Incógnito.

Mitigaciones del seguimiento por rebote

Tema de los comentarios Resumen Chrome Response
Comentarios sobre la API Chrome debería bloquear el acceso a las cookies o al almacenamiento en lugar de particionarlos cuando se aplican las mitigaciones del seguimiento de rebote (BTM), ya que se cita un comportamiento no deseado y confusión por el método de "particionamiento" de Safari. Agradecemos esta sugerencia. Actualmente, BTM no implica la partición de cookies o almacenamiento, sino que los borra después de un período de gracia. Si hay diseños posteriores para BTM que impliquen acciones inmediatas en relación con las cookies, preferiremos bloquearlas en lugar de particionarlas.

Fortalecimiento de los límites de la privacidad entre sitios

No se recibieron comentarios este trimestre.

API de Fenced Frames

No se recibieron comentarios este trimestre.

API de Shared Storage

Tema de los comentarios Resumen Chrome Response
Solicitud de función de la API Solicita agregar reproducciones de anuncios y clics en el almacenamiento compartido. Tenemos en cuenta estos comentarios mientras evaluamos el papel que desempeñarán las APIs de Privacy Sandbox en el futuro, a la luz del anuncio de Google de abril de 2025, en el que se indica que se mantendrá el enfoque actual para ofrecer a los usuarios la opción de elegir cookies de terceros en Chrome.

CHIPS

Tema de los comentarios Resumen Chrome Response
Pregunta sobre la API Solicitud de aclaración sobre cómo los controles de las 3PC de Chrome interactúan con CHIPS, específicamente si las cookies no particionadas se convierten en particionadas cuando se inhabilitan las 3PC y si las cookies particionadas permanecen activas. Las cookies no particionadas no se almacenarán, recuperarán ni enviarán en un contexto de terceros cuando se inhabiliten las 3PC. Sin embargo, las cookies particionadas seguirán almacenándose, recuperándose y enviándose en un contexto de terceros, ya que su funcionalidad no se ve afectada por la configuración del navegador que inhabilita las 3PCs.
Problema de privacidad Preocupación de que un tercero incorporado con un identificador persistente, como para el inicio de sesión único, aún pueda permitir que tanto los terceros incorporados como los incorporantes obtengan un identificador digital global, incluso con cookies particionadas. Si bien una entidad incorporada puede tener un identificador persistente, cuando este se almacena en una cookie particionada, solo se puede acceder a él en el sitio en el que el elemento incorporado configuró la cookie. La unión entre sitios de este identificador requeriría una acción de acceso, que ya permite el intercambio de un identificador en forma de token de autenticación, incluso sin el uso de cookies particionadas.

FedCM

Tema de los comentarios Resumen Chrome Response
Uso de API La mediación silenciosa falla para los usuarios con varias cuentas sin un error específico. El comportamiento de mediación silenciosa es una función diseñada de esta manera, ya que está pensada para un caso muy específico con solo una cuenta disponible. En su lugar, se recomienda usar la mediación "opcional", en la que FedCM recurre a presentarle al usuario un selector de cuentas si no es posible la mediación silenciosa.
Uso de API navigator.credentials.get devuelve errores genéricos, lo que impide capturar motivos de rechazo específicos, como el descarte por parte del usuario o los períodos de espera. La incapacidad de los desarrolladores para distinguir entre el rechazo del diálogo de FedCM por parte del usuario, un error de red o el hecho de que FedCM se encuentre en un "período de enfriamiento" debido a que el usuario rechazó el diálogo anteriormente también es una función diseñada para preservar la privacidad del usuario. La preocupación es que esta capacidad permitiría que los sitios web infieran el estado de acceso del usuario en diferentes proveedores de identidad (IdP).
Acceso Se observó un comportamiento incoherente en la selección de cuentas con varias cuentas conectadas. No está claro si la incapacidad intermitente para seleccionar una cuenta específica en un caso de varias cuentas conectadas es un error intermitente en FedCM o algún problema relacionado con el sistema de pruebas. Estamos trabajando con el denunciante para resolver este problema y le pedimos más detalles para comprenderlo mejor.
Uso de API Si el usuario descarta el diálogo durante la autorización con FedCM, el hecho de que se encuentre en el estado de período de espera no se informa a través de un error detectable. Sí, ese sería el caso y se produciría el código de error genérico para preservar la privacidad del usuario.
Uso de API ¿Por qué FedCM entra en un período de silencio de 10 minutos después de una "reautenticación automática" exitosa? Dado que la reautenticación automática se produce sin que el usuario inicie ninguna acción, si el usuario quisiera volver al sitio web, pero acceder con una cuenta diferente, necesitaría un período en el que FedCM no lo reautentique automáticamente. El "período de silencio" brinda a los usuarios la oportunidad de acceder manualmente con una cuenta diferente. En esta entrada de blog, encontrarás más detalles sobre este "período de silencio".
Lightweight FedCM Preocupaciones de que la propuesta de Lightweight FedCM introduce complejidad adicional para los IdP debido a la necesidad de admitir dos implementaciones incompatibles (FedCM vs. Lightweight FedCM). FedCM ligero es compatible con FedCM tradicional. Los IdP pueden elegir qué método de implementación usar y no se les exigirá que admitan ambos.
Lightweight FedCM es un mecanismo de envío para FedCM. Si un IdP decide usar esta función, puede enviar la información de la cuenta al navegador cuando el usuario accede, de modo que, cuando una RP invoque FedCM, la cuenta se recupere del navegador en lugar del extremo de cuentas del IdP.
Lightweight FedCM Preocupaciones sobre la exposición de datos personales del usuario, como el nombre, el correo electrónico y la foto de perfil, al RP en la propuesta de Lightweight FedCM La propuesta de FedCM ligero se actualizó desde que recibimos estos comentarios para quitar el nombre, el correo electrónico y la imagen de perfil de la respuesta del método.
Lightweight FedCM La administración de varias cuentas con acceso no parece ser lo suficientemente flexible en la propuesta de FedCM ligero. Actualmente, la propuesta no admite duraciones de sesión individuales ni estados de acceso matizados por cuenta. Actualmente, el vencimiento está vinculado al IdP dentro del objeto de credenciales. Tomamos nota de la expiración por cuenta como una pregunta abierta y tendremos en cuenta estos comentarios para futuros desarrollos.
Lightweight FedCM No se define claramente la distinción entre "accedió" y "disponible para selección", lo que podría afectar la experiencia del usuario en la propuesta de Lightweight FedCM. Actualmente, no admitimos la capacidad de distinguir si una cuenta accedió o no a la interfaz de usuario (IU) de FedCM. No se deben mostrar las cuentas cerradas.
Si se cierra la sesión de una cuenta y se muestra en la lista, y un usuario selecciona la cuenta a la que no se accedió de forma activa, se puede usar la API de Continuation para que el usuario vuelva a acceder.
Uso de API Incoherencia entre el campo given_name en getUserInfo y su uso en la IU de FedCM. Este problema se analizó más a fondo con Mozilla aquí para definir cómo se debe tratar given_name en getUserInfo.
Uso de API No todos los campos que se usan en la IU de IdentityProviderAccount se proporcionan a getUserInfo, específicamente tel y username, lo que sugiere la necesidad de sincronización. El debate con Mozilla y otros miembros del Grupo de la comunidad de FedID avanza en el tema de conciliar qué campos de IdentityProviderAccount se envían a getUserInfo..
FedCM empresarial Solicitud de compatibilidad con FedCM para casos de uso de IdP empresarial. El problema clave es la necesidad de un mecanismo confiable para que los IdP indiquen a los navegadores que los administradores dieron su consentimiento previo para permitir que el usuario acceda a RP específicos que los rastreadores web no pueden imitar ni usar de forma abusiva. Esto se analizó en la reunión del 22 de abril del CG de FedID (aquí puedes encontrar las notas de la reunión), y se propusieron combinaciones de extensiones del navegador y políticas empresariales (para dispositivos administrados) como posibles soluciones. Agradecemos que nos envíes comentarios adicionales sobre este problema aquí.

Combate el spam y el fraude

API de Private State Tokens (y otras APIs)

No se recibieron comentarios este trimestre.