Informe trimestral del 1ᵉʳ trimestre de 2025 que 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 Competition and Markets Authority (CMA) en virtud de los párrafos 12, 17(c)(ii) y 32(a). En este informe, se describe el progreso de Google en las propuestas de Privacy Sandbox, las expectativas de plazos actualizadas, las explicaciones sustanciales 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 abordarlos.
Google ha mantenido a la CMA al tanto del progreso de las propuestas de Privacy Sandbox en sus reuniones de estado habituales programadas de conformidad con el párrafo 17(b) de los Compromisos. Además, el equipo mantiene la documentación para desarrolladores, que proporciona descripciones generales de las funciones principales de anuncios privados 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 comparten en las listas de distribución de los desarrolladores individuales.
Glosario de acrónimos
- ARA
- API de Attribution Reporting
- CHIPS
- Cookies con estado particionado independiente
- DSP
- Plataforma orientada a la demanda
- FedCM
- Administración de credenciales federadas
- 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 Origin
- API de PA
- API de Protected Audience (antes conocida como FLEDGE)
- PatCG
- Grupo de la comunidad de tecnología publicitaria privada
- 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
- Sugerencias de clientes de usuario-agente
- W3C
- World Wide Web Consortium
- WIPB
- Ceguera IP intencional
Comentarios generales, sin API ni tecnología específicas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Elección del usuario | No está claro cómo será el enfoque actualizado de Google para mejorar la elección del usuario, cómo se les presentará a los usuarios y las tasas previstas de aceptación o rechazo. Se requiere más información para distinguir esto de la baja de las cookies de terceros. | En abril de 2025, Google publicó una entrada de blog sobre los próximos pasos para Privacy Sandbox y las protecciones contra el seguimiento en Chrome, en la que anunció que tomó la decisión de mantener el enfoque actual para ofrecer a los usuarios cookies de terceros en Chrome y que no lanzará un nuevo mensaje independiente para las cookies de terceros. Brindaremos más actualizaciones a medida que estén disponibles. |
| Creación de huellas digitales | Google no compartió información con los publicadores ni los especialistas en marketing sobre cómo pueden recurrir a alternativas a los sistemas de anuncios de Google sin usar una identidad del consumidor más riesgosa como clave de coincidencia común (es decir, la creación de huellas digitales). | Destacamos varios sistemas de anuncios que no son de Google que ofrecen soluciones a los publicadores y especialistas en marketing que se compilan en parte con las APIs de Privacy Sandbox. Esto incluye los sistemas de anuncios que no son de Google en todos los mercados y canales. Puedes encontrar más detalles y casos de éxito en la sección Recursos para empresas de privacysandbox.com aquí. |
| Privacy Sandbox | Las APIs de Privacy Sandbox reemplazarían los ingredientes de datos de Internet por los propios productos terminados de Google. Dado que la alternativa de Google es una API, ofrece acceso a un producto que es de su propiedad y que controla, y que está sujeto a los términos y condiciones que Google puede aplicar a su discreción. Eso no reemplaza los componentes que usan otras personas para fabricar sus propios productos terminados. | Las APIs de Privacy Sandbox se desarrollaron e implementaron después de un amplio compromiso con los reguladores y una amplia variedad de partes interesadas del ecosistema. Al igual que con otras tecnologías de la plataforma, las APIs de Privacy Sandbox deben tener en cuenta que se usarán como componentes en los productos terminados de otros, y alentamos los esfuerzos del ecosistema para desarrollar tecnologías adicionales que funcionen junto con las APIs de Privacy Sandbox. |
| Elección del usuario | Solicitud de información sobre si el enfoque actualizado de Google para los 3PC en Chrome cumplirá con ciertos requisitos reglamentarios, lo que podría afectar la experiencia de las partes interesadas en la plataforma de administración de consentimiento. | En abril de 2025, Google publicó una entrada de blog sobre los próximos pasos para Privacy Sandbox y las protecciones contra el seguimiento en Chrome, en la que anunció que tomó la decisión de mantener el enfoque actual para ofrecer a los usuarios cookies de terceros en Chrome y que no lanzará un nuevo mensaje independiente para las cookies de terceros. Brindaremos más actualizaciones a medida que estén disponibles. |
| Cronograma y adopción de Privacy Sandbox | Las tecnologías publicitarias detuvieron las pruebas de las APIs de Privacy Sandbox y buscan razones más sólidas para reinvertir en estas tecnologías para las actividades de productos y marketing. Sus decisiones de reinversión están muy influenciadas por la necesidad de mayor claridad en el cronograma de User Choice, así como por las inquietudes sobre la latencia de la API de Protected Audience (API de PA) y la hoja de ruta de B&A. Además, existen inquietudes sobre la próxima revisión de los compromisos de la CMA, en particular, sobre el papel de Google como impulsor principal de las tecnologías de Privacy Sandbox sin depender de identificadores de terceros, y sobre la dirección general futura de la iniciativa para informar las estrategias de inversión. | En abril de 2025, Google publicó una entrada de blog sobre los próximos pasos para Privacy Sandbox y las protecciones contra el seguimiento en Chrome, en la que anunció que tomó la decisión de mantener el enfoque actual para ofrecer a los usuarios cookies de terceros en Chrome y que no lanzará un nuevo mensaje independiente para las cookies de terceros. Brindaremos más actualizaciones a medida que estén disponibles. Las subastas de la API de PA de Chrome son un 35% más rápidas año tras año. Además, observamos un aumento significativo en el uso de subastas paralelas, lo que proporciona un beneficio aún mayor para esas subastas. Nuestra hoja de ruta actual de B&A está disponible aquí. |
| Cronograma de Privacy Sandbox | ¿Qué se actualizó en la página de cronograma de Privacy Sandbox? | Recientemente, se agregó una descripción general de la API de Topics a la página de cronograma de Privacy Sandbox. |
| Privacy Sandbox | ¿Hay algún documento de investigación sobre privacidad y utilidad que ayude a comprender el impacto de Privacy Sandbox en los ingresos? | Los casos de éxito de mercado relevantes que abordan estas preguntas están disponibles aquí, y los resultados de las pruebas de las APIs de Privacy Sandbox están disponibles aquí. |
| Adopción de Privacy Sandbox | Un usuario pionero informó desafíos iniciales con las APIs de Privacy Sandbox debido a la lenta adopción por parte de las empresas más grandes, lo que afectó los lanzamientos de prueba. Sin embargo, a pesar de esto, se valoró el enfoque colaborativo del equipo de Privacy Sandbox y su capacidad de respuesta a los comentarios. | Agradecemos los comentarios de los usuarios pioneros. Nos comprometemos a colaborar con los usuarios pioneros y seguiremos interactuando con el ecosistema y recopilando comentarios mientras evaluamos el rol de las tecnologías de Privacy Sandbox en el apoyo al ecosistema. |
| Pruebas de Chrome | Inquietud por la capacidad de continuar con las pruebas de Privacy Sandbox de manera eficaz después de la eliminación de las etiquetas de prueba que destacan una diferencia significativa en la calidad del tráfico entre Chrome con 3PC inhabilitadas (modo B) y los usuarios que inhabilitaron personalmente las 3PC en la configuración de Chrome. | Nuestra respuesta es similar a la de trimestres anteriores: El equipo de Privacy Sandbox comprende que a las empresas les gustaría seguir usando las etiquetas de baja de cookies. El proceso para extender la disponibilidad de las etiquetas es similar al de extender una prueba de origen. La compatibilidad con las etiquetas se ha extendido en varias ocasiones. Planeamos proponer una mayor extensión de la compatibilidad con las etiquetas de baja de cookies y compartiremos actualizaciones en blink-dev a medida que estén disponibles. |
Inscripción y certificación
No se recibieron comentarios este trimestre.
Muestra anuncios y contenido relevantes
Temas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cómo habilitar o inhabilitar | ¿La confirmación de Google de que la Búsqueda de Google no usará la decisión de un sitio de inhabilitar la API de Topics como un indicador de clasificación impedirá que Google use la decisión de un sitio de habilitar la API de Topics como un indicador de clasificación? | Nuestra respuesta es similar a la de trimestres anteriores: El equipo de Privacy Sandbox no ha coordinado ni solicitado a la organización de Búsqueda que use la clasificación de páginas como incentivo para que los sitios web adopten la API de Topics. La Búsqueda de Google no usará la decisión de un sitio de admitir (o no) la API de Topics como un indicador de clasificación. |
| Observabilidad del uso | Solicitar un mecanismo de observabilidad para una SSP o una tecnología publicitaria general para poder ver si se usa su implementación de la API de Topics en la Web | Estamos evaluando la compatibilidad con esta función y agradecemos los comentarios adicionales del ecosistema si esta función es de alta prioridad. |
| Privacidad | Preguntas sobre el consentimiento y el potencial de reidentificación | Actualmente, estamos analizando este problema aquí y agradecemos los comentarios adicionales. |
API de Protected Audience
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| API de PA y GAM/AdX | Google no enviará ninguna demanda de GAM/AdX a un publicador que desee utilizar un servidor de anuncios de publicador rival. Google debería permitir que los publicadores rivales elijan vendedores alternativos de subastas de la API de PA de nivel superior para controlar la subasta final. La información de la API de PA estará disponible para GAM, pero estará restringida para las SSP rivales. Como resultado, los publicadores no pueden comparar el rendimiento de la demanda proveniente de la API de PA en GAM, como la de AdX o las SSP integradas en la API de PA. | Respuesta de Chrome: El estándar de la API de PA está diseñado para ser flexible y permite que diferentes partes ejecuten la subasta de nivel superior. Esta elección depende de las implementaciones y capacidades específicas que ofrece el servidor de anuncios del publicador (ya sea GAM o algún otro) y otras empresas participantes en el ecosistema. El diseño centrado en la privacidad de la API de PA limita los informes detallados para todos los participantes de forma coherente. Los datos específicos que se informan desde la subasta de la API de PA están sujetos a las mismas reglas y limitaciones de preservación de la privacidad definidas por la API para todos los participantes, incluidas las SSP. Los publicadores usan los informes agregados y que preservan la privacidad de la API de PA para evaluar el rendimiento. Esto permite evaluar la contribución general de la demanda obtenida a través de la API de PA y compararla con otros canales de demanda, de acuerdo con los principios de privacidad desde el diseño de la API. Respuesta proporcionada por Google Ad Manager: Los publicadores no están obligados a usar la función del servidor de anuncios de GAM para acceder a la demanda de AdX. Además, la API de PA no distingue quién inicia una subasta, ya sea en diseños de un solo vendedor o de varios vendedores. |
| Vendedor de nivel superior | El vendedor de nivel superior (TLS) tiene acceso a información a la que no tiene acceso ninguno de los otros vendedores de componentes, lo que genera inquietudes sobre el acceso desigual a la información. Si bien cualquier entidad puede ser el TLS, para acceder a la demanda de AdX, los publicadores deben usar GAM como servidor de anuncios del publicador. Esto crea un incentivo para usar GAM como servidor de anuncios del publicador, lo que genera una ventaja competitiva para Google. | Respuesta de Chrome: El diseño de la API de PA no dicta qué entidad puede actuar como TLS. El rol de TLS requiere coordinar la subasta y acceder a la información relacionada según la estructura de la API. Respuesta proporcionada por Google Ad Manager: Durante años, nos hemos enfocado en la equidad de las subastas, lo que incluye nuestra promesa de que ningún precio de ninguna de las fuentes publicitarias no garantizadas de un publicador, incluidos los precios de las líneas de pedido no garantizadas, se compartirá con otro comprador antes de que realice una oferta en la subasta, lo que reafirmamos más adelante en nuestros compromisos con la Autoridad de la Competencia de Francia. En el caso de las subastas de la API de PA, tenemos la intención de cumplir nuestra promesa 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 subastas de varios vendedores. Para que quede claro, no compartiremos el precio de la subasta contextual con ninguna subasta de componentes, incluida la nuestra, como se explica en esta actualización. Además, no usamos información sobre la configuración de subastas de componentes, incluidos los indicadores que los compradores proporcionan a las SSP, como parte de nuestra propia subasta. Además, como se indicó anteriormente, GAM no requiere que los publicadores usen su funcionalidad de servidor de anuncios para acceder a la demanda de AdX. Por último, como se señaló anteriormente en el informe del segundo y tercer trimestre de 2024 de Google, las plataformas orientadas a la compra de Google (Google Ads, anteriormente AdWords, y DV360) compran impresiones de intercambios que no son de Google, incluso a través de la API de PA. |
| API de PA y GAM/AdX | Para los publicadores, es difícil comprender la activación de la API de PA en el 100% del inventario, ya que el etiquetado de la opción no deja claro el propósito. En el caso de las SSP, cuyo medio principal de acceso al inventario suele ser a través de una subasta de varios niveles con GAM como TLS, no hay forma de realizar pruebas ni monetizar a través de la API de PA sin estar sujeto a GAM. | Respuesta de Chrome: El estándar de la API de PA define los roles técnicos (como el vendedor de TLS y componentes) y el proceso de subasta, lo que permite flexibilidad en las plataformas que desempeñan estos roles. Las partes que implementan (publicadores, SSP y proveedores de TLS) administran las actividades operativas, como la configuración, la coordinación y los acuerdos, para facilitar la participación con el framework de la API de PA. Respuesta proporcionada por Google Ad Manager: Como se describe en nuestro Centro de ayuda, Ad Manager ofrece a los publicadores un control para habilitar pruebas con vendedores de componentes que no sean de Google, como otras SSP, en el 100% del inventario de un publicador en el que la API esté disponible para su uso (anula cualquier muestreo o limitación que pueda aplicar GAM). Si un publicador habilita este control, cada vez que un vendedor de componentes que no es de Google proporcione una configuración de subasta, GAM intentará ejecutar una subasta de nivel superior con la subasta de componentes proporcionada, siempre y cuando el publicador haya obtenido el consentimiento del usuario necesario para hacerlo. GAM les deja claro a los publicadores que este control puede afectar el rendimiento, de modo que puedan tomar una decisión informada. |
| Del servidor en comparación con en el dispositivo | Las soluciones del servidor, como las ofertas y subastas (B&A), tienen el potencial de resolver la conformación del tráfico y, al mismo tiempo, mantener la privacidad. Las soluciones del servidor son la única opción viable y Google debería abandonar las soluciones integradas en el dispositivo. | El objetivo de Privacy Sandbox es admitir soluciones de subastas del servidor (servicios de B&A) y en el dispositivo, lo que proporciona opciones para satisfacer diferentes necesidades y casos de uso de la tecnología publicitaria. |
| Seguridad de subastas | Los ataques a las ofertas de la API de PA son, en esencia, descalificantes para las ofertas y subastas integradas en el dispositivo. Las partes interesadas no consideran que este problema esté resuelto y siguen solicitando garantías técnicas para garantizar que no se manipulen las ofertas de la API de PA, así como un modo de depuración exhaustivo para proporcionar detección de incidentes en tiempo real y depuración eficiente. | Garantizar la integridad de las subastas de la API de PA, incluida la mitigación de posibles ataques, es un enfoque clave de Privacy Sandbox. El diseño de la API incorpora medidas de integridad, y agradecemos que nos envíes más comentarios técnicos sobre inquietudes específicas. Presentamos y analizamos una lista detallada de posibles ataques a la API de PA y nuestras mitigaciones durante la reunión del grupo comunitario de lucha contra el fraude del W3C en mayo de 2024. Aceptamos más debates y comentarios sobre los posibles "ataques a las ofertas de la API de PA" que te preocupan. |
| Tráfico sin cookies | ¿Habrá una forma de habilitar la API de PA solo en el tráfico sin cookies para pruebas o para otros fines? | Las tecnologías publicitarias pueden identificar si hay 3PC o no. Esto se explica con más detalle aquí. |
| ID de asiento | En lo que respecta a la propuesta de ID de asiento, el conocimiento del ID de asiento es esencial para la mayoría de las solicitudes de oferta, lo que genera preocupación sobre la vinculación del ID de asiento al registro de creatividades. Además, ¿se aplicaría solo al "anuncio principal" o también a los anuncios de componentes? | La propuesta de BuyerAndSellerReportingId aborda la preocupación por la falta del ID de Seat del comprador durante el registro de la creatividad para el anuncio principal. El objetivo de este identificador es comunicar el ID de asiento del comprador al vendedor. Estamos evaluando la compatibilidad con los anuncios de componentes. |
| Supervisión y creación de informes | Solicitud de función para la supervisión en tiempo real (RTM) para (1) enviar informes de RTM para subastas canceladas y (2) nuevos buckets propagados por el navegador para aclarar qué tipo de cancelación se produjo. | Al parecer, la RTM no es una solución adecuada para investigar el porcentaje de participación. La RTM se diseñó, como una API de supervisión de baja latencia, para detectar interrupciones críticas, repentinas y temporales. Por el contrario, el porcentaje de participación no requiere informes de baja latencia y no es una interrupción temporal repentina y crítica. Los vendedores con los que los compradores colaboran son quienes responden de manera más eficaz las inquietudes sobre las tasas de participación, y no los compradores que investigan a través del navegador. Además, como las subastas canceladas son muy comunes, si el navegador generara informes de RTM de cada subasta cancelada, podría anular los informes de RTM de las interrupciones reales. |
| Documentación Aclaración |
Se informó una discrepancia en la documentación de la explicación de la API de PA que indica que el nonce debe ser una cadena de UUID, pero en realidad muestra una promesa. | Aquí se propone una aclaración. |
| Contexto congelado |
Cuando se trabaja con un contexto congelado, ¿qué opciones están disponibles para abordar problemas y desafíos relacionados con (1) el empaquetado, (2) las bibliotecas externas y (3) los tipos de datos no admitidos? | Aquí encontrarás una respuesta a esta pregunta. |
| Especificaciones | La API de Private Aggregation agregó una operación genérica contributeToHistogramOnEvent. Como consecuencia, la definición en la API de PA se convirtió en una operación sobrecargada, y las operaciones del IDL web "no deben sobrecargarse en la interfaz, la interfaz parcial [...]", por lo que esa definición ahora no es válida. | Este problema señala una incoherencia temporal entre la API de PA y las especificaciones de agregación privada mientras combinamos cambios similares en ambas. Combinamos una solicitud de extracción para abordar este problema. |
| Grupos de interés | Solicita orientación sobre el método recomendado y eficiente en recursos para finalizar la participación de ofertas de un grupo de interés (GI) cuando se detiene una campaña. | Estas son algunas sugerencias que podemos ofrecerte: Creemos que el mecanismo con la latencia más baja, el menos permanente, pero también el que libera menos recursos, es usar los indicadores de ofertas en tiempo real para informar a su generateBid() que deje de realizar ofertas. La segunda opción que usa menos recursos sería establecer una prioridad negativa para ese IG en la respuesta de los indicadores de ofertas en tiempo real, ya que esto impediría que se invoque generateBid(). La tercera opción, que usa aún menos recursos, sería quitar los anuncios del IG. Los IG sin anuncios no tienen invocado su generateBid(). La cuarta opción, que usa aún menos recursos, sería quitar el biddingLogicURL del IG. En este punto, el IG aún se puede actualizar o volver a unir para reactivarlo. Otras opciones giran en torno a salir del IG, ya sea a través de leaveAdInterestGroup() o clearOriginJoinedAdInterestGroups(), o cuando vence el IG.Como se destacó anteriormente, las diferentes opciones tienen diferentes implicaciones de latencia y consumo de recursos. Las tecnologías publicitarias pueden elegir la opción que tenga la mejor relación costo-beneficio para sus casos de uso específicos. |
| Públicos | Solicitud de un mecanismo para ejecutar operaciones lógicas en los públicos creados (p.ej., la capacidad de segmentar una intersección de IG A y B) | Con la API de PA, hoy es posible ejecutar operaciones lógicas en públicos del mismo sitio. Actualmente, no se admiten las operaciones lógicas de públicos en diferentes sitios por motivos de privacidad, como se explica en nuestro modelo de privacidad. Seguimos realizando investigaciones en esta área y compartiremos las actualizaciones a medida que las tengamos. |
| Solicitud de función | Propuesta para quitar la restricción de las ofertas adicionales que requieren que se conozca el TLS con anticipación. | Actualmente, estamos analizando esta propuesta aquí y recibimos con gusto más comentarios. |
| Enfoque actualizado para 3PC en Chrome | ¿Las APIs de Privacy Sandbox, como la API de PA, seguirán disponibles para todos los usuarios de Chrome estable, o las APIs (o un subconjunto de ellas) solo estarán disponibles para los usuarios que rechazaron las 3PC? | No es nuestra intención que la decisión de un usuario de rechazar las cookies de terceros tenga un impacto en la disponibilidad de las APIs de Privacy Sandbox en Chrome estable. |
| Señales mejoradas | ¿Hay planes para agregar una funcionalidad que indique si el TLS tiene la intención de ejecutar una subasta de la API de PA? | Estamos evaluando la compatibilidad con esta función. Compartiremos más detalles sobre los plazos cuando estén disponibles y recibimos con gusto comentarios adicionales sobre esta solicitud. |
| ID de oferta | Inquietud por el hecho de que el requisito del servidor de KV en la propuesta de ID de oferta pueda ser un proceso costoso y lento del servidor. | La propuesta de ID de oferta permite que las SSP consulten los metadatos de los IDs de oferta seleccionados desde el servidor de par clave-valor durante las subastas de PA, de modo que no tengan que precargar todos los metadatos relacionados con la oferta en el dispositivo. Esta propuesta se está desarrollando en respuesta a las solicitudes de las SSP, y recibimos con gusto comentarios adicionales del ecosistema aquí. Entendemos que se requiere trabajo para configurar el servidor de par clave-valor, pero, en general, creemos que este es un beneficio neto para las empresas de tecnología publicitaria. Seguimos recibiendo comentarios y sugerencias para facilitar este proceso. |
| Limitación de frecuencia entre IG | Solicitud de limitación de frecuencia en IG a través de la API de PA. | La limitación de frecuencia entre IG tiene características de privacidad desafiantes para las que no pudimos encontrar soluciones. Si esta función es de alta prioridad, recibimos con gusto más comentarios del ecosistema. |
| Informes de IDs de acuerdos y IDs de asientos | Solicitar la capacidad de obtener IDs de ofertas o asientos en los informes agregados | Las funciones de ID de informes en las que estamos trabajando aquí permitirán generar informes de los IDs de acuerdos y asientos. selectedBuyerAndSellerReportingId se proporciona a reportResult(), por lo que la forma más fácil de informarlo sería a través de informes a nivel del evento (es decir, codificar el ID de la oferta en la URL que se pasa a sendReportTo()). Si se usaran informes agregados, también se podría hacer. Actualmente, la función de ID de informe está disponible para el 10% del tráfico del canal estable de Chrome. Estamos evaluando expandir el lanzamiento al 100%. |
| Grupos de interés | Usa el mismo orden de prioridad en la selección y evaluación de los IG, y en todos los modos de evaluación. | Actualmente, estamos analizando este tema aquí y recibimos con gusto más comentarios. |
| Grupos de interés | Se sugiere usar la activación y la delegación de públicos como formas de aumentar la adopción de la API de Privacy Sandbox. | Estamos al tanto de esta solicitud de varias partes interesadas y estamos investigando una solución. Los comentarios adicionales del ecosistema son bienvenidos. |
| Grupos de interés | Desafíos relacionados con la creación de IG de la API de PA, específicamente en lo que respecta a la delegación y la propiedad cuando se actúa para varias compras o en nombre de los publicadores. | Recibimos la solicitud de varias partes interesadas para admitir delegaciones de IG más avanzadas y vemos el valor agregado de las SSP que contribuyen a este proceso. Estamos realizando investigaciones para encontrar la mejor solución que permita que diferentes partes participen en el proceso de extensión del público. Agradecemos los comentarios adicionales del ecosistema. |
| Rendimiento del cliente | Solicita orientación para facilitar la caché del cliente de trustedBiddingSignals para optimizar el costo de la infraestructura y la latencia. | Actualmente, estamos analizando este tema aquí y recibimos con gusto más comentarios. |
Subasta protegida (servicios de ofertas y subastas)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Servicios de par clave-valor | ¿Cómo se agrupan las solicitudes del navegador al servidor de KV del vendedor? Para un vendedor, ¿cómo se verá la solicitud del navegador, como una solicitud GET o POST? Además, se necesitan algunas aclaraciones sobre los requisitos de k-anonimato. | En el caso de la versión 1, Chrome envía una solicitud GET al servicio de KV del vendedor para recuperar trustedScoringSignalsURL con los indicadores de los parámetros de consulta de la solicitud. Los parámetros incluirían hostname, renderUrls, adComponentRenderUrls y experimentGroupId. Actualmente, estamos experimentando con algunas extensiones para enviar información adicional para el análisis de creatividades, pero aún no se lanzaron. Cuando se establece maxTrustedScoringSignalsURLLength en 0, Chrome podría agrupar todos los indicadores en una sola solicitud (posiblemente superando cualquier límite de longitud de URL en su servidor), pero no se garantiza. Actualmente, Chrome elige incluir solicitudes en el mismo lote si están listas para enviarse en un plazo de 10 ms, aunque actualmente estamos investigando cómo optimizar esto.Cuando trabajes con trustedScoringSignals, es útil recordar que Chrome respeta los encabezados de almacenamiento en caché. Los encabezados como el encabezado "Cache-Control" de Stale-While-Revalidate podrían reducir la latencia promedio, ya que permiten que Chrome use la copia almacenada en caché (y actualice la caché para la próxima subasta), lo que quita de manera eficaz la recuperación de indicadores de la ruta crítica.Por último, en lo que respecta al k-anonimato, la sección particular de la explicación parece estar desactualizada. Originalmente, íbamos a exigir que las URLs de los indicadores de confianza fueran k-anónimas, pero se eliminó ese requisito. Quitaremos esta oración de la explicación. |
| Servicios de B&A | La actualización a la versión más reciente de B&A lleva mucho tiempo. Sería beneficioso tener tiempos de compilación más rápidos o imágenes precompiladas. | Las tecnologías publicitarias pueden compilar los objetos binarios por su cuenta y validarlos con los valores hash proporcionados. En el futuro, consideraremos investigar la posibilidad de proporcionar artefactos precompilados o mejorar los tiempos de compilación. |
| Solicitud de funciones de la API | Solicitud de compatibilidad con macOS para las secuencias de comandos de compilación, las imágenes de contenedor y las herramientas de invocación de los servicios de ofertas y subastas (B&A) para facilitar el desarrollo y las pruebas locales. | Actualmente, admitimos amd64, que es suficiente para la implementación en las plataformas en la nube compatibles (GCP y AWS). Es posible que investiguemos la compatibilidad con otras arquitecturas en el futuro. |
| AWS | ¿Es necesario crear roles de IAM para las compilaciones de producción? | Sí, los roles de IAM son necesarios para obtener los permisos adecuados y comunicarse con los coordinadores. Las claves se usan para desencriptar el texto cifrado de ProtectedAudienceInput que se genera en el dispositivo, como se describe aquí. Además, estos roles deben aprobar la certificación del servidor o TEE de las compilaciones de producción con esos mismos coordinadores. Esto se aborda con más detalle en nuestra guía de autoservicio. |
| Marcas de B&A | Solicitar que se incluyan definiciones de las marcas de B&A disponibles en la documentación, ya que, en la actualidad, estas definiciones residen en el código de Terraform, los archivos cc y los archivos proto, pero las tecnologías publicitarias se beneficiarían de la documentación sobre estas marcas, ya que la aprovecharían como fuente de información para comprender cómo personalizar las implementaciones. | Estamos investigando la posibilidad de documentar las descripciones de las marcas de Terraform y recibimos comentarios adicionales aquí. |
| Servicio de ofertas de AWS |
Necesita orientación sobre el servicio de ofertas en AWS y el comportamiento y la configuración de registro predeterminados. | Para depurar tus servicios de ofertas dentro del TEE (como el servicio de ofertas), te recomendamos que uses la depuración con consentimiento de Ad Tech. Esto te permite habilitar el registro detallado y capturar datos de solicitud o respuesta para tus solicitudes de prueba específicas directamente desde tu cliente para ayudar con la depuración. |
| Documentación de TEE K/V |
Solicitamos una aclaración sobre el inicio de la aplicación de las TKV, como se indica en el sitio para desarrolladores. | Te avisaremos con suficiente anticipación antes de exigir el uso de TEE. Hasta entonces, puedes seguir usando tu propio servidor para los indicadores de par clave-valor en tiempo real. |
| Pruebas y análisis de B&A | El análisis y las pruebas de B&A siguen siendo costosos y no parecen estar listos para la producción. | Para poder analizarlo en más detalle, necesitamos más información sobre el análisis de costos y los factores que llevan a la evaluación de la preparación para la producción. |
| Optimización de servidores de confianza | Propuesta para combinar los parámetros específicos de los vendedores de componentes en un parámetro inputsPerSeller, con una cadena JSON para su valor. | Estamos analizando esta propuesta y recibimos con gusto comentarios adicionales aquí. |
| Seguridad | ¿Cómo se mitigan los riesgos de seguridad de la TKV con el uso de B&A? | Es posible evitar las llamadas externas a TKV. Actualmente, esta función es totalmente compatible y se puede configurar en GCP. En el caso de AWS, se debe desarrollar una asistencia adicional debido a la baja de AWS App Mesh, que antes habilitaba esta función. Aquí puedes enviarnos tus comentarios adicionales. |
| Servicios de B&A | Solicitar claridad en la narrativa o la comunicación sobre el valor de la transmisión HTTP para la optimización de B&A | Privacy Sandbox admite capacidades de transmisión para transferir datos de B&A y mejorar la latencia de las tecnologías publicitarias que elijan usarla. Es una optimización de rendimiento opcional en el caso del modo mixto. |
| Prebid | Solicita actualizaciones sobre cómo contribuir a la biblioteca de código abierto de Prebid para habilitar las funciones de B&A de la API de PA para el ecosistema. | En marzo de 2025, Chrome lanzó la optimización preferida de Prebid en la versión estable, como se documenta en la ruta de planificación pública de B&A (consulta marzo de 2025). |
| Determinación por tráfico | Solicitud de mecanismos para registrar los indicadores contextuales que recibe B&A para comprender mejor cuándo se activan los IG y mejorar su lógica de "intención de oferta" en la respuesta contextual. Esto permite un mejor uso de los recursos de red para evitar el "tráfico inútil" (también conocido como modelado de tráfico). | Actualmente, estamos analizando una propuesta aquí y recibimos con gusto comentarios adicionales. |
| Documentación Aclaración |
Se necesita una aclaración sobre el error "No se puede acceder al proxy de servicio o Vsock" que se detectó en la configuración de integración de prueba de B&A. | Esto se debe a los requisitos mínimos de memoria.Se actualizó la explicación de la configuración de AWS para reflejar este requisito. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Datos en tiempo real | La falta de datos en tiempo real afecta a todos los sectores. La demora de los datos en tiempo real es un problema grave para los anunciantes, ya que los compradores se trasladan a plataformas que tienen Google Analytics, ya que es el único lugar en el que pueden obtener pruebas de que llegan a los públicos. | Las demoras de datos en tiempo real que forman parte de la API de Attribution Reporting (ARA) se implementan como mecanismos de protección de la privacidad para reducir la capacidad de las tecnologías publicitarias de usar informes a nivel del evento para hacer un seguimiento de los usuarios en varios sitios. Sin embargo, la ARA proporciona flexibilidad en la forma en que se entregan los informes de atribución, ya que permite que los informes a nivel del evento tengan una ventana mínima de informes de 1 hora y que los informes agregados tengan la opción de enviarse de inmediato a las tecnologías publicitarias sin demoras. |
| Uso de API | Solicitud de confirmación sobre la configuración correcta de un flujo de atribución entre aplicaciones web, específicamente cuando se opera la atribución web a web y web a aplicación en paralelo. | Cuando se publican campañas de Web a Web y de Web a aplicación en paralelo, la tecnología publicitaria debe elegir solo una plataforma para registrar cada fuente o activador, a fin de evitar el registro doble. Te recomendamos que uses el sistema operativo (SO) siempre que sea posible, ya que puede realizar la atribución web a web y web a aplicación, siempre y cuando las fuentes y los activadores web se hayan delegado correctamente. Esto significaría responder con el encabezado Attribution-Reporting-Register-OS-Source para las fuentes y Attribution-Reporting-Register-OS-Trigger para los activadores. El encabezado Attribution-Reporting-Support se puede usar para identificar si hay compatibilidad a nivel de Chrome o Android. El encabezado Attribution-Reporting-Info es útil cuando no hay un encabezado Attribution-Reporting-Support en la solicitud. En ese caso, el navegador tomará la decisión de registro de la plataforma en función de la disponibilidad de la compatibilidad con la plataforma en el dispositivo del usuario. |
| Especificaciones de API | Solicitamos aclaraciones sobre el encabezado de solicitud HTTP de Attribution-Reporting-Support que establece la API de Attribution Reporting y si se pretende que el encabezado contenga claves de Web y de SO, independientemente de la plataforma. | El encabezado Attribution-Reporting-Support está sujeto a que el navegador agregue parámetros "GREASE" para garantizar que los servidores usen un analizador de encabezados estructurados que cumpla con las especificaciones. Para este encabezado, solo se deben interpretar las claves del diccionario estructurado. Actualmente, los valores y parámetros no se usan. Consulta aquí para ver un ejemplo. |
| Informes basados en 3PC | Solicitar orientación para solucionar problemas de discrepancias en la medición entre la ARA y los terceros en las campañas publicitarias | La ARA admite dos tipos de informes de depuración que se pueden usar para solucionar problemas y depurar discrepancias. Los informes de depuración de atribución correcta se pueden usar para comparar fácilmente los resultados de la ARA con los de otras tecnologías de medición, y los informes de depuración detallados se pueden usar para recibir más información y solucionar posibles problemas en los registros de atribución. |
| Uso de API | Durante las pruebas de la ARA, se descubrieron ciertos problemas: informes detallados insuficientes que generaban datos con ruido y una optimización de campañas inflexible, umbrales altos que excluían a los anunciantes más pequeños y dificultades para comparar campañas debido a indicadores clave de rendimiento incoherentes. | La ARA proporciona flexibilidad, ya que ofrece varios parámetros que las tecnologías publicitarias pueden personalizar para lograr sus casos de uso de medición específicos. Los informes a nivel del evento admiten informes flexibles a nivel del evento, lo que permite que las tecnologías publicitarias personalicen sus períodos de informes, la cantidad de informes que pueden recibir y los datos de activadores que desean medir, lo que puede cambiar el impacto del ruido en sus datos y permitirles lograr diferentes casos de uso. Del mismo modo, los informes agregados tienen diferentes formas en que las tecnologías publicitarias pueden personalizar sus parámetros de configuración, como la cantidad de dimensiones de las que realizan un seguimiento, la frecuencia de procesamiento por lotes y el uso del presupuesto de contribución para cambiar el impacto del ruido y lograr diferentes casos de uso. |
| Especificaciones de API | Pregunta sobre la dependencia de ARA en 3PC, específicamente en cuanto a si permanece en una fase de prueba que requiere estos 3PC. | La ARA se habilita independientemente de los 3PC, pero estos deben estar habilitados para permitir que los informes de depuración de transición de la ARA comparen los resultados de la ARA con los resultados de atribución basados en cookies. |
| Uso de API | Consulta sobre el registro de fuentes para la atribución de apps a la Web en versiones anteriores de Android (11, 12 y 13) con ARA. | Actualmente, ARA es compatible con Android S y versiones posteriores (12 y versiones posteriores). |
| Uso de API | Solicitar detalles de distribución y tarifas de participación en la ARA | Nuestra respuesta no ha cambiado desde los trimestres anteriores: "No tenemos planes de compartir esta información con el ecosistema. Los desarrolladores pueden llamar a las APIs en las que ya implementaron código para estimar la disponibilidad de las APIs de Privacy Sandbox". |
| Disponibilidad de la API | Cuando se habilita ARA, ¿se habilitan o inhabilitan los 3PC? | Cuando la ARA está habilitada en el navegador de los usuarios, no tiene ningún efecto en la configuración de cookies de los usuarios. Es posible que la ARA esté habilitada y que el usuario tenga las cookies habilitadas o inhabilitadas. |
| Informes | ¿Hay una lista predefinida de valores que podamos recibir en el encabezado "Attribution-reporting-support"? | Como se indica en nuestra guía, el valor es un diccionario de encabezados estructurados, cuya única semántica definida actualmente es la presencia o ausencia de las claves web y del SO. Se deben ignorar todas las demás partes del encabezado. En otras palabras, el análisis requiere el uso de un analizador de encabezados estructurado, no una coincidencia de cadenas simple. |
Servicio de agregación
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Solicitud de función | Solicitudes de funciones para el servicio de agregación: Integraciones de servidor a servidor, medición en varios dispositivos, atribución multitáctil y generación de informes de contribución, atribución en varios canales y compatibilidad con ciclos de optimización de la IA avanzados (p.ej., Entrenamiento de modelos privados). |
Estamos evaluando estas solicitudes y compartiremos más detalles cuando estén disponibles. Agradecemos los comentarios adicionales del ecosistema sobre si estas solicitudes son una prioridad. |
| Solicitud de función | Se solicitó establecer el parámetro delete_on_termination de EBS en True en el entorno de Terraform para mitigar las inquietudes sobre el restablecimiento cuando se actualiza el servicio de agregación. | Estamos evaluando esta solicitud y compartiremos más detalles cuando estén disponibles. Aceptamos comentarios adicionales del ecosistema sobre si esta solicitud es una prioridad aquí. |
| Documentación Aclaración |
Solicitar orientación sobre lo que se puede cambiar (p. ej., los umbrales de supervisión) y lo que no se debe modificar | Estamos evaluando la publicación de documentación y orientación adicionales sobre las personalizaciones disponibles para el servicio de agregación. |
| Implementación | Solicitud de aclaración sobre la falla de la nueva implementación en el comando bazel. | La implementación puede fallar debido a la versión de Bazel que se usa en el entorno. Se ajustará la documentación para abarcar la depuración de fallas de Terraform y para indicar la versión de bazel requerida. |
API de Private Aggregation
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Uso de API | Solicitud de orientación sobre algunos desafíos de implementación, como la posible pérdida de datos debido a las limitaciones informadas del almacenamiento compartido, las dificultades con la cardinalidad alta que requieren listas de entidades permitidas complejas del servicio de agregación (se sugiere el uso de comodines) y las pruebas lentas causadas por la regla "sin duplicados" del servicio de agregación. | En cuanto a las limitaciones de Shared Storage, el límite de 20 contribuciones (que se detalla aquí) es por ejecución, no por mes. Además, los llamadores de la API pueden anular este límite. El límite se implementó para ayudar a administrar el costo de procesamiento de informes en el servicio de agregación y no para limitar la utilidad de los informes. En relación con las consultas de comodín, estamos evaluando esta solicitud y compartiremos más detalles cuando estén disponibles. En relación con la regla "Sin duplicados", para habilitar las pruebas, admitimos temporalmente el modo de depuración con el fin de omitir esta regla. Esto se describe con más detalle aquí . |
| ID de filtrado y buckets | ¿Es posible solicitar al servicio de agregación el mismo bucket con dos IDs de filtrado diferentes en dos ejecuciones de agregación independientes? Es decir, ¿puede el ID de filtrado actuar como una partición complementaria de dominios? | Sí, esta función es compatible. Cuando se realice una agregación, solo se procesarán las contribuciones con un ID de filtrado que coincida con la lista de los parámetros de trabajo, y el resto permanecerá disponible para procesarse en ejecuciones independientes. |
| Atribución de múltiples puntos de contacto | Solicitudes de aclaración sobre la implementación de la atribución multitoque (MTA): 1) ¿Hay un límite para la cantidad de contribuciones si el valor de agregación no supera 2^16? 2) ¿Existe un límite para la cantidad de claves de agregación únicas (buckets) que se pueden almacenar para un contexto determinado? 3) ¿Cómo procesa el servicio de agregación los informes de resumen cuando cada usuario-agente (navegador) tiene una clave de agregación única, como es probable que suceda en MTA? |
1) Implementamos límites de contribución predeterminados, pero el llamador de la API puede anularlos, como se explica aquí. El propósito de los límites es ayudar a los llamadores de la API a administrar el costo de procesamiento de informes en el servicio de agregación. 2) No existe tal límite, aunque las tecnologías publicitarias deben considerar el nivel de detalle de las claves de agregación para mejorar la relación señal-ruido, como se explica con más detalle aquí. 3) Consulta esta guía, en especial la guía de relación señal/ruido que se abordó anteriormente en el punto 2). |
Limita el seguimiento encubierto
Reducción de usuario-agente/Sugerencias de clientes de usuario-agente
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Solicitud de función | Se solicitó agregar Sec-CH-UA-Robot a las sugerencias de clientes de usuario-agente (UA-CH), ya que permitiría que los servidores identifiquen el tráfico automatizado para la adaptación de contenido, la seguridad y las estadísticas. | Este es un caso de uso importante que se está analizando en otros grupos de estándares (consulta aquí para obtener más detalles) y recomendamos a las partes interesadas que participen y envíen sus comentarios. Sin embargo, consideramos que UA-CH podría no ser la solución adecuada, ya que el tráfico automatizado puede manipular fácilmente los encabezados de solicitud HTTP. |
IP Protection (antes Gnatcatcher)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Privacidad de las direcciones IP | Dejar las direcciones IP disponibles para que Google las use contradice sus objetivos de privacidad declarados. Aunque Google dice que anonimiza los datos a través de la Protección de IP, los usuarios deben haber accedido a Chrome para usarla, por lo que Google aún conoce sus identidades. | Los motivos del acceso son para evitar fraudes y abusos, principalmente, limitar el acceso a los proxies. Además, para proteger la privacidad de los usuarios en el contexto del requisito de autenticación, nuestro diseño de tokens está firmado de forma ciega, lo que significa que el token emitido durante el acceso es diferente del token que se usa durante el proxy, por lo que los tokens emitidos no se pueden vincular a la identidad de Google de un usuario más adelante. Esto significa que Google no sabe quién es el usuario cuando se usa un proxy para su tráfico en modo Incógnito, a pesar del requisito de autenticación por motivos de prevención de fraudes. |
| Privacidad de las direcciones IP | El uso de IPs es un paso en la dirección equivocada. No se pueden borrar del navegador, como las cookies, y los usuarios no tienen los mismos controles de transparencia que con las cookies. Si desaparecen las cookies, la industria pasará a usar las IP como solución alternativa, dando prioridad a la autopreservación sobre la privacidad. | Como plataforma, el objetivo de Chrome es proporcionar a los usuarios funciones que mejoren su experiencia de navegación en la Web. Para los usuarios de Chrome que eligen navegar en modo Incógnito, esto significa brindar protecciones mejoradas contra el seguimiento entre sitios limitando la disponibilidad de la información de la dirección IP en contextos de terceros. |
| Lista de dominios enmascarados | ¿Cuáles son los criterios de selección de la lista de dominios enmascarados (MDL)? | Chrome desarrolló criterios para identificar qué dominios deben estar en la MDL y, por lo tanto, recibir direcciones IP enmascaradas en un contexto de terceros. Google se asoció con Disconnect.me, un destacado líder en privacidad en Internet que también colabora con otros navegadores web. Chrome aprovechará Disconnect.me para identificar los dominios que se alinean con los criterios establecidos por Chrome. Además, Chrome desarrolló una metodología para identificar funciones de JavaScript muy utilizadas que proporcionan resultados coherentes a partir de APIs web estables y de alta entropía y, por lo tanto, se pueden usar para construir identificadores probabilísticos de alta entropía. Luego, estas funciones se detectan cuando se cargan en sitios web en un contexto de terceros, lo que genera una lista de dominios que entregan secuencias de comandos con estas características que se convierten en parte de la MDL y, por lo tanto, se usan proxies. La canalización de detección que busca estos patrones de uso inadecuado de la API considera todos los dominios, incluidos los propios de Google. |
| Prevención de fraudes | Comentarios sobre los tokens de revelación probabilísticos (PRT) que indican que la demora de revelación propuesta de 24 horas y las tasas de revelación impiden la detección de fraudes en tiempo real. Solicita demoras más cortas (1 hora) y tarifas más altas (al menos de dos dígitos). Otras sugerencias incluyen habilitar tarifas diferenciales en función de indicadores de riesgo (VPN, navegadores automatizados) y permitir revelaciones segmentadas de tokens específicos. | La mayoría de los desarrolladores con los que hablamos proporcionan informes por hora a sus clientes y varios actualizan las listas de bloqueo de IP a lo largo del día. Un período de demora más corto permite actualizaciones más frecuentes y, en menos de una hora, volvería a habilitar la medición de la IVT en las estadísticas por hora, pero también podría aumentar la probabilidad de que los usuarios vuelvan a ser identificables. Estamos dispuestos a explorar la reducción de los períodos de demora y el cambio de la tasa de revelación en función de los estudios del ecosistema y los comentarios de las partes interesadas. Aquí puedes enviarnos más comentarios. |
| Lista de dominios enmascarados | Pregunta sobre la inclusión del dominio en el MDL a pesar de no tener un caso de uso publicitario. Se teme que esto pueda permitir que la "conmutación de IP" cree perfiles basados en direcciones IP. | Reconocemos la importancia de implementar un proceso de apelación para nuestro enfoque basado en listas. Las apelaciones permiten que las empresas afirmen que su dominio en el MDL no cumple con los criterios de inclusión y que debe quitarse, lo que permite que ese dominio siga recibiendo las direcciones IP originales de los usuarios en un contexto de terceros en el modo Incógnito. Lanzamos el proceso de apelaciones para brindarles a los propietarios de dominios tiempo suficiente para presentar una apelación y recibir una decisión antes del lanzamiento de la Protección de IP en el modo Incógnito de Chrome estable. Puedes encontrar más detalles sobre el proceso de apelación aquí. |
| Lista de dominios enmascarados | Comentarios en los que los publicadores investigan las implicaciones de que sus socios se incluyan en el MDL Se tranquilizó con las disposiciones de GeoIP en la explicación de la Protección de IP. | Chrome reconoce la importancia de admitir casos de uso basados en la ubicación geográfica. El proxy asignará direcciones IP que representen la ubicación aproximada del usuario, incluido el país. Puedes encontrar más información en la explicación de la geolocalización de IP. |
| Lista de dominios enmascarados | Pregunta sobre la MDL si la segmentación a nivel del país aún está disponible. | Chrome reconoce la importancia de admitir casos de uso basados en la ubicación geográfica. El proxy asignará direcciones IP que representen la ubicación aproximada del usuario, incluido el país. Puedes encontrar más información en la explicación de la geolocalización de IP. |
| Detección de fraudes | Preocupaciones sobre el impacto de la protección de IP en los sistemas de detección de fraudes ¿Los usuarios verán las IP de proxy o un encabezado? ¿Las SSP y las DSP verán la misma dirección IP de proxy para un uso determinado? Las inconsistencias podrían afectar la detección de fraudes y OpenRTB. | Los usuarios que naveguen en modo Incógnito con la Protección de IP habilitada y que realicen solicitudes a dominios del MDL recibirán una dirección IP de proxy según un geofeed definido. Las organizaciones pueden solicitar que los PRT se pasen como un encabezado adicional en el tráfico con proxy, en el que se puede revelar una pequeña muestra de las IP originales después de un período de demora. Sospechamos que muchas SSPs pasarán su dirección IP con proxy en las solicitudes de oferta del servidor a sus socios de demanda, pero no se garantiza que las DSP ganadoras vean la misma dirección IP de proxy en el momento de la impresión. |
| Detección de fraudes | Preguntas sobre la frecuencia de actualización del archivo de ubicación geográfica de IP, los tiempos de actualización para obtener detalles sobre cómo informar comportamientos fraudulentos y PRT, y cómo la tecnología publicitaria debe detectar actividades fraudulentas. | La explicación de los PRT está publicada, al igual que la lista de direcciones IP de proxy y sus regiones geográficas asignadas. Te recomendamos que revises este archivo periódicamente para ver si hay actualizaciones y cambios, ya que las direcciones IP rotarán con el tiempo. La dirección de correo electrónico pública para denunciar abusos se anunciará más cerca del lanzamiento. |
| Ubicación geográfica | Solicitud de una lista pública de direcciones IP que se usan para los proxies | El archivo que asigna direcciones IP a ubicaciones aproximadas para la protección de IP está disponible aquí. Ten en cuenta que este archivo se actualiza periódicamente. |
| Uso de API | Afirmación de que IP Protection parece estar activada de forma predeterminada y que los usuarios no tienen la opción de inhabilitarla. | La Protección de IP estará disponible para los usuarios en el modo Incógnito de Chrome, en plataformas para computadoras y Android. Los usuarios podrán inhabilitar la Protección de IP. En el caso de las versiones de Chrome administradas por empresas, se puede habilitar la Protección de IP, pero estará desactivada de forma predeterminada. |
| Uso de API | Consulta sobre la disponibilidad de una marca de experimento para habilitar y probar la Protección de IP en las versiones beta y Canary de Chrome. | Actualmente, no tenemos una marca de experimento disponible para probar la función completa de Protección de IP. Los experimentos funcionales que llevamos a cabo solo incluyen tráfico de proxy que se dirige a dominios de Google. |
| Privacidad de las direcciones IP | ¿Cómo funciona la configuración de la solicitud de 3PC cuando un navegador pasa al modo Incógnito? | Los 3PC se bloquean de forma predeterminada en el modo Incógnito. |
| Modo Incógnito | Se solicita aclaración sobre si la Protección de IP funciona en el modo Incógnito cuando el usuario no accedió a Chrome. | La Protección de IP no está activa si el usuario no accedió a Chrome antes de iniciar el modo Incógnito. Los motivos son para evitar fraudes y abusos, en particular, limitar la frecuencia de acceso a los proxies. La Protección de IP usará la autenticación de cliente para limitar la capacidad de las personas que actúan de mala fe de aprovechar los proxies para amplificar los ataques a los servicios en la MDL. Por lo tanto, la Protección de IP solo estará disponible para los usuarios que se hayan autenticado con la Cuenta de Google con la que accedieron en el navegador Chrome antes de abrir una nueva ventana de incógnito. |
| Modo Incógnito | Solicitudes para evaluar el impacto de la Protección de IP antes del lanzamiento, incluidas las siguientes: (1) Propuesta para usar una marca de estado del navegador o informes de API agregados para cuantificar el uso del modo Incógnito (2) Enviar un encabezado de Protección de IP durante un período antes de habilitar la función (3) Enviar la función a un porcentaje pequeño y conocido del tráfico para la extrapolación |
Comprendemos el interés del ecosistema en poder comprender y medir la escala y el impacto de la protección de la propiedad intelectual. Sin embargo, Chrome trabaja para que la elección de un usuario de navegar en modo Incógnito sea privada. Chrome no expone un método para detectar a los usuarios que navegan en modo Incógnito y tomó medidas para limitar otros indicadores que podrían revelar el modo de navegación del usuario. Estamos considerando formas de facilitar estas pruebas sin afectar la privacidad de los usuarios que navegan en modo Incógnito y recibimos con gusto comentarios adicionales del ecosistema. |
Mitigaciones del seguimiento por rebote
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cumplimiento | La falta de voluntad de Google de autorizar el uso de la técnica de mitigación del seguimiento de rebotes (BTM) que cumple con la legislación de protección de datos no tiene fundamento legal y hace que el proceso de apelaciones de la Zona de pruebas de privacidad no tenga sentido. | Como explicamos en nuestro informe de comentarios anterior, el estado de cumplimiento no tiene relación con la aplicación de la BTM, y Google no toma ninguna decisión con respecto al cumplimiento en la implementación de la BTM. En cambio, la BTM, al igual que otras protecciones de la privacidad de Chrome, se enfoca en ampliar el control de los usuarios sobre si se comparten sus datos y cómo se hacen. El proceso de apelaciones administrado por terceros al que se hace referencia en el Informe del segundo y tercer trimestre de la CMA es específico de las áreas en las que Google toma decisiones sobre la inclusión o exclusión de empresas individuales en las listas. |
| Cumplimiento | Discusión sobre cómo los navegadores garantizan el cumplimiento de las acciones con consentimiento legal en el contexto del RGPD, en la que se destacan situaciones en las que los navegadores podrían suprimir acciones (como redireccionamientos o configuración de cookies) a las que los usuarios dieron su consentimiento de forma explícita, lo que genera un conflicto entre el consentimiento legal y la configuración de privacidad del navegador. | El navegador no tiene visibilidad sobre la naturaleza de la relación entre un usuario y un sitio web. Además, con el comportamiento actual de la BTM, ya existen soluciones para que un usuario dé consentimiento explícito para el seguimiento de rebotes desde un sitio determinado. Obtén más información sobre el cumplimiento en nuestras Preguntas frecuentes sobre el cumplimiento relacionado con la privacidad. |
| Sitios de doble uso | ¿Quieres obtener más información sobre si las transiciones de WebView o de app a Web (Chrome) se considerarán "sitios de doble uso" en BTM? | El navegador no tiene visibilidad sobre si comenzó una cadena de rebote a través de una transición de WebView o de la aplicación. Por lo tanto, la BTM no les brinda a esos flujos ningún tratamiento especial. En su lugar, interpreta el flujo como un rebote entre sitios que comienza en "about:blank" y continúa con el comportamiento estándar. |
Fortalecimiento de los límites de la privacidad entre sitios
Conjuntos de sitios web relacionados (anteriormente, Conjuntos propios)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Uso de API | Preocupaciones sobre el posible abuso de RWS junto con la protección de IP Exponer las direcciones IP a las organizaciones dentro de un conjunto de RWS podría incentivar a las organizaciones a unirse a varios conjuntos de RWS para obtener acceso a los datos de direcciones IP portátiles y hacer un seguimiento de los usuarios de Incógnito. | Los requisitos establecidos para los sitios asociados, los sitios de servicio y los conjuntos en su totalidad, que se aplican mediante validaciones automatizadas, mitigan cualquier incentivo potencial para intentar unirse a varios conjuntos. Unir la actividad del usuario en varios conjuntos a través de direcciones IP requeriría la inclusión de un dominio de MDL en un conjunto, lo que requiere coordinación entre el propietario del conjunto y el propietario del dominio. Este mismo riesgo se aplica a los sitios individuales (es decir, sin RWS) que se coordinan con dominios de MDL. Respondimos esta pregunta con más detalle aquí. |
API de Fenced Frames
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Publicidad nativa | Comentarios que indican que los marcos delimitados, tal como están diseñados actualmente, son incompatibles con su modelo de negocio de publicidad nativa, que requiere que los anuncios se adapten de forma flexible al contenido circundante. | Seguimos evaluando las necesidades del ecosistema y la oferta actual de marcos delimitados. En cualquier caso, como se indicó anteriormente, los marcos delimitados serán obligatorios a partir de 2026. |
API de Shared Storage
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Error de la API | Se informa que Chrome registra un error cuando el mecanismo de asignación de la API de Shared Storage evita que se ejecute la operación selectURL, aunque este es un comportamiento esperado. Solicita que Chrome cambie el nivel de registro de error a advertencia o información, ya que el llamador no puede realizar acciones en función del error. | El cambio se implementó y se incluyó en Chrome M134, disponible desde el 4 de marzo de 2025. |
CHIPS
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Documentación de la API | Se necesita una aclaración sobre las protecciones de seguridad que ofrecen las cookies particionadas en comparación con las cookies SameSite=Lax/Strict. Se sugiere que la documentación indique explícitamente que las cookies particionadas no proporcionan el mismo nivel de protección contra los ataques XSS y CSRF que las cookies SameSite=Lax/Strict. | Actualizaremos la explicación y la especificación para aclarar la semántica y las protecciones que ofrecen las cookies particionadas. |
FedCM
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| IU y seguridad | Comentarios sobre la IU de FedCM que es demasiado similar al acceso con un clic anterior de Google, es difícil cuantificar el rendimiento de FedCM debido a la falta de seguimiento de presentación pasivo y una recomendación para un lenguaje de documentación más sólido en relación con PKCE. | Estamos trabajando de forma activa con las partes interesadas para abordar sus comentarios. Entre las áreas de debate en curso, se incluyen formas de proporcionar mejores métricas a los proveedores de identidades para permitirles hacer un seguimiento del rendimiento de FedCM y posibles mejoras para abordar nuevos casos de uso de FedCM en torno a casos de uso de suscripción. |
| Uso de API | Cuando un usuario actualiza la página y llama a navigator.credentials.get para acceder, aparece una ventana emergente que le solicita que haga clic para continuar, lo que genera una demora que afecta la experiencia del usuario. ¿Los terceros de confianza (RP) pueden almacenar en caché el token que devuelve navigator.credentials.get para mejorar la experiencia del usuario? | Los RP pueden usar sus propias cookies para almacenar el token. Luego, los RP pueden verificar sus propias cookies para determinar si un usuario accedió antes de invocar navigator.credentials.get. Aquí, abordamos este tema con más detalle. |
| Selección de varios IDps | ¿Cómo mostraría el navegador las opciones de acceso para varios proveedores de identidad (IdP) en FedCM? | La documentación para desarrolladores incluye información sobre cómo se mostrarán varios proveedores de identidad. Las partes interesadas pueden experimentar con esta funcionalidad habilitando la marca fedcm-multi-idp en chrome://flags. |
| Navegadores y proveedores de identidad | ¿Es posible que un navegador, como Chrome, actúe como una AC? Los navegadores podrían usar sus datos de cuenta y perfil almacenados como una fuente de autenticación de confianza. | Debido a que los navegadores se pueden modificar (p.ej., a través de extensiones), no se puede confiar en ningún reclamo de verificación de correo electrónico que realice directamente el navegador sin una verificación adicional basada en el servidor. Por lo tanto, no se recomienda una solución basada únicamente en el cliente. Analizamos este problema con más detalle aquí. |
| Especificaciones de API | Discusión sobre si el parámetro del algoritmo IdentityCredential.disconnect() debe ser obligatorio o opcional. | Ya se corrigió ese error. Puedes obtener más detalles aquí. |
| Seguridad de API | Preocupaciones sobre la filtración de tokens en el proceso de acceso de FedCM si un RP tiene una vulnerabilidad de XSS Un atacante podría ejecutar navigator.credentials.get en código malicioso para obtener el token. | FedCM no crea riesgos de XSS nuevos; estos riesgos son inherentes a las aplicaciones web y a los protocolos de autenticación existentes. Para mitigar estos riesgos, los RP deben verificar el reclamo de aud en los tokens de ID y solo aceptar aserciones emitidas en su propio origen. Como se explica aquí, existen prácticas recomendadas ampliamente establecidas para proteger este intercambio de tokens que existen en la actualidad y están disponibles para su uso con FedCM. Además, la API de Storage Access se puede usar con FedCM, y las llamadas a la API de Storage Access se otorgan automáticamente cuando hay una llamada previa a FedCM. Esto debería habilitar el flujo de redireccionamiento incorporado que se analiza en el problema de GitHub. |
| Especificaciones de API | client_metadata_endpoint es un campo obligatorio en la respuesta del extremo de configuración de FedCM. Un objeto vacío es una respuesta válida, y Chromium ignora de forma silenciosa una respuesta 404, lo que sugiere que el extremo se considera opcional en la práctica. | Aceptamos que se podría cambiar la especificación para reflejar esto y hacer que client_metadata_endpoint sea un campo opcional. |
| Uso de API | Inquietudes sobre la dificultad de probar implementaciones de FedCM debido a las interfaces de usuario controladas por el navegador a las que no se puede acceder a través del DOM. | Admitimos las APIs de automatización del navegador para las pruebas de regresión, que pueden abordar estas inquietudes. Estas APIs se documentan aquí. |
| Especificaciones de API | El parámetro login_url, que es una parte obligatoria de la respuesta del extremo de configuración, no se documentó en el artículo 3.2 de la especificación. | Enviamos una actualización a la documentación para incluir el parámetro login_url en el artículo 3.2. |
| Especificación de la API | Inquietud por un posible vector de seguimiento en FedCM. Un IdP podría insertar IDs como parámetros de ruta en los extremos especificados en la respuesta del extremo de configuración (accounts_endpoint, client_metadata_endpoint) y usar estos IDs para correlacionar las solicitudes de metadatos de la cuenta y del cliente. | Si bien no tenemos evidencia de que las IdP inserten IDs en estos extremos, estamos considerando activamente las mitigaciones para abordar este problema aquí. |
Lucha contra el spam y el fraude
API de Private State Tokens (y otras APIs)
No se recibieron comentarios este trimestre.