Informe trimestral del segundo y tercer trimestre de 2024 que resume los comentarios del ecosistema recibidos sobre las propuestas de Privacy Sandbox y la respuesta de Chrome.
Como parte de sus compromisos con la CMA, Google acordó proporcionar públicamente informes trimestrales sobre el proceso de participación de las partes interesadas para sus propuestas de Privacy Sandbox (consulta los párrafos 12 y 17(c)(ii) de los Compromisos). El 22 de julio de 2024, Google anunció que no daría de baja las cookies de terceros (3PC) en Chrome y, en su lugar, propuso implementar un enfoque actualizado para mejorar la elección del usuario. Por lo tanto, con el acuerdo de la CMA, Google no envió un informe público del segundo trimestre de 2024 a la CMA para permitir que Google y la CMA tuvieran tiempo suficiente para considerar las implicaciones del anuncio de Google.
Estos informes de resumen de comentarios de Privacy Sandbox se generan a partir de la agregación de los comentarios que recibe Chrome de las diversas fuentes que se indican en la descripción general de los comentarios, incluidos, sin limitaciones, los problemas de GitHub, el formulario de comentarios disponible en privacysandbox.com, las reuniones con las partes interesadas de la industria y los foros de estándares web. Chrome recibe con gusto los comentarios que recibe del ecosistema y explora activamente formas de integrar los aprendizajes en las decisiones de diseño.
Los temas de los comentarios se clasifican según su prevalencia por API. Para ello, se agrega la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Los temas comunes de los comentarios se identificaron cuando se revisan los temas de debate de las reuniones públicas (W3C, PatCG, IETF), los comentarios directos, GitHub y las preguntas frecuentes que se presentan en los equipos internos y los formularios públicos de Google.
Más específicamente, se revisaron los actas de las reuniones de los organismos de estándares web y, para los comentarios directos, se consideraron los registros de Google de las reuniones 1:1 con las partes interesadas, los correos electrónicos recibidos por ingenieros individuales, la lista de distribución de la API y el formulario de comentarios público. Luego, Google coordinó entre los equipos involucrados en estas diversas actividades de divulgación para determinar la prevalencia relativa de los temas que surgieron en relación con cada API.
Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de las preguntas frecuentes publicadas, las respuestas reales a los problemas planteados por las partes interesadas y la determinación de una posición específica para los fines de este ejercicio de informes públicos. A raíz del enfoque actual del desarrollo y las pruebas, se recibieron preguntas y comentarios en particular con respecto a las APIs de Topics, Protected Audience y Attribution Reporting.
Es posible que los comentarios recibidos después del final del período de informes actual aún no tengan una respuesta de Chrome.
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
- FPS
- Conjuntos propios
- IAB
- Interactive Advertising Bureau
- IDP
- Proveedor de identidad
- IETF
- Grupo de trabajo de ingeniería de Internet
- IP
- Dirección de protocolo de Internet
- openRTB
- Licitaciones en tiempo real
- TS
- Prueba de Origin
- API de PAT
- API de Protected Audience (antes llamada FLEDGE)
- PatCG
- Grupo de la comunidad de tecnología publicitaria privada
- Acceso al
- Grupo de confianza
- RWS
- Conjuntos de sitios web relacionados (anteriormente, Conjuntos propios)
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable
- UA
- Cadena de usuario-agente
- UA y Suiza
- Sugerencias de clientes de usuario-agente
- W3C
- World Wide Web Consortium
- WIPB
- Ceguera involuntaria de IP
Comentarios generales, sin API ni tecnología específicas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Baja de las cookies de terceros (3PCD) | ¿Cuáles son los planes de Google para la 3PCD? ¿Se evaluaron los efectos a largo plazo en la industria de la publicidad digital? | Proponemos un enfoque actualizado que mejore las opciones de los usuarios. Como se indica aquí, en lugar de dar de baja las cookies de terceros, presentaremos una nueva experiencia en Chrome que permitirá a las personas tomar una decisión informada que se aplique a toda su navegación web, y podrán ajustar esa decisión en cualquier momento. Estamos analizando esta nueva ruta con los organismos reguladores y nos comunicaremos con la industria antes de lanzarla. |
| Elección del usuario | El anuncio de la elección del usuario ha impactado en el interés del ecosistema por adoptar soluciones de Privacy Sandbox. Los comentarios sobre el anuncio de elección del usuario son variados, incluidas solicitudes de funciones como capacidades de supervisión. | Con el enfoque actualizado que prioriza la elección del usuario, sigue siendo importante que los desarrolladores tengan alternativas que mejoren la privacidad en lugar de los identificadores entre sitios. Si bien aún no tenemos detalles para compartir sobre cómo será la nueva experiencia, esperamos un aumento significativo del tráfico sin cookies en Chrome. Esto significa que las APIs de Privacy Sandbox siguen siendo fundamentales para las empresas. Seguiremos invirtiendo en las tecnologías de Privacy Sandbox para mejorar aún más la privacidad y la utilidad. |
| IU de elección del usuario | Preguntas sobre el cronograma de las funciones de inhabilitación o consentimiento, el tipo de opción para el usuario que se está considerando y cómo la IU afectará los entornos de pruebas automatizadas. | Por el momento, no tenemos actualizaciones sobre los plazos. Una vez que decidimos no implementar 3PCD, quisimos proporcionar una actualización al ecosistema lo antes posible. Compartiremos una actualización sobre el cronograma para que los usuarios elijan en cuanto tengamos una. |
| Prueba de Chrome | Solicitud de disponibilidad continua de las etiquetas de prueba facilitadas por Chrome para medir la adopción del mercado y el impacto económico de los 3PCD después del primer semestre de 2024. | Sabemos que los verificadores querrán seguir usando grupos de navegadores etiquetados para las pruebas y la coordinación, incluso cuando finalicen las pruebas facilitadas por Chrome del 1ᵉʳ semestre de 2024. Estamos evaluando los próximos pasos para las etiquetas teniendo en cuenta el anuncio sobre la elección del usuario. Mientras tanto, el equipo de Chrome publicó un intención de extender la compatibilidad para los grupos de navegadores etiquetados hasta el hito 132 de Chrome, que finaliza en enero de 2025. |
| Privacy Sandbox en Android | Privacy Sandbox en Android y Privacy Sandbox en Chrome están vinculados de forma indisoluble, y no podemos evaluar correctamente Privacy Sandbox sin Android. El recorrido típico del cliente, que incluye aspectos multidispositivo y multitáctil, es fundamental para Privacy Sandbox en Chrome y Privacy Sandbox en Android. | Ten en cuenta que Privacy Sandbox en Android no está dentro del alcance de los compromisos de Google con la CMA. Si los comentarios son específicos de los cronogramas y el lanzamiento de Android, no tenemos novedades que compartir en este momento, salvo que seguimos avanzando en Android, que consideramos un flujo de trabajo independiente para mejorar la privacidad. Como señalamos anteriormente, la disponibilidad de las APIs de Privacy Sandbox en Android también dependerá de la velocidad a la que los usuarios actualicen sus dispositivos, lo que no está bajo el control de Google. |
| Tráfico limitado del modo B | El tráfico de subasta de anuncios disponible en el modo B fue menor de lo esperado. | Existen varios motivos por los que los volúmenes de subastas de la API de Protected Audience (API de PA) podrían ser más bajos de lo esperado, por ejemplo: - Las empresas que conocemos que integraron la API de PA solo incluyeron formatos de banner. - Es posible que las plataformas orientadas a la venta no siempre inicien una subasta. - Es posible que un navegador no tenga grupos de intereses (IG). - Es posible que no haya ofertas. Sin embargo, no tenemos conocimiento de nadie que haya intentado probar la API de PA y no haya recibido tráfico. |
| Visibilidad de interrupciones | Visibilidad de las interrupciones y los problemas que afectan a las APIs de Privacy Sandbox | Hay una página de estado pública para las APIs de Privacy Sandbox que tienen servicios fuera del navegador. El equipo de Chrome otorga la máxima prioridad a la confiabilidad de nuestra plataforma y a todas las APIs esenciales que usan los sitios y servicios principales de la Web, incluidas las tecnologías de Privacy Sandbox. Hasta el momento, solo hubo una interrupción. Se relacionaba con una configuración temporal para pruebas del 1%. Pronto ya no se necesitará la configuración experimental involucrada en esta interrupción, por lo que estamos seguros de que este problema no ocurrirá una vez que las APIs se habiliten de la manera normal en Chrome. |
| Estudio del gráfico de cookies | ¿Cuál es la perspectiva de Chrome sobre el método CookieGraph, como se describe en este informe, dentro del marco de trabajo de Privacy Sandbox? | El documento plantea algunos puntos interesantes sobre la detección y la prevalencia de las cookies propias (1P) establecidas por dominios diferentes del que visita el usuario. Como se señala en el artículo, estas cookies son extremadamente útiles para recopilar estadísticas y datos sobre cómo interactúan los usuarios con un sitio web. Estos datos son fundamentales para que los desarrolladores brinden a los usuarios una mejor experiencia de navegación. El argumento principal del artículo es defectuoso, ya que considera que las cookies propias son un vector de seguimiento entre sitios. Sin embargo, esto solo ocurre si se tienen en cuenta las suposiciones muy agresivas que se describen en el documento:
Ten en cuenta que estos son vectores de reidentificación que se pueden explotar sin utilizar cookies propias (por ejemplo, a través del uso compartido de datos del servidor) y deben abordarse por separado de nuestro esfuerzo actual, que se enfoca en mecanismos de seguimiento basados en el estado, como las 3PC. Por último, queremos señalar que el documento equipara las cookies publicitarias y de estadísticas con las cookies de seguimiento, y las cookies estrictamente necesarias con las cookies que no realizan seguimiento, lo que no siempre es el caso. De hecho, los servicios de estadísticas propias o de proveedores particionados en el sitio, como los widgets de localizador de tiendas, los widgets de chat o las cookies del balanceador de cargas, a menudo pueden limitarse a un solo dominio. Por el contrario, algunas cookies estrictamente necesarias pueden ser el seguimiento entre sitios con fines antifraude. |
| Cambios en la UX | Los cambios en la UX en Chrome 112 que colocan controles de cookies propias en la sección "Datos de sitios en el dispositivo" de la configuración de Chrome podrían dificultar que los usuarios bloqueen todas las cookies. | Este cambio se realizó como parte de un esfuerzo por separar y elevar los controles de las 3PC (o almacenamiento no particionado) de todos los demás tipos de datos de sitios. Los controles de cookies de terceros se encuentran en el panel Privacidad y seguridad, mientras que los controles de cookies propias y de todos los demás tipos de datos de sitios (de los que suelen depender las funciones críticas del sitio) se agrupan en "Datos de sitios en el dispositivo". Seguiremos supervisando los comentarios sobre este tema, pero creemos que la separación actual logra un buen equilibrio entre la visibilidad de controles de privacidad significativos y la preservación de una experiencia de navegación funcional. |
| Facturación y pagos | Las facturaciones y los pagos no se están probando por completo, ya que los verificadores están más comprometidos con probar otras áreas de las APIs de Privacy Sandbox. | Los desarrolladores y las empresas pueden elegir cuándo y qué probar. Las APIs están disponibles de forma general para pruebas desde septiembre de 2023. |
| Prueba | No todo el tráfico experimental que las DSP reciben de las SSP está etiquetado. Algunas DSPs informaron que la proporción de impresiones experimentales sin etiqueta puede ser diferente entre los grupos de tratamiento y control. | Chrome no puede controlar si las empresas reenvían etiquetas en las solicitudes de oferta. Proporcionamos un método para obtener una etiqueta del navegador. Depende del ecosistema pasar las etiquetas a los socios si estos no pueden leerlas directamente. |
| 3PCD en WebView de Android | Solicitud de orientación para habilitar la marca "Test Third Party Cookie Phaseout" en Android WebView para probar la baja. | Las cookies de terceros se bloquean de forma predeterminada en WebView de Android. |
| Privacidad diferencial para mitigar los riesgos en el entrenamiento de modelos | ¿Por qué se usa la privacidad diferencial en el entrenamiento de modelos? | La privacidad diferencial, combinada con los entornos de ejecución confiables (TEE), es esencial en el entrenamiento de modelos para evitar la filtración de datos y proteger la información sensible contra amenazas. Este enfoque garantiza que los pesos del modelo no revelen datos individuales del usuario. |
Inscripción y certificación
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Inscripción | Solicitar aclaración sobre cómo funciona la inscripción de certificación entre el origen inscrito y el origen de la tecnología publicitaria con el subdominio www | La tecnología publicitaria solo deberá integrarse en https://example.com. Cuando coloca su certificación en https://example.com/.well-known/privacy-sandbox-attestations.json, la https://www.example.com queda cubierta, ya que es un subdominio. |
| Especificaciones de API | Se sugiere agregar un esquema JSON para el archivo de certificación en el repositorio. | Estamos evaluando esta sugerencia y recibimos comentarios adicionales aquí. |
Muestra anuncios y contenido relevantes
Temas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Ponderación de temas | Lo más importante que debes comprender en Temas es la rareza de un indicador determinado. El diseño actual debe evolucionar para permitir agregar un valor de peso junto a cada tema observado. El peso sería el peso relativo de un tema determinado para un navegador en comparación con todos los navegadores que usan el tema. | Queremos comprender mejor por qué la rareza de una señal es la señal más importante. Aceptamos comentarios adicionales del ecosistema sobre la utilidad de este caso de uso aquí. |
| Confiabilidad de Topics | Google necesita proporcionar garantías más sólidas en torno a la confiabilidad de Topics a lo largo del tiempo. | Los cambios en nuestras APIs se seguirán realizando en función de los comentarios del ecosistema y se analizarán públicamente antes de que se implementen. Nuestra propuesta de una estructura de gobernanza revisada proporcionaría garantías adicionales. |
| Clasificador | Los sitios de los publicadores suelen clasificarse de forma incorrecta o se les asignan temas demasiado generales para que cumplan con algún propósito significativo. | Como se explica en nuestra explicación sobre la clasificación de temas, los sitios se clasifican mediante una combinación de una lista de anulación seleccionada por humanos, que contiene los sitios más populares, y un modelo de aprendizaje automático integrado en el dispositivo. Chrome sigue evaluando opciones para que los sitios contribuyan a la clasificación de temas. Cualquier mejora de utilidad debe sopesarse con los riesgos de privacidad y abuso. Por ejemplo, algunos de los riesgos incluyen los siguientes: - sitios que usan el autoetiquetado como método para codificar diferentes significados (y potencialmente sensibles) en los temas; y - sitios que atacan temas para reducir su utilidad para otros (p.ej., enviar spam a los temas del usuario con ruido sin sentido). El público puede inspeccionar estos componentes, con herramientas disponibles a través de chrome://topics-internals o esta colaboración. Con las pruebas, esperamos que la clasificación mejore con el tiempo y recibimos con gusto comentarios con ejemplos de sitios que podrían estar mal categorizados. |
| Pregunta sobre la API | Se cuestiona que la API de Topics brinde beneficios persistentes y anticompetitivos a las SSP que monetizan contenido de mala calidad. | Al igual que con las cookies de terceros, el navegador es independiente de a quién le muestra Topics, siempre que esa entidad esté inscrita y certificada. |
| (También se informa en trimestres anteriores) Utilidad para diferentes tipos de partes interesadas |
Debido a que, actualmente, el clasificador de temas solo usa el nombre de host de la página para definir los temas correspondientes, los sitios grandes con contenido diverso contribuyen con temas genéricos, mientras que los sitios pequeños contribuyen con temas de nicho con más valor publicitario. | Nuestra respuesta es similar a la de trimestres anteriores: Al igual que con los 3PC, hay una diferencia en el valor de la información que aportan los diferentes sitios. Los sitios de interés nicho son inconsistentes en su contribución de valor: no todos los sitios de interés nicho tienen un contexto comercialmente valioso y, por lo tanto, aportan menos valor. Estos son los sitios que se beneficiarán de la API de Topics. Consideramos la posibilidad de realizar clasificaciones a nivel de la página en lugar de a nivel del sitio. Sin embargo, existen varias inquietudes importantes de privacidad y seguridad con esa clasificación. |
| Clasificador | A menudo, a los sitios más pequeños se les asigna una clasificación imprecisa o ninguna clasificación para que no puedan participar en el intercambio de valor. | Con respecto al presunto daño, esto no perjudica a sitios específicos que posiblemente estén mal clasificados que otros sitios, ya que la información contextual de un sitio siempre estará disponible para subastas en su sitio, lo que proporcionaría información comparable con el tema correcto, incluso en el caso de una clasificación errónea. Por lo general, los temas se usan para recopilar información publicitaria potencialmente útil de sitios web externos, en lugar de hacerlo en sus propios sitios. |
| Versión de la taxonomía | ¿Cómo podemos acceder a la versión de la taxonomía para garantizar la retrocompatibilidad? | La versión de la taxonomía forma parte del encabezado de solicitud que se envía con una solicitud de recuperación habilitada para temas. Por ejemplo, si el encabezado es "(1 2);v=chrome.1:2:5, ();p=P000000000", la versión es chrome.1:1:2. En el que chrome.1 es la versión de configuración, 2 es la versión de taxonomía y 5 es la versión del modelo. Esto se describe en la especificación y también se agregó a la explicación. |
| Datos de Topics | Solicitar aclaración sobre cómo se actualizan los datos de Topics | No se especifica la actualización de la taxonomía. Esto les brinda a los proveedores de navegadores flexibilidad en la implementación. Dicho esto, estas son las heurísticas de la actualización de la taxonomía de Chrome de la versión 1 a la 2: - Se mantiene un solo árbol de taxonomía para los temas de la versión 1 y la 2. - El mismo ID de tema representa el mismo significado. - El árbol solo crece, ya que se agregan temas o conexiones nuevos, y nunca se reduce. - Sin embargo, algunos temas o vínculos podrían estar "inactivos" en una versión, lo que podría dar la impresión de que se borraron o reorganizaron. Ejemplos: - "Pickup Trucks" ahora tiene "Trucks, Vans & SUVs" como categoría superior intermedia. - “Estudio de idiomas extranjeros” ahora tiene la opción “Educación” como segundo padre o madre, y la versión superior original, “Referencia”, está inactiva. Impacto de los temas "inactivos": Estos temas no se usarán para la clasificación nueva. Sin embargo, se siguen teniendo en cuenta cuando se aplican bloqueos de usuarios: si un usuario bloqueó un tema en la V1, sus temas secundarios permanecerán bloqueados en la V2 (incluso si el tema secundario aparece en un elemento superior diferente en la V2). |
| Clasificador | Buscar comprender las causas y las opciones de corrección disponibles en relación con las clasificaciones erróneas | En primer lugar, nos gustaría señalar que la determinación de Chrome sobre los temas de un sitio solamente se usa como entrada en el algoritmo de Topics para determinar los intereses de un usuario con fines publicitarios. No se desarrolló para otros fines de clasificación más generales. Nos interesa la exactitud general de nuestro modelo de clasificación, por lo que intentamos mejorar su precisión/recuperación siempre que sea posible, pero a nivel global en lugar de a nivel de clasificación de sitios individuales. Esto se debe a que, cuando ocurre, la clasificación incorrecta no perjudica al sitio individual que se clasificó de forma incorrecta, sino que reduce la calidad del indicador de Topics cuando se selecciona un anuncio en otros sitios. Cuando seleccionas anuncios en el sitio que clasificaste de forma incorrecta, el sitio ya conoce los temas reales del sitio y estos pueden usarse como entrada para las búsquedas publicitarias. Agradeceremos recibir comentarios adicionales aquí. |
| Pruebas de la API | ¿Topics y, en general, las APIs de Privacy Sandbox se pueden probar con Chromium? | La API de Topics no se envía con Chromium, sino con Chrome. |
| Emisor de temas | Solicitud para mejorar el valor agregado de Topics aprovechando los servicios de TEE para que las tecnologías publicitarias admitan el costo del análisis avanzado de formas que cumplan con la privacidad. | Respondimos a comentarios similares aquí. Consideramos la frecuencia inversa y, después de modelarla, descubrimos que no se correlacionaba bien con el valor del tema según el valor proporcionado por los compradores y vendedores. Envíanos tus comentarios adicionales aquí. |
| Especificaciones de la API | ¿La configuración de cohorte de intereses del navegador podría bloquear la API de Topics? | Respondimos a estos comentarios aquí. La API de Topics es una evolución de FLoC y respeta su política de permisos. Como se indica en la explicación: "Nota: La política de permisos anterior: interest-cohort=() de las FLoC también prohibirá el cálculo de temas". |
| Clasificación de temas | Cuando se obtienen los "5 temas principales", ¿se debe registrar la frecuencia de las visitas al sitio web en función de cada llamador apto o siempre en función de todo el historial de visitas del navegador? Además, ¿los temas se clasifican por separado para cada emisor? | Se basa en la frecuencia de un subconjunto de historiales de navegación. Una entrada del historial de navegación (una página) es apta para participar solo si la página tuvo al menos un llamador de Topics. Aquí encontrarás más detalles sobre el almacenamiento del historial de temas. Como se indica en nuestro anuncio sobre las mejoras de la API de Topics, la clasificación depende de la frecuencia y también de un nivel de prioridad binario (consulta aquí y aquí para obtener más detalles). Sin embargo, no depende de la frecuencia de los emisores. Ten en cuenta que esto no significa que todos los emisores puedan obtener los 5 temas principales en la siguiente época. Como se indica en la explicación, "Solo los llamadores que observaron que el usuario visitó un sitio sobre el tema en cuestión en las últimas tres semanas pueden recibir el tema". El navegador debe hacer un seguimiento de qué llamador observó los 5 temas principales (que corresponden a los 5 temas principales con dominios de llamador en la especificación). Agradecemos que nos envíes más comentarios sobre este problema aquí. |
API de Protected Audience (anteriormente, FLEDGE)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informa en trimestres anteriores) Costos |
¿Es más costoso ejecutar TEE en nubes públicas en comparación con los centros de datos de tecnología publicitaria locales? | Nuestro modelo de seguridad de TEE actual se beneficia de las prácticas de las implementaciones de la nube pública (consulta más detalles en la explicación de los requisitos de TEE de la nube pública). Por ejemplo, los TEE actuales basados en hardware no protegen contra todos los ataques físicos. Nuestros proveedores de servicios en la nube pública admitidos, AWS y GCP, diseñaron e implementaron mitigaciones para los riesgos de acceso físico, incluidos los de los empleados. Si bien algunas tecnologías publicitarias nos mencionaron que ejecutar servicios en la nube es más costoso que los centros de datos de tecnología publicitaria local, otras tecnologías publicitarias se ejecutan en nubes públicas, ya sea por costo o por otros beneficios. Seguimos evaluando opciones para expandir nuestra compatibilidad con TEE, incluso fuera de las nubes públicas. Como parte de esto, estamos investigando los centros de datos locales y nos estamos comunicando con el ecosistema para explorar posibles soluciones que nos permitan ofrecer esa asistencia. En esta etapa de la investigación, no podemos garantizar que esto resulte en una solución viable para el ecosistema. |
| API de PA y Google Ad Manager (GAM) | El GAM no puede lograr un resultado de mercado justo. GAM no publica anuncios de forma oportuna, no informa cuántos anuncios publicó con la API de PA y no ofrece la posibilidad de configurar qué método se seleccionará para publicar un anuncio, p.ej., desactivando la API de PA para ciertos espacios. | Respuesta de Google Ad Manager: GAM trabajó y sigue trabajando para optimizar la latencia cuando se publican anuncios a través de la API de PA, de modo que el aumento adicional de los ingresos de los publicadores a partir de la demanda de la API de PA supere cualquier costo incurrido debido a la latencia adicional de la subasta de la API de PA. Nuestras pruebas iniciales indican que los publicadores obtienen un beneficio en ingresos netos con la API de PA en el tráfico sin cookies de terceros, lo que indica que la demanda adicional de la API de PA supera cualquier costo que pueda generar la latencia. Puedes encontrar más detalles sobre nuestro enfoque en nuestras preguntas frecuentes. Además, GAM proporciona a los publicadores informes sobre los anuncios publicados a través de la API de PA. Esto incluye los anuncios que se publican cuando GAM es un vendedor de componentes y los anuncios que se publican a través de otros vendedores de componentes cuando GAM es un vendedor de nivel superior. Puedes encontrar más detalles sobre los avisos en nuestro Centro de ayuda. Por último, GAM permite que los publicadores habiliten o inhabiliten el uso de la API de PA en su tráfico a través de un control en la IU (consulta nuestro Centro de ayuda para obtener más información). Estamos dispuestos a recibir comentarios sobre los controles adicionales que deseen los publicadores, y priorizaremos cualquier solicitud de funciones de acuerdo con nuestro proceso estándar de priorización de funciones. |
| API de PA y GAM/AdX | Parece que Google ha tomado la posición de que simplemente no comprará ninguna impresión de la API de PA de la que GAM no tome la decisión final de venta, al igual que Google Ads solo compra de forma interna. Esto parece ser un abuso de posición de mercado, ya que GAM/AdX podría enviar una configuración de subasta de componentes a un vendedor alternativo de nivel superior como cualquier otro mercado. | Respuesta del administrador de la plataforma de Google Ads: Esa no es la posición de Google. Las plataformas de compra de Google (Google Ads y DV360) sí compran impresiones de mercados de intercambio que no son de Google. Esto es válido para las impresiones de la API de PA y las impresiones de la API que no son de PA. |
| Respuesta del mercado | Preocupaciones de Mozilla: El público protegido de Google protege a los anunciantes (y a Google) más que a ti. | Agradecemos la evaluación de Mozilla y seguiremos participando en los foros de estándares públicos para conocer sus comentarios. Uno de los temas de su evaluación es que la implementación actual de la API de PA aún no aplica todas las protecciones planificadas. Nuestro enfoque de lanzamiento con la API de PA buscó encontrar el equilibrio adecuado entre fomentar la adopción y la implementación de protecciones de la privacidad lo antes posible. Como parte de esto, establecimos un plan para imponer restricciones de privacidad con el tiempo, con el objetivo de facilitar mejor las integraciones con las APIs y darnos tiempo para recopilar más comentarios que podamos incorporar en las protecciones futuras (p.ej., funciones de VAST en marcos delimitados). También agradecemos las comunicaciones más recientes de Mozilla sobre su propio enfoque hacia la privacidad y la publicidad digital: “Una Internet libre y abierta no debería afectar la privacidad” y “Mejorar la publicidad en línea a través del producto y la infraestructura”. |
| (También se informa en trimestres anteriores) Resultados de la subasta |
Solicitud de subasta única para mostrar varias URLs de renderización con su puntuación correspondiente, lo que facilita que la publicidad nativa anule el duplicado y evite problemas de UX y latencia. | Nuestra respuesta es similar a la de trimestres anteriores: Consideramos compartir varias renderURLs y sus respectivas puntuaciones desde una sola subasta de la API de PA, pero no lo implementamos debido a preocupaciones de privacidad. Entendemos tu deseo de evitar mostrar el mismo anuncio varias veces a un usuario en una sola página y estamos evaluando esta solicitud. Agradecemos los comentarios adicionales del ecosistema aquí sobre la asistencia adicional que se necesita en la API de PA para admitir de forma óptima el caso de uso de la publicidad nativa. |
| Rendimiento | Inquietudes sobre la latencia que afecta a la API de PA. | Escuchamos inquietudes sobre la latencia, y esta es una de las razones por las que desarrollamos varias funciones como parte de la API de PA, que permitirán que las SSP establezcan límites en la latencia de la DSP y realicen mejoras que pueden disminuirla. Recientemente, actualizamos nuestra guía de prácticas recomendadas sobre latencia, que incluye más información para aprovechar estas funciones. También seguimos desarrollando nuevas mejoras en la latencia, algunas de las cuales se pueden ver aquí. |
| Vendedores de nivel superior | Google debería permitir que los publicadores elijan vendedores alternativos de subastas de la API de PA de nivel superior. | La API de PA no distingue quién inicia una subasta, ya sea en diseños de un solo vendedor o de varios vendedores. Las empresas individuales son libres de elegir si admiten o no las subastas de la API de PA y cómo hacerlo. |
| (También se informa en trimestres anteriores) Segmentación negativa |
Solicitud de una solución para un caso de uso en el que un anunciante no quiere mostrar anuncios a un público determinado. | Admitimos la segmentación negativa de IG a través de ofertas adicionales (contextuales), lo que resuelve las necesidades de un anunciante que no desea mostrar anuncios a un público determinado. Puedes encontrar los detalles en esta explicación y en este problema de GitHub. También estamos explorando soluciones para admitir la segmentación negativa de IG en las ofertas de la API de PA y recibimos comentarios adicionales aquí. |
| (También se informó en trimestres anteriores) Publicidad nativa |
Solicitud de compatibilidad con el marco de límite para la publicidad nativa | Estamos considerando admitir este caso de uso y estamos analizando posibles soluciones y alternativas aquí. |
| WebView | Se solicita aclaración sobre la situación en la que IG se unió a Chrome y no estaba disponible para la subasta ejecutada en WebView. | Queremos admitir estos casos de uso una vez que haya suficiente infraestructura de privacidad disponible. Por el momento, no tenemos más anuncios, pero recibimos con gusto comentarios adicionales aquí. |
| IG negativos | Solicitud para el procesamiento de updateURL para admitir IG negativos a través de la función de encabezado emergente. | Estamos evaluando esta solicitud y aceptamos comentarios adicionales aquí. |
| Filtrado de diversidad | Solicitud de orientación para implementar el filtrado de diversidad cuando se publica publicidad nativa en la API de PA con varios vendedores y varias subastas. | Estamos analizando esta solicitud aquí y agradecemos que nos envíes comentarios adicionales. |
| (También se informa en trimestres anteriores) Filtros de bloqueo |
Solicitud de orientación para aplicar las reglas de "bloqueo de publicador" (filtros) cuando se publica publicidad nativa en la API de PA con varios vendedores. | Compartimos información sobre el tema aquí y recibimos con gusto más comentarios. |
| Restricciones | Solicita permitir restricciones a nivel de dominio en lugar de a nivel de subdominio. | Las restricciones a nivel de origen o subdominio siguen el modelo de seguridad básico de la Web, por lo que ese es nuestro diseño predeterminado. Analizamos este tema con más detalle aquí y aquí. |
| Ofertas de confianza | Solicitud de usuario-agente y sugerencias de cliente relacionadas en solicitudes de indicadores de ofertas de confianza | Estamos haciendo un seguimiento de esta solicitud de función y recibimos con gusto más comentarios aquí. |
| (También se informa en trimestres anteriores) Múltiples IG |
Usar varios IG en la misma oferta | Actualmente, esto no es compatible con la API de PA, ya que provocaría un cambio en el modelo de privacidad subyacente. Te invitamos a que participes en la conversación aquí. |
| (También se informa en trimestres anteriores) Rendimiento |
Incluir más lógica en el cliente puede dañar el rendimiento de la página y la UX, lo que podría perjudicar las puntuaciones de SEO del sitio web. | Estamos analizando este problema y recibimos con gusto más comentarios aquí. |
| Dinámica de las subastas | La API de PA reduce la información sobre las dinámicas de subasta (p.ej., quién participa, quién gana cada componente subastado, etc.), lo que reduce la trazabilidad de los publicadores y dificulta saber si se están cumpliendo los acuerdos. | Aquí, propusimos una solución para el seguimiento de las ofertas. Planeamos modificar algunos campos existentes y crear algunos nuevos dentro del objeto IG para almacenar DealID y SeatIDs, y permitir que se propaguen de generateBid a scoreAd o salida a través de informes a nivel del evento. Esto debería proporcionar una compatibilidad adecuada para el caso de uso del acuerdo. Agradecemos los comentarios sobre otros metadatos que las tecnologías publicitarias consideran fundamentales para la dinámica de las subastas y para que sigan teniendo esta trazabilidad para los publicadores. Recomendamos a las tecnologías publicitarias que proporcionen ejemplos específicos de los metadatos a los que se refieren y de qué parte a qué parte deben fluir. |
| GAM | Inquietudes sobre el requisito de usar GAM como servidor de anuncios del publicador para acceder a la demanda de AdX. | Respuesta proporcionada por Google Ad Manager: GAM no requiere que los publicadores usen su función de servidor de anuncios para acceder a su función de intercambio. |
| (También se informa en trimestres anteriores) Subasta de componentes |
Los ganadores de la subasta de componentes de la API de PA serán visibles para GAM, lo que genera inquietudes sobre el acceso desigual a la información. | Nuestra respuesta no ha cambiado desde los trimestres anteriores: Respuesta proporcionada por Google Ad Manager: "Durante años, nos hemos enfocado en la equidad de las subastas, incluida nuestra promesa de que no se compartirá con otro comprador 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, 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 proporcionan los compradores a las SSP, como parte de nuestra propia subasta. De hecho, nos complacerían los cambios en la API de PA que permitan a los vendedores de componentes especificar sus configuraciones de subasta de componentes de una manera que no sea visible para el vendedor de nivel superior". |
| GAM | ¿GAM solicitará la distribución de ingresos para ejecutar o informar subastas de nivel superior si GAM no participó en la creación de la subasta de componentes de la API de IG o PA? | Respuesta proporcionada por Google Ad Manager: Cuando los publicadores eligen usar GAM como su servidor de anuncios, GAM ejecutará la subasta de nivel superior y cobrará una tarifa de publicación de anuncios por su funcionalidad de servidor de anuncios (la misma tarifa de publicación de anuncios que se aplica fuera de las subastas de la API de PA). Sin embargo, si el anuncio ganador proviene de un vendedor de componentes que no es de GAM, es decir, que GAM no participó en la creación de subastas de componentes de la API de IG o PA, GAM no administra la facturación y no cobra un porcentaje de tarifa de medios. |
| Clickiness | ¿El registro de los eventos de clic está sujeto a la misma privacidad diferencial? | Actualmente, no se planea que esta función esté sujeta a restricciones de "k-anon", ya que el "registro de clics" solo estará disponible como browserSignal dentro de la función generateBid(); no está disponible como atributo nuevo en los informes a nivel del evento. |
| Rendimiento | Costos de salida altos debido a la respuesta incondicional a las solicitudes de ofertas contextuales. | Debido a cuestiones de privacidad, no podemos proporcionar información directamente sobre qué DSP tienen IG. Sin embargo, estamos explorando soluciones alternativas que podrían proporcionar estadísticas y, al mismo tiempo, preservar la privacidad. |
| Anuncios nativos y outstream | Solicita actualizaciones sobre la perspectiva de Chrome con respecto a los anuncios nativos y outstream. | La posición de Chrome depende del caso de uso en cuestión. Con respecto a las campañas de video, Chrome establece que nuestro trabajo es fomentar la convergencia del ecosistema en soluciones viables de video in-stream con nuestras APIs. Hasta el momento, la única propuesta concreta que conocemos es la propuesta de GAM. En el caso de los anuncios nativos, estamos recopilando comentarios de forma activa aquí y planeamos incorporar pronto más pasos de descubrimiento en las tecnologías publicitarias. |
| Supervisión en tiempo real (RTM) | El tráfico etiquetado no envía informes de RTM. | Estamos al tanto de esta brecha y estamos trabajando para proporcionar una solución. Compartiremos una actualización cuando esté disponible aquí. |
| Compatibilidad con la extensión de público | Solicitud de actualización sobre la compatibilidad de los públicos seleccionados por el vendedor o la extensión de público en la API de PA. | Estamos trabajando para proporcionar una solución a este caso de uso. Estamos recopilando comentarios del ecosistema sobre lo que debemos desarrollar y apoyar. Compartiremos una actualización cuando esté disponible y recibimos comentarios adicionales aquí. |
| Depuración | En la herramienta para desarrolladores de Chrome, no hay un panel para supervisar el rendimiento detallado de la API de PA. Por ejemplo, el rendimiento general podría verse afectado por la cantidad de IG o de compradores. | Si bien estos comentarios específicos se relacionan con las capacidades de la IU de la herramienta para desarrolladores de Chrome para ayudar con la supervisión, el 7 de octubre presentamos la capacidad de las tecnologías publicitarias para configurar eventos personalizados que se pueden usar como base para la supervisión y las alertas. Puedes encontrar más detalles aquí. Esperamos que esta actualización responda a una parte importante de estos comentarios. Envíanos tus comentarios sobre esta función, ya sea que se relacionen con los datos admitidos o la experiencia de los desarrolladores, en la correspondiente conversación de GitHub aquí. |
| Indicadores | Preocupaciones sobre si las DSP pueden garantizar que perBuyerSignals se envíe a las SSP independientemente de los resultados de la subasta contextual. | Se supone que la subasta contextual tiene solo una oferta ganadora de una DSP, o mejor dicho, una oferta para intentar superar con una subasta posterior de la API de PA. En el flujo de la API de PA, la SSP decide invitar a todas las DSP que desee para ver si tienen demanda (en forma de un IG integrado en el dispositivo) para enviar. Es completamente posible y, de hecho, muy probable que una DSP que perdió la subasta contextual se "vuelva a invitar" a participar en la subasta de la API de PA. En esta "reinvitación", la DSP, si decide aceptar, reenviará a la SSP cualquier indicador que el Verificador de anuncios quiera asegurarse de que la DSP tenga en cuenta, si hubiera alguno para esa campaña. En otras palabras, en la subasta de la API de PA, la DSP siempre puede enviar perBuyerSignals a la SSP, sin importar lo que haya transcurrido en la subasta contextual. |
| Indicadores | Solicitud para agregar prevClicks al objeto browserSignals que se pasó a generatedBid(). |
Esta solicitud se puede resolver con nuestra propuesta para admitir indicadores de clics. Anunciamos esta función en nuestra entrada de blog más reciente y en la explicación correspondiente. Agradeceremos que nos envíes más comentarios sobre esta propuesta aquí. |
| (También se informa en trimestres anteriores) Indicadores de modelado |
Solicita aumentar la cantidad de bits de los indicadores de modelado de 12 a 30 bits. | Respondimos a estos comentarios con una contrapropuesta aquí. Estamos interactuando de forma activa con la industria para comprender sus puntos de vista sobre nuestra propuesta y, actualmente, estamos sopesando los beneficios para la industria en función del impacto en los usuarios de Chrome y otras partes interesadas. |
| Documentación | Solicitud de orientación sobre el uso de los servidores de clave-valor (K/V) y los TEE. | La orientación sobre el uso de los TEE en el contexto de K/V está disponible en los detalles del diseño del modelo de confianza del servicio de K/V aquí. |
| Ciclo de vida de IG negativos | Solicitud para extender la vida útil de los IG negativos a 365 días. | Los IG negativos se usan para evitar que se muestren anuncios, pero los usuarios malintencionados pueden usarlos para revelar información sobre los usuarios, lo que genera riesgos de reidentificación (p.ej., una forma en que los usuarios malintencionados pueden atacar es simplemente realizar ofertas altas con IG negativos de forma reiterada para saber si un usuario visitó o no ciertos sitios). Si mantenemos un TTL de 365 días, las personas que actúan de mala fe tendrán muchos más datos sobre los IG negativos, lo que genera riesgos de privacidad significativamente mayores. Por lo tanto, no podemos admitir esta solicitud para proteger la privacidad del usuario. |
| Especificaciones de API | ¿Qué se puede insertar como valores para pasar como parte de perBuyerSignals? ¿Puede el vendedor definirlo de forma arbitraria? | perBuyerSignals es el lugar donde los vendedores brindan a los compradores toda la información que quieren que esté disponible en la subasta. El ecosistema debe decidir qué desea insertar allí, pero nos complace que se inicie una conversación adicional aquí. |
| Susticiones de macros de tamaño del anuncio | Necesito orientación sobre por qué no funcionan los reemplazos de macros de tamaño de anuncio. | Pronto compartiremos más detalles de forma pública. |
| Reemplazo de macro de SSP posterior a la oferta: falsificación de la URL de nivel superior | ¿Qué mecanismos puede implementar Chrome para permitir que los proveedores de verificación verifiquen la URL de nivel superior dentro del marco de Privacy Sandbox? ¿Hay indicadores o datos alternativos que se puedan usar dentro de los marcos vallados para garantizar la precisión de la URL de nivel superior proporcionada por la SSP? |
Actualmente, estamos analizando estos comentarios adicionales aquí. |
| Solicitud de función | Solicitud para proporcionar UACH de baja entropía en recuperaciones de updateURL y en notificaciones de conversión de informes en tiempo real. | Estas solicitudes se están analizando aquí y recibimos comentarios adicionales aquí y aquí. |
| Solicitud de función | Solicitud para que se active el diseño de depuración con consentimiento del servidor de confianza cuando se activa un cliente determinado para enviar informes de nivel de evento forDebuggingOnly con reducción de muestreo a través de forDebuggingOnly.reportAdAuctionWin() y forDebuggingOnly.reportAdAuctionLoss(). |
Esta es una solicitud activa de la que estamos haciendo un seguimiento y proporcionaremos una actualización al ecosistema cuando esté disponible. Recibimos con gusto comentarios adicionales aquí. |
| Uso de API | Solicitud de orientación para contar el alcance de usuarios únicos y el alcance de impresiones | Estamos analizando una propuesta para abordar cómo leer los IG desde una worklet de almacenamiento compartido, en la que podrías enviar informes agregados privados. Puedes obtener más detalles aquí y agradecemos tus comentarios sobre la propuesta y su utilidad para el ecosistema. |
| Uso de API | Falta de claridad sobre lo que los publicadores deben probar, qué APIs son importantes, cuáles se deben activar y qué sucederá en el futuro. | Estamos trabajando para brindar una mejor asistencia a los publicadores y comprender mejor sus roles en el ecosistema. |
| Uso de API | ¿Es posible agregar objetos de escucha de eventos a los eventos de Ad Auction Worklet? | Esto no es posible a través de eventos normales, pero los eventos del protocolo de Herramientas para desarrolladores de Chrome abordarán parcialmente este caso de uso. Ten en cuenta que es probable que los eventos regulares afecten las propiedades de aislamiento o privacidad. Sin embargo, puedes encontrar los detalles aquí. |
| K-Anonimato | Solicitar aclaraciones sobre los requisitos de renderización de anuncios (p. ej., al menos 50 personas habrían visto el anuncio si se hubiera permitido su publicación) | La documentación para desarrolladores proporciona una descripción general de nuestras expectativas para desarrollos futuros. En particular, se explica que el umbral inicial de k-anonimato es k=10 personas. La lista de distribución blink-dev proporciona actualizaciones sobre lo que sucede en vivo en Chrome. Como se indica en la conversación de la lista de distribución de a-anonimato, actualmente aplicamos de forma experimental el requisito de a-anonimato en aproximadamente el 1% del tráfico estable de Chrome y nunca lo aplicamos en las porciones etiquetadas de forma explícita ("Modo A" y "Modo B"). |
| Alfombrado | ¿Se puede quitar o reducir temporalmente el filtrado de K/V de TEE de tener que llamar a todos los fragmentos de N a una cantidad que equilibre la protección de la privacidad con la utilidad (es decir, rendimiento o costo de K/V)? | Estos tipos de solicitudes solo se controlan para instancias que no son de producción en las que se puede controlar el desgaste. Para las instancias de producción, aún se requiere el desbarbado. Podremos evaluar la situación una vez que recibamos comentarios sobre el uso que no es de producción. |
| Desgaste | Solicitud para agregar una marca para inhabilitar el chaffing del objeto binario K/V de depuración/no producción. | Esta marca se proporciona con la versión 1.0.0. |
| Error de la API | La API dejó de funcionar después de actualizar a Chrome 126, a pesar de que estaba habilitada en la configuración. | Se descubrió que este problema estaba relacionado con la marca de Chrome "enable-fenced-frames", que los usuarios habilitaron con fines de desarrollo. Si restableces esta marca a la configuración predeterminada, se resolverá el problema. |
| Informes | Solicitud para que la habilitación de la API de informes en tiempo real no dependa del vendedor para los compradores | Esta solicitud se considera aquí. La solución de RTM se lanzó recientemente y recibimos con gusto los comentarios, en particular, de las tecnologías publicitarias que ya adoptaron la función. |
| Informes | Solicitud de informes de terceros: mientras que las DSP y las SSP reciben notificaciones de impresiones de Chrome, los proveedores técnicos de la capa intermedia no lo hacen de forma predeterminada. | Estamos analizando esta solicitud y agradecemos los comentarios adicionales aquí. |
Servicios de subastas protegidos
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| TEEs | El requisito de Google de integración manual según los estándares técnicos es una restricción importante en la elección del proveedor de servicios en la nube. Los estándares técnicos aplicados se pueden seguir sin una visita al Bureau of Cloud Providers, como parece tener en mente Google. La demora en la implementación de los proveedores alternativos en 2025 (o antes) es inaceptable porque introducirá efectos de red que fomentarán las propinas en las soluciones de Google. | El servicio de agregación es el único que se requiere para ejecutarse en un servicio de TEE para abordar algunos casos de uso de la tecnología publicitaria. El servicio de agregación admite Amazon Web Services (AWS) y Google Cloud Platform (GCP). En función de los comentarios de las tecnologías publicitarias, creemos que esta asistencia es adecuada en esta etapa. En el caso de los proveedores de servicios en la nube adicionales, Google publicó criterios detallados para los TEE en proveedores de servicios en la nube pública. Su objetivo es garantizar que la solución de TEE cumpla con los objetivos de privacidad y seguridad de Privacy Sandbox. Específicamente, los servidores de TEE de Privacy Sandbox procesan datos de usuarios entre sitios sin encriptar (p.ej., datos de los sitios del publicador y del anunciante para el servicio de agregación). Estos deben ser seguros para cumplir con los objetivos de privacidad del usuario de las APIs. Del mismo modo, es necesario contar con un entorno seguro para garantizar que las APIs sigan protegiendo la información comercial confidencial de las empresas (por ejemplo, evitar que otros participantes de la subasta de la API de PA accedan a los datos comerciales de propiedad exclusiva de un comprador). Hasta donde sabemos, actualmente no existe una tecnología de TEE que proteja por completo los datos del usuario de un operador potencialmente adversario. Por lo tanto, incluimos varios requisitos para validar la confiabilidad del proveedor de servicios en la nube. No sabemos a qué se refiere la “Oficina de proveedores de servicios en la nube” y no forma parte de los requisitos. Agradecemos cualquier comentario sobre los requisitos. También seguimos evaluando la compatibilidad con proveedores nuevos, incluso en función de las solicitudes que se envían mediante el proceso definido en la explicación. Hasta el momento, solo recibimos una solicitud para admitir Azure, que estamos evaluando. |
| Bed and breakfast | Es difícil evaluar la complejidad técnica y la viabilidad del servicio de B&A a medida que el diseño sigue evolucionando. | Para abordar estas inquietudes, proporcionamos explicaciones detalladas en GitHub en las que se explica el diseño de B&A, cronogramas de disponibilidad publicados y una hoja de ruta de las funciones compatibles con la API de PA. Brindamos asistencia a las tecnologías publicitarias que buscan implementar la B&A y recopilar comentarios del ecosistema en GitHub. |
| B&A | Busca orientación y una mejor manera de calcular el costo de usar TEE para B&A para comenzar a usarlo o migrar a su uso desde el dispositivo. | Recientemente, publicamos la Guía de tamaño de instancias de servidor K/V, que incluye herramientas para medir los costos con mayor precisión. |
| Servidor K/V | Verificador de anuncios que solicita usar la URL de página completa en el servidor K/V para realizar la verificación del anuncio. | Actualmente, estamos evaluando la posibilidad de proporcionar la URL completa de la página al servidor K/V que se ejecuta en un TEE para la verificación de anuncios. La URL de la página completa no estará disponible en BYOS de K/V. |
| Seguridad de la subasta | Buscar funciones de seguridad de subastas para garantizar que las personas que actúan de mala fe no accedan a datos sensibles o actúen como imitadores: ¿qué funciones protegen la subasta de los ataques de repetición y cómo se pueden implementar las protecciones de seguridad? | El modelo de seguridad actual de B&A puede proteger la integridad de las subastas. B&A se ejecuta en un TEE que protege la confidencialidad de los indicadores y el código de las tecnologías publicitarias de las personas o entidades que actúan de mala fe. En la arquitectura de B&A, una carga útil de solicitud de B&A encriptada (texto cifrado de la solicitud) fluye del cliente a través de un servidor de anuncios no confiable al servicio de SellerFrontEnd (SFE, que ejecutan las SSP en TEE). El texto cifrado de la solicitud contiene un ID de generación basado en una marca de tiempo. El SFE examinará la marca de tiempo de la solicitud y rechazará las solicitudes reproducidas que no se encuentren dentro de un período de +/- n segundos de la hora del servidor. Además, B&A puede mostrar una carga útil de respuesta de tamaño fijo para la comunicación entre servidores. Estas soluciones pueden ayudar a mitigar los ataques de repetición a través del sistema cuando un agente malicioso intenta reproducir la misma carga útil de la solicitud para obtener más información sobre su contenido. B&A está en proceso de documentar y actualizar los modelos de seguridad en los instructivos. |
| Señales a través del servidor K/V de |
Solicitud para incluir perBuyerSignals enviada a través del servicio K/V como parte de la solicitud de indicadores de ofertas de confianza de Chrome. | Estamos evaluando la viabilidad de incluir información de perBuyerSignals, transferida al servidor K/V que se ejecuta en un TEE, incluida la URL de página completa. |
| Servidor K/V | Solicita un cronograma de adopción por fases para las restricciones de privacidad en K/V y B&A. | Entendemos tu deseo de adoptar un enfoque más gradual para la adopción de TKV y agradecemos tus solicitudes específicas sobre K/V y B&A. Sin embargo, después de una evaluación cuidadosa, decidimos no relajar las protecciones de privacidad en estas APIs en este momento. Creemos que estas medidas, como el rozamiento, son fundamentales para proteger la privacidad del usuario y mantener la confianza en Privacy Sandbox. |
| Servidor K/V | Necesitas orientación para escalar el almacén de par clave-valor a través de una configuración compatible. | La Guía de tamaño de instancias de servidores K/V publicada recientemente puede ayudarte. La herramienta proporcionará las QPS (indicadas como "RPS" en la explicación) en cada combinación de parámetros. |
| Servidor K/V | Se agregó información del vendedor en la solicitud del servidor K/V. | Estamos analizando el tema y agradecemos los comentarios adicionales aquí. |
| Servicios de K/V + B&A | Solicita que se aclare el cronograma o la hoja de ruta de K/V y B&A. | Para K/V y B&A, tenemos etapas y cronogramas: En el caso del servidor K/V junto con las subastas de la API de PA integradas en el dispositivo (en comparación con B&A), el cronograma público está disponible aquí. En términos de cómo se define la "Disponibilidad general" para K/V, consulta la sección del plan de ruta, que define el conjunto de funciones para las versiones beta y general. En el caso de B&A, consulta el cronograma público aquí y el plan de ruta aquí. Definimos las pruebas de escalamiento como "pruebas estables y completas a escala de producción". Consulta aquí para conocer el conjunto de funciones específico en esta etapa. B&A también tiene etapas alfa y beta, por lo que la prueba a escala incluirá el superconjunto de funciones de etapas anteriores. En el caso de K/V y B&A, avísanos si estas definiciones de etapas ayudan a aclarar qué estará disponible y cuándo. Si aún hay déficits, comunícate con nosotros. Con gusto te brindaremos más detalles para que puedas planificar mejor. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Respuesta del mercado | El requisito de que los sistemas de atribución de la competencia solo usen informes a nivel del evento y de resumen o agregados dentro de límites estrictos es una restricción arbitraria a la competencia. Evita la atribución y el retargeting específicos del dispositivo en tiempo real a nivel del evento, incluso si se implementan protecciones para garantizar el cumplimiento de la protección de datos (p.ej., la desidentificación). | El diseño mencionado se basa en los objetivos de privacidad de la API; p.ej., proteger la información entre sitios que se transfiere de un sitio a otro. Por ejemplo, la ARA admite la atribución a nivel del evento a través de informes de eventos. Los informes de eventos tienen un retraso de, al menos, una hora, lo cual es necesario para dificultar la asociación del informe a nivel del evento con la identidad del usuario en el sitio del anunciante mediante ataques de canal lateral de tiempo, como se documenta aquí. Además, existen otras formas de realizar la atribución, más allá de la ARA, como recopilar información directamente de los usuarios que proporcionan datos de identificación de forma consciente. Estamos abiertos a recibir comentarios sobre los casos de uso que no se pueden lograr con los límites de privacidad actuales de las APIs de Privacy Sandbox. |
| Varias superficies | Solicita confirmación sobre si las APIs de ARA y Shared Storage admiten o no casos de uso de varias plataformas y dónde se evidencia esto. | Actualmente, ARA y el almacenamiento compartido no admiten la atribución multisuperficie (entre dispositivos). Se admite la atribución web y entre apps en el mismo dispositivo (mediante ARA). |
| (También se informa en trimestres anteriores) Dispositivos múltiples |
¿La ARA admite conversiones en dispositivos múltiples? | Nuestra respuesta es similar a la de trimestres anteriores: La multidispositivo presenta nuevos desafíos de privacidad además de los de 3PC y también agrega desafíos de distribución de tecnología debido a la variedad de dispositivos y plataformas que puede usar un usuario. Estamos explorando posibles soluciones, pero nos enfocamos en los casos de uso críticos que actualmente admite ARA y, por el momento, no tenemos un cronograma para la compatibilidad multidispositivo. |
| Escalamiento | Preocupaciones sobre si la API de Attribution Report (ARA) está configurada actualmente y si se puede implementar y escalar de forma confiable para atender a todos los usuarios de Chrome. | Actualmente, ARA está disponible para todos los usuarios de Chrome y se ejecuta como se espera. Además, seguimos probando y supervisando su confiabilidad y escalabilidad, ya que la cantidad de empresas de tecnología publicitaria que prueban la ARA sigue aumentando. Te invitamos a que nos envíes más comentarios sobre el ecosistema aquí. |
| (También se informó en trimestres anteriores) Anulación de duplicación |
Inquietudes sobre cómo la ARA propone restringir el mecanismo de atribución en los dispositivos de modo que los publicadores no puedan realizar de manera eficaz la lógica posterior a la atribución para los informes de resumen, incluida la anulación de duplicación de varias conversiones del mismo tipo para el mismo clic en el anuncio. | Nuestra respuesta no cambia desde los trimestres anteriores: La anulación de duplicados en los dispositivos y las canalizaciones de medición es un desafío conocido y actual que las tecnologías publicitarias también enfrentan hoy con las 3PC. Con la ARA, las tecnologías publicitarias pueden decidir cuándo registrar conversiones específicas y agregar metadatos específicos para indicar qué embudos de medición utilizaron para hacer un seguimiento de las conversiones (es decir, parte de la clave de agregación), que se pueden comparar con otros embudos de medición. Te invitamos a que nos envíes más comentarios sobre el ecosistema aquí. |
| Seguimiento de conversiones | Solicitud de capacidad para operar con conversiones de varios dominios | Estamos analizando esta solicitud aquí y agradecemos los comentarios adicionales del ecosistema. |
| Informes | El navegador espera al menos dos días, pero hasta 30 días, para enviar la conversión, lo que puede ser motivo de preocupación, ya que la mayoría de los anunciantes interesados son anunciantes de rendimiento, que trabajan en tiempos casi en tiempo real. | La configuración predeterminada de los informes a nivel del evento tiene las siguientes ventanas de informes predeterminadas: 2 días, 7 días y 30 días. Con los informes flexibles a nivel del evento, las tecnologías publicitarias pueden cambiar la cantidad y la duración de los períodos de informes a partir de los valores predeterminados. Las ventanas de informes se pueden cambiar a un mínimo de 1 hora, lo que puede ayudar con los casos de uso de rendimiento de los anunciantes. Te invitamos a que nos envíes más comentarios sobre el ecosistema aquí. |
| Atribución de clientes en línea a sin conexión | ¿Habrá opciones de implementación para la publicidad en línea y sin conexión en ARA? ¿O hay alguna otra sugerencia para medir la atribución de sin conexión a en línea? | Actualmente, no hay planes para admitir casos de uso de medición de transición de canales en línea a ventas tradicionales en la ARA. Existen desafíos importantes de privacidad y seguridad que se deben tener en cuenta para este tipo de asistencia. Te invitamos a que envíes comentarios adicionales sobre el ecosistema en relación con los casos de uso de esta compatibilidad aquí. |
| Informes de depuración | ¿Cómo almacenar o recuperar el ID del anuncio de manera que esté disponible para acceder a los registros de Chrome (fuente o activador) para la atribución de app a Web? | Para habilitar los informes de depuración, la tecnología publicitaria debe demostrarnos que ya puede unirse al usuario en la app y la Web, y esto se hace para garantizar que los informes de depuración no revelen información nueva. La tecnología publicitaria puede demostrar la unión proporcionando una clave de unión única para cada usuario. Esta clave de unión puede ser el ID del anuncio o una clave de unión de origen. Si la tecnología publicitaria usa el ID del anuncio, Chrome no admite de forma nativa el acceso al ID del anuncio desde el navegador, y la API espera que cada tecnología publicitaria tenga su propio método para pasar el ID del anuncio durante el registro web. |
| Nivel de detalle del bucket | ¿Es posible usar diferentes estrategias de bucket por anunciante? | Te recomendamos que experimentes con diferentes enfoques de escalamiento del presupuesto de contribución para encontrar el que funcione mejor para tus casos de uso. La ARA se creó con la intención de ser flexible y personalizable para satisfacer una variedad de casos de uso de la tecnología publicitaria. Por lo tanto, te recomendamos experimentar con diferentes estrategias de agrupamiento por anunciante o por vertical. El uso de diferentes estrategias de agrupamiento puede ser útil cuando los anunciantes tienen diferencias en los valores de medición de los que les interesa realizar un seguimiento y en el volumen de los valores de medición. |
| Documentación | Solicite documentación adicional para implementar la Web de aplicaciones<>para la ARA. | Lanzamos la documentación sobre la app<>Web para ARA aquí. |
| Rendimiento | La cantidad de solicitudes relacionadas con la ARA puede representar una carga pesada en los servidores de un publicador en relación con la cantidad de solicitudes keepalive necesarias para impulsar el sitio. Agrupar eventos de origen en una sola solicitud puede ayudar a reducir la carga en un servidor. Una idea potencial es permitir que un array de objetos codificados en JSON | Es posible agrupar eventos de origen según una lógica específica hasta cierto punto con la lógica de JavaScript en combinación con la API. Actualmente, estamos evaluando esta solicitud y recibimos con gusto los comentarios adicionales del ecosistema aquí. |
| Solicitud de función | Se sugiere una propuesta de solución alternativa debido a que no es compatible con la integración de servidor a servidor. | Actualmente, no planeamos implementar la compatibilidad para la integración de servidor a servidor en la ARA. Existen muchos desafíos de privacidad que se deben considerar para permitir la integración de servidor a servidor. Agradecemos los comentarios del ecosistema sobre casos de uso adicionales de compatibilidad de servidor a servidor aquí. |
| Documentación | Solicita una guía de inicio rápido que explique las partes clave de la ARA y cómo comenzar a usarla con un par de casos de uso sencillos. | Aquí encontrarás una guía de inicio rápido para ARA. Estamos trabajando para mejorar aún más esta documentación este año y agradecemos los comentarios adicionales sobre casos de uso o situaciones específicos que requieran documentación adicional aquí. |
| Uso de API | Solicitud de recomendaciones para escalar contribuciones para muchos valores pequeños. | Te recomendamos que experimentes con diferentes enfoques de escalamiento del presupuesto de contribución para encontrar el que mejor se adapte a tus casos de uso. Para el escenario de muchos valores pequeños, recomendamos experimentar con diferentes valores de épsilon para identificar los puntos de inflexión en los cuales el ruido de épsilon puede ser aceptable en tu caso de uso. Puedes encontrar más detalles en nuestro artículo de investigación sobre la optimización de los informes de resumen en ARA. |
| Flexible a nivel del evento | ¿Cuándo se implementará la configuración flexible a nivel del evento (múltiples especificaciones de activadores)? | Actualmente, el nivel de evento flexible admite la personalización de los siguientes aspectos de configuración de registro: la cantidad de informes que se pueden generar por fuente, la cantidad y la duración de los períodos de informes, y la cardinalidad de los datos del activador. Actualmente, estamos recopilando más comentarios del ecosistema sobre mejoras flexibles adicionales a nivel del evento, pero no planeamos implementar ninguna en este momento. Nos complace recibir comentarios adicionales sobre casos de uso que podrían beneficiarse de algunas de las mejoras flexibles a nivel del evento que se enumeran aquí. |
| Procesamiento de buckets | Solicita que se considere limitar las contribuciones agregadas para los buckets, así como la extensibilidad y la retrocompatibilidad futuras. | Estamos analizando esta solicitud y agradecemos los comentarios adicionales aquí. |
| Epsilon | ¿Qué sucede con el rango de epsilon una vez que ARA cambia a disponibilidad general? | La ARA alcanzó la disponibilidad general en Chrome en el 3ᵉʳ trimestre de 2023. En este momento, no hay planes para modificar la ventana de valor de épsilon. Nuestra propuesta de implementar una estructura de administración revisada proporciona más garantías en caso de que se prevean modificaciones. |
| Informes | Los informes de error de activación desconocida no contienen atributos de origen en el cuerpo del informe. | Como se indica en la especificación, no es necesario que haya otros campos en el cuerpo del informe para trigger-unknown-error. Reconocemos que la tabla que describe los campos en el cuerpo del informe era potencialmente engañosa, ya que los campos relacionados con la fuente pueden estar presentes o no, según la causa subyacente del error. Por ejemplo, se podría producir un error interno antes de que se produzca la lógica de coincidencia de fuente, lo que significaría que no hay datos de origen disponibles para propagar el informe de depuración. Ya actualizamos la documentación para aclarar esto. |
| Uso de API | Cuando se trabaja con dos objetivos de medición, recuento y valor, ¿la indicación es dividir el presupuesto de contribución y el ϵ? | Cuando trabajes con dos objetivos de medición, te recomendamos que dividas el presupuesto de contribución entre ellos. |
| Informes | ¿La ARA admite la atribución multitoque o los informes de asistencia (también conocidos como informes de contribución)? | Actualmente, la ARA no admite la atribución multitáctil ni los informes de asistencia. Por el momento, no tenemos planes de implementar esta función. Agradecemos los comentarios adicionales sobre casos de uso y su prioridad aquí. |
| Error de la API | En el caso de ARA, la documentación indica que se usa XOR para combinar las piezas clave de agregación de origen y activador, pero, en la práctica, se usa O. Esta discrepancia genera confusión y posibles errores en la implementación. | Se actualizó la documentación para reflejar que se trata de un error. |
Servicio de agregación
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Trabajos de agregación | Solicitud para permitir múltiples prefijos en trabajos de agregación. | Estamos investigando los comentarios y publicamos una propuesta aquí. Puedes enviarnos comentarios sobre la propuesta aquí. |
| Solicitud de función | Se solicitó cambiar la secuencia de comandos de Terraform para que, si no se establece service_account_token_creator_list (o está vacía), se omita la modificación de la política de IAM de la cuenta. | Estamos investigando este problema aquí y recibimos con gusto más comentarios sobre el ecosistema. |
| Uso de API | Se necesita una aclaración sobre el hecho de que el plan de Terraform siempre muestra cambios. | Este problema se corrigió en la versión AgS 2.8. |
| Uso de API | Buscar recomendaciones para configurar la configuración por anunciante para la frecuencia de agregación con filtrado de contribución flexible | Actualmente, con la ARA es posible agrupar en lotes por anunciante. El filtrado flexible de contribuciones se puede usar para casos más avanzados en los que una tecnología publicitaria desea segmentar aún más las contribuciones de un informe por diferentes frecuencias. Las tecnologías publicitarias pueden obtener más información sobre el procesamiento por lotes aquí y sobre el uso de IDs de filtrado con ARA aquí. También estamos trabajando en más documentación para filtrar IDs. |
| Solicitud de función | Solicita compatibilidad con "log_sum_exp" en el servicio de agregación (AgS). | Nos comunicamos con esta parte interesada para obtener más detalles sobre el caso de uso. Te enviaremos una actualización cuando tengamos más detalles. |
| Solicitud de función | Solicita poder ver más registros, estadísticas y otras métricas cada vez que haya problemas en las AgS y posibles problemas en una AgS implementada. | Publicamos actualizaciones de nuestra documentación para incluir más errores, mitigaciones y descripciones aquí. Agradecemos los comentarios adicionales sobre errores, métricas, registros, etc. que no estén documentados o disponibles, y sobre qué detalles serían útiles aquí. |
| Pruebas de API | ¿Cuál será el valor final de epsilon después del período de prueba? | Por el momento, no hay planes para modificar la ventana de valor de epsilon. Recomendamos a los verificadores que experimenten con diferentes parámetros y envíen comentarios. |
| Informes | Se genera el informe, pero también se muestra PRIVACY_BUDGET_AUTHORIZATION_ERROR en el código devuelto. | Proporcionamos orientación para especificar el origen de los informes y los informes agregables correctos para evitar este error. Nos complace recibir comentarios adicionales sobre el problema, en especial, si hay errores recurrentes. |
| Descubrimiento de claves | ¿Cuáles son los planes para la propuesta de descubrimiento de claves? | Aún no tenemos un cronograma para el lanzamiento de la propuesta de descubrimiento clave, pero solicitamos comentarios del ecosistema sobre la propuesta aquí. |
| Personalización | Buscar opciones de personalización disponibles para el servicio de agregación | No es posible personalizar el servicio de agregación dentro del TEE, pero sí para algunos componentes fuera de él. Esto se debe a los estándares de privacidad y seguridad que debemos mantener dentro del TEE. Estamos trabajando para actualizar nuestra documentación a fin de ayudar a las tecnologías publicitarias a comprender la arquitectura y los componentes que se pueden personalizar. No podríamos admitir ciertas personalizaciones, por lo que recomendamos que las tecnologías publicitarias usen nuestras configuraciones estándar siempre que sea posible. |
| Instancias puntuales frente a instancias bajo demanda | ¿Se probó el sistema con instancias spot en lugar de instancias bajo demanda? ¿Hay alguna desventaja específica de usar instancias spot, además de su posible falta de disponibilidad temporal? | No priorizamos las pruebas en instancias Spot porque recomendamos que las tecnologías publicitarias usen instancias a pedido. La desventaja de las instancias spot es que la tarea se interrumpe durante el consumo del presupuesto. Si se consumió el presupuesto y el trabajo se interrumpe antes de que la tecnología publicitaria reciba el informe de resumen, las plataformas de tecnología publicitaria no podrían simplemente reintentar el trabajo, pero deberían solicitar la recuperación del presupuesto. La recuperación del presupuesto solo se recomienda para fallas catastróficas para preservar la privacidad. Recomendamos a las plataformas de tecnología publicitaria que configuren el ajuste de escala automático para minimizar los costos. Si seleccionas 0 para el ajuste de escala automático, no habrá instancias en ejecución hasta que se solicite una tarea (ten en cuenta que esto puede aumentar la latencia, ya que las instancias se activarán en el momento de una solicitud). |
| Errores conocidos y soluciones | Se necesita una aclaración sobre el trabajo del servicio de agregación que muestra un "Error de servicio" | Este problema se resolvió aquí. También actualizamos algunos de nuestros mensajes de error para que sean más descriptivos. Por ejemplo, comenzamos a generar errores de permisos o autenticación más específicos en AWS, a diferencia de antes, cuando estos errores aparecían como errores internos. Actualizamos la documentación sobre los códigos de error y los pasos de mitigación aquí. Aceptamos comentarios adicionales sobre los errores que no están documentados o disponibles y sobre qué detalles serían útiles aquí. |
API de Private Aggregation
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Diseño de claves | Solicitud de orientación sobre el diseño de claves de agregación privada | Si bien no tenemos una guía específica para la agregación privada, tanto el framework de pruebas de carga del servicio de agregación como la guía de administración de claves avanzada se pueden usar como recursos. |
| Presupuesto de contribución | ¿En qué nivel se calcula y limita el presupuesto de contribuciones? | El presupuesto de contribución es de 2^16 en una ventana continua de 10 minutos y de 2^20 en una ventana continua de 24 horas. |
Limita el seguimiento encubierto
Reducción del usuario-agente o sugerencias de cliente de usuario-agente
No se recibieron comentarios este trimestre.
Protección de IP (anteriormente Gnatcatcher)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Android | ¿Cuál es el plan para lanzar la Protección de IP en Android? | Si bien estamos explorando la posibilidad de llevar funciones contra el seguimiento oculto a Android, incluida la protección de IP, no tenemos planes formales para compartir en este momento. |
| Uso de API | ¿Hay o habrá una excepción contra el fraude para la protección de IP? | Nos esforzamos por lograr un equilibrio entre proteger a los usuarios de que se les haga un seguimiento en la Web en función de sus direcciones IP y, al mismo tiempo, minimizar las interrupciones en las operaciones normales de los servidores, incluido el uso de direcciones IP para evitar abusos. Si bien no podemos proporcionar más detalles en este momento, esperamos hacerlo en un futuro cercano y esperamos continuar con la conversación. |
| Identificación de personas que actúan de mala fe | Preocupaciones sobre la eficacia de las medidas de seguridad tradicionales contra las direcciones IP maliciosas | La Protección de IP no usará proxy para las solicitudes propias, por lo que esperamos que la mayoría de los sistemas de detección de intrusiones no se vean afectados. Planeamos ofrecer detalles adicionales en el futuro para abordar las inquietudes sobre las fallas en el sitio y antifraude para los usuarios que utilizan el modo Incógnito. |
| Enmascaramiento de direcciones IP | Si el sitio del publicador de noticias (propio) usa el mismo dominio que el sitio de publicidad (de terceros), ¿se enmascarará la dirección IP para ambos? De lo contrario, ¿cómo se distingue entre ambos? | IP Protection propone actualmente un enfoque basado en listas para identificar el tráfico de terceros que pasa por los proxies. Sin embargo, incluso si un origen está en esa lista, no se usará un proxy si se accede a él en un contexto propio. Estamos finalizando los detalles sobre qué dominios externos específicos tendrán prioridad inicialmente y cómo definiremos con precisión los contextos propios y externos para la Protección de IP. |
| Enmascaramiento de direcciones IP | Preocupación por la protección IP y su impacto en los sistemas antifraude. | Los propietarios de contenido original no se ven afectados por nuestros planes de Protección de IP, por lo que los sitios como los foros deben tener acceso a las direcciones IP para resolver las disputas. Planeamos proporcionar más detalles en el futuro para abordar las inquietudes relacionadas con el fraude publicitario. |
| Enmascaramiento de direcciones IP | ¿La IP está enmascarada en el encabezado de los dominios afectados? | A los usuarios se les asignará un área geográfica según su dirección IP anterior al proxy que represente su ubicación actual. Puedes obtener más información aquí. |
Mitigación del seguimiento por rebote
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Especificaciones de API | Se necesita una aclaración sobre el comportamiento de Chrome con respecto al manejo de la navegación extendida cuando se cierra una pestaña. | Resolvimos este problema aquí y actualizamos las especificaciones según corresponda. |
| Seguimiento de navegación | Análisis de un enfoque de mitigación de seguimiento que incluye un conjunto finito de vínculos para reducir la entropía en las solicitudes entre sitios | Seguimos analizando este tema con otros proveedores de navegadores aquí y recibimos con gusto comentarios adicionales y propuestas específicas sobre este problema del ecosistema. |
Privacy Budget
Como se indica en la explicación de GitHub y en el sitio para desarrolladores, Privacy Budget ya no se considera de forma activa
como parte de las propuestas de Privacy Sandbox.
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 |
|---|---|---|
| (También informado en trimestres anteriores) Límite de dominios del conjunto de sitios web relacionados (RWS) | Solicitud para aumentar el límite de dominios asociados en RWS | Nuestra respuesta es similar a la de trimestres anteriores: Por el momento, no esperamos aumentar el límite numérico. El límite se estableció en función de las consideraciones de privacidad del usuario, los comentarios de las partes interesadas del ecosistema en el W3C y la consideración de implementaciones comparables en otros navegadores. Para obtener más información, consulta nuestras entradas de blog (1, 2). Te recomendamos que examines los casos de uso que requieren acceso a cookies entre sitios más allá del límite numérico y que consideres aprovechar nuestra guía para casos de uso de identidad, incorporaciones autenticadas y casos de uso de publicidad. Si las sesiones de los usuarios están vinculadas a acciones de acceso, te recomendamos que uses la API de Federated Credential Management (FedCM) para mantener la funcionalidad. Te invitamos a que nos envíes tus comentarios sobre otros casos de uso que puedan ser necesarios aquí. |
| Control de cookies entre sitios | Las cookies entre sitios que establece un subdominio no se pasan en las solicitudes posteriores del dominio principal. El problema persiste incluso con la configuración correcta de CORS y credenciales. | Aquí proporcionamos orientación sobre el uso correcto de la API requestStorageAccessFor que necesita especificar el origen completo (es decir, incluir subdominios) para que se envíen cookies entre sitios en solicitudes de recuperación posteriores. |
| Elección del usuario | Solicitud de más información sobre requestStorageAccessFor que usa RWS después del lanzamiento de la opción del usuario, en particular, cómo funcionará el gesto del usuario implícito o explícito, que actualmente permite el acceso a 3PC, en el nuevo sistema. | Esperamos que el comportamiento de los RWS en cualquiera de los modos de elección del usuario (es decir, independientemente de si los usuarios eligieron retener o limitar sus terceros de terceros) será coherente con el comportamiento existente o de envío en Chrome con las cookies de terceros permitidas en comparación con las cookies de terceros bloqueadas con RWS habilitado ("Permitir que los sitios relacionados vean tu actividad en el grupo"). Te recomendamos que primero invoques hasStorageAccess para verificar si la incorporación ya tiene acceso a cookies entre sitios no particionadas antes de invocar requestStorageAccess. El método hasStorageAccess mostrará un valor verdadero si el usuario eligió permitir 3PC. Actualmente, requestStorageAccessFor no requiere un gesto del usuario si se permiten 3PC. Abrimos un nuevo problema de GitHub para discutir y especificar cuál debería ser el comportamiento correcto en este caso, y agradecemos los comentarios adicionales del ecosistema. |
| Uso de API | Inquietudes sobre la falta de claridad en cuanto al uso de los RWS con fines "comerciales", lo que dificulta su adopción. La parte interesada indicó interés en agrupar publicaciones para la publicidad segmentada. | El uso previsto de los RWS es admitir la funcionalidad principal del sitio y los recorridos principales de los usuarios. Recomendamos el uso de nuestras APIs de publicidad para propósitos específicos en los casos de uso relacionados con la publicidad segmentada. |
| Uso de API | Se informó un problema con requestStorageAccess en el que se podían establecer datos de localStorage, pero no cookies. | El problema se debió a un error tipográfico en el atributo SameSite. Asegúrate de que la ortografía sea correcta y configúralo de forma explícita en Ninguno para 3PC. |
| Especificaciones de API | Discrepancias en los esquemas JSON del repositorio, como la ubicación incorrecta del campo "contact" y sugerencias de mejoras, incluido el uso de la palabra clave "oneOf" para garantizar la coherencia. | Estamos investigando estos comentarios y buscaremos realizar estas mejoras en el esquema en un futuro cercano. Te invitamos a que nos envíes tus comentarios adicionales aquí. |
| Acceso de terceros a RWS | Con el consentimiento del usuario, permite que un medio indique los dominios de terceros que también tendrán ese acceso a los datos de la API de RWS. | Permitir que los terceros combinen sus propios datos sin particionar con los datos de sitios de RWS socavaría las protecciones de seguimiento entre sitios de Privacy Sandbox. Sin embargo, estamos considerando la posibilidad de permitir que los terceros mantengan los datos particionados en un RWS y buscamos comentarios sobre el diseño de una solución de este tipo aquí. |
API de Fenced Frames
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Pregunta sobre la API | Inquietudes sobre cómo los marcos delimitados sin acceso a la red podrían infringir la seguridad de la marca y la protección contra el fraude de los anunciantes. | Estamos haciendo un seguimiento de esta inquietud en el contexto de nuestro plan para aplicar los marcos delimitados. Pronto comenzaremos a buscar soluciones compatibles con la aplicación forzosa de los marcos delimitados y, en cuanto haya propuestas lo suficientemente sólidas, las compartiremos. |
| Pregunta sobre la API | ¿La API de Fenced Frames aún está programada para 2026? | Como se indica en nuestro anuncio público, los marcos vallados no serán obligatorios antes de 2026. |
| Error de la API | Cuando reportEvent() envía datos de clics correctamente desde un submarco de origen cruzado, setReportEventDataForAutomaticBeacons() no reemplaza los datos del marco superior. |
Estamos analizando este problema y agradecemos tus comentarios adicionales aquí. |
API de Shared Storage
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Publicidad en apps | No hay un equivalente de la API de Shared Storage en Privacy Sandbox en Android. | Estamos evaluando soluciones en Android en función de las necesidades de los casos de uso y las restricciones de la plataforma. Por el momento, no tenemos planes de compartir información, pero agradecemos los comentarios adicionales del ecosistema sobre este tema. |
| Uso de API | Confusión en cuanto a la necesidad de una tarea en JavaScript adicional para la implementación de la API de Shared Storage. |
Estamos investigando estos comentarios y considerando la posibilidad de actualizar nuestra documentación para explicar la necesidad de secuencias de comandos de worklet adicionales para la API de Share Storage. |
| No confiabilidad | La API de Shared Storage podría cambiar de forma significativa o eliminarse en función de las críticas sobre la privacidad, lo que la convierte en una base poco confiable para compilar. | No tenemos planes de cambiar o descartar significativamente la infraestructura de almacenamiento compartido. Los principales cambios que se anunciaron son en la puerta de salida de Select URL, en la que se requerirán marcos delimitados y dejarán de estar disponibles los informes a nivel del evento. Sin embargo, estos cambios no entrarán en vigencia al menos hasta 2026. |
CHIPS
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cookies particionadas | A diferencia de Firefox, Chrome no diferencia las claves de partición según los ancestros de marco, lo que genera inconsistencias. | Chrome adoptó el "bit de cadena de ancestros" para resolver la inquietud de seguridad y la discrepancia con el comportamiento de Firefox. Describimos esto con más detalle aquí. |
| Cookies particionadas | Los iframes incorporados con diferentes niveles de acceso de almacenamiento comparten y reemplazan la misma cookie particionada, lo que genera inconsistencias en los estados de autenticación. | Para esta configuración en particular, te recomendamos que uses cookies no particionadas con una invocación de la API de Storage Access. Analizamos este tema con más detalle aquí. |
| Cookies particionadas | ¿Se borrarán los contenedores de cookies particionados cuando se inhabiliten los 3PC? ¿Hay alguna manera de probar este comportamiento? | No tenemos planes para compartir en este momento. Sin embargo, los desarrolladores pueden probar esta funcionalidad borrando manualmente las cookies particionadas a través del panel Aplicación>Cookies de Chrome DevTools. |
FedCM
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Alcance del registro del proveedor de identidad (IdP) y selector de organizaciones |
Pregunta sobre la extensión del registro de la IdP de la política de origen actual a una política del mismo sitio. Este cambio permitiría una administración de identidad más amplia y flexible, como permitir que la página de bienvenida de una universidad registre varios proveedores de identidad basados en subdominios sin necesidad de registros separados específicos del origen. Comentarios para mejorar la depurabilidad, controlar los clientes aprobados para la mediación silenciosa, aclarar el comportamiento de las cookies, permitir la personalización del texto de la ventana emergente y abordar los problemas de tiempo de espera. |
Agradecemos estos comentarios y estamos considerando cómo se podría incorporar un selector de organizaciones en FedCM. Agradecemos que nos envíes comentarios adicionales del ecosistema aquí, ya que seguimos definiendo mejor este enfoque. |
| Cookies de IdP | Discusión sobre el impacto de implementar cookies de sesión de corta duración como parte de la propuesta de credenciales de sesión vinculadas al dispositivo (DBSC). Hay inquietudes sobre la experiencia del usuario en FedCM, en la que las cookies de IdP vencidas requieren un modal visible para el usuario para la renovación. | El DBSC propuesto debe permitir la renovación de cookies sin interacción del usuario, lo que garantiza una experiencia del usuario continua. Analizamos este problema con más detalle aquí. |
| Especificaciones de API | Pregunta sobre la pertinencia de usar "NetworkError" en la especificación de la API de FedCM cuando el tamaño del array "providers" no es igual a 1. | Creemos que “TypeError” sería más apropiado para esta situación, ya que refleja un error de codificación en lugar de un problema de red. Analizaremos este cambio y exploraremos la posibilidad de quitar esta restricción en actualizaciones futuras a medida que avancemos hacia la compatibilidad con varios IdP. Envíanos tus comentarios adicionales aquí. |
Cómo combatir el spam y el fraude
API de Private State Tokens (y otras APIs)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Prueba de baja y modo B | Preocupaciones sobre la prueba de baja, las pruebas del modo B, la posible baja de los tokens de estado privado (PST) y la posibilidad de que una nueva API sea más adecuada para su caso de uso de prevención de fraudes. | La prueba de baja y las pruebas del modo B no se modifican. Comunicaremos cualquier actualización a través del blog para desarrolladores. No tenemos planes de descontinuar las PST y estamos analizando el desarrollo y las actualizaciones de las funciones en curso en GitHub. No anunciamos ninguna API nueva, pero recibimos con gusto los comentarios sobre cómo los PST pueden abordar mejor los casos de uso de prevención de fraudes. |
| Comentarios sobre la API | Solicita la capacidad de revocar tokens para abordar un caso de uso de prevención de fraudes. | Si bien el emisor podría revocar todos los tokens cambiando las claves que usa, la revocación de tokens individuales no es factible con la API, ya que requeriría permitir que el emisor asocie la emisión y el canje de tokens, lo que rompe el modelo de privacidad de PST de evitar el seguimiento entre los dos eventos. |