Informe trimestral del segundo trimestre de 2023 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). 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 realiza una agregación de la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Para identificar los temas de comentarios comunes, se revisaron los temas de debate de las reuniones públicas (W3C, PatCG, IETF), los comentarios directos, GitHub y las preguntas frecuentes que surgieron a través de los equipos internos de Google y los formularios públicos.
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. Como reflejo 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
- 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
- Internet Engineering Task Force
- IP
- Dirección de protocolo de Internet
- openRTB
- Licitaciones en tiempo real
- TS
- Prueba de Origin
- PatCG
- Grupo de la comunidad de tecnología publicitaria privada
- Acceso al
- Usuario de confianza
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable
- 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 |
|---|---|---|
| Administración de datos y cumplimiento normativo | Orientación del ecosistema para usar Privacy Sandbox de conformidad con los requisitos reglamentarios | Al igual que con cualquier tecnología nueva, cada empresa es responsable de garantizar que su uso de Privacy Sandbox cumpla con la ley. Google no puede brindar asesoramiento legal a terceros. Sin embargo, sabemos que esta es un área clave de interés para el ecosistema. Para cada API, publicamos una amplia documentación técnica, que debería proporcionar la base para realizar las evaluaciones legales necesarias, y estamos trabajando para poner a disposición materiales adicionales que respalden los esfuerzos de las empresas por cumplir con los requisitos reglamentarios. |
| Propuesta de pruebas cuantitativas de CMA | Más información sobre la propuesta de pruebas cuantitativas de la CMA | Estamos trabajando junto con la CMA para diseñar experimentos que proporcionen una imagen del impacto de la baja de las cookies de terceros y la introducción de las propuestas de Privacy Sandbox en el ecosistema. En abril, la CMA publicó una guía de alto nivel sobre lo que sucedería durante el período de prueba, seguida de una guía detallada en junio. Te recomendamos que compartas directamente con la CMA tus preguntas o comentarios sobre la propuesta de pruebas cuantitativas. |
| Modos de prueba que facilitó Chrome | Más información y aclaraciones sobre los cronogramas de pruebas | El 18 de mayo, publicamos una entrada de blog en la que compartimos más información sobre los dos modos de pruebas facilitadas por Chrome. Estos detalles no son definitivos, y publicaremos más orientación sobre la implementación a medida que avancemos en el tercer trimestre de 2023. |
| Almacenamiento particionado | ¿Se usará el almacenamiento particionado durante las pruebas facilitadas por Chrome? | La partición de almacenamiento se enviará a todos los usuarios antes del experimento de baja de las cookies de terceros. Por lo tanto, se habilitará para todos los grupos experimentales. Los sitios tendrán la opción de habilitar una prueba de baja para recuperar el almacenamiento sin particionar durante este período. |
| Asistencia de producción | ¿Cuál es el proceso establecido para que Chrome admita los problemas técnicos y las derivaciones de Privacy Sandbox que afectan al ecosistema? | Google proporciona una variedad de canales para permitir que las tecnologías publicitarias informen problemas y permitan las derivaciones necesarias. Consulta nuestra descripción general de los comentarios para obtener más información sobre los foros públicos y privados para comentarios y derivaciones. |
| Cronograma de inscripción | El período actual para la inscripción es demasiado corto | Aún estamos evaluando la fecha límite de aplicación y nos gustaría conocer la opinión del ecosistema sobre cuál sería el plazo más adecuado. |
| Número DUNS | Más información sobre el requisito de número DUNS para la inscripción y la certificación | Los participantes pueden encontrar los requisitos para obtener un número DUNS en el sitio web de Dun & Bradstreet. Los requisitos varían según el mercado, por lo que los participantes deben asegurarse de consultar el sitio web del mercado específico que les interesa. Sin embargo, en general, los participantes deberán proporcionar información básica sobre su empresa, como el nombre, la dirección y la información de contacto del propietario o administrador. Es posible que también se les solicite a los participantes que proporcionen información financiera, como los ingresos anuales de la empresa. Una vez completada la solicitud, D&B la revisará y emitirá un número DUNS si se aprueba. |
| Transición de la prueba de origen a la disponibilidad general | ¿La transición de la prueba de origen a la disponibilidad general afectará a los verificadores actuales de la prueba de origen? | A partir de julio, los verificadores podrán acceder a las APIs de relevancia y medición en la fase de disponibilidad general. Esto proporcionará una superposición entre la disponibilidad de la prueba de origen y la disponibilidad general. |
| Estudio de AdExchanger | Más información sobre la metodología de la encuesta | En la encuesta, se les pidió a los encuestados que estimaran las tasas de sincronización y los ingresos de sus empresas. Los encuestados podían elegir la metodología para responder sus preguntas individuales. |
| Valores de los parámetros | ¿Cómo se determinan los valores de los parámetros, como el nivel de ruido, los umbrales de anonimato y el presupuesto de privacidad? | En esta explicación de GitHub, se establecen los principios más generales detrás de las APIs de Privacy Sandbox. Todavía se están definiendo muchos valores, y recibimos con gusto comentarios sobre este tema. |
Muestra anuncios y contenido relevantes
Temas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Preservación de la privacidad | Investigación que evalúa la API de Topics en términos de preservación de la privacidad | Participamos activamente en la comunidad de investigación y presentamos nuestras investigaciones sobre las propiedades de privacidad de la API de Topics en artículos, informes y presentaciones de talleres. Nos complace ver que más miembros externos de la comunidad de investigación participan en esta área. La API de Topics protege a los usuarios contra el seguimiento general en la Web, ya que dificulta demasiado hacer un seguimiento de los usuarios a gran escala. Estos documentos demuestran que lo estamos haciendo correctamente con la API de Topics. Son más privadas que las cookies de terceros y protegen a los usuarios mientras admiten los sitios que les gusta visitar. |
| La taxonomía de temas no es lo suficientemente detallada. | La taxonomía de temas generales no incluye temas más detallados, incluidos los específicos de la región. | En respuesta a los comentarios anteriores del ecosistema, el 15 de junio, publicamos una entrada de blog en la que se detalla una nueva taxonomía actualizada que incorpora numerosas mejoras a partir de los comentarios del ecosistema. Como parte de nuestro trabajo en la taxonomía revisada, colaboramos con varias empresas del ecosistema, como Raptive (antes CafeMedia) y Criteo. La taxonomía actualizada quita las categorías que consideramos menos útiles y las reemplaza por categorías que coinciden mejor con los intereses de los anunciantes, a la vez que mantenemos nuestro compromiso de excluir temas potencialmente sensibles. Invitamos al ecosistema a revisar la taxonomía más reciente y enviar comentarios sobre los cambios. |
| Proceso de actualización de la taxonomía y el clasificador | Más información sobre la taxonomía de Topics y la cadencia de lanzamientos del clasificador, y cómo las empresas pueden prepararse para esas actualizaciones. | Como se compartió en la entrada de blog reciente, esperamos que la taxonomía evolucione con el tiempo y que la gobernanza de la taxonomía eventualmente se transfiera a un tercero externo que represente a las partes interesadas de toda la industria. También compartimos el plan de implementación en el grupo topics-announce. |
| Impacto en los indicadores propios | El aumento en la cantidad de temas de la actualización reciente de la taxonomía puede ser muy valioso y, como resultado, desvaloriza otros indicadores basados en intereses propios. | En el informe del 1ᵉʳ trimestre de 2023, la CMA comentó que "Según entendemos, Google ha estado analizando su nueva taxonomía propuesta con varios participantes del mercado en toda la cadena de suministro de tecnología publicitaria. Si bien algunos publicadores grandes han dicho que una mayor utilidad de los temas aumentaría la presión competitiva sobre sus soluciones basadas en datos de origen, nuestra opinión preliminar es que una mayor utilidad es mejor para la competencia en general, en particular para la capacidad de los publicadores más pequeños de seguir monetizando su inventario después de la baja de las cookies de terceros". Nuestra opinión está alineada con este comentario de la CMA. |
| Utilidad para diferentes tipos de partes interesadas | Las tecnologías publicitarias que actúan como SSP y DSP pueden tener ventajas significativas sobre otros actores del ecosistema. | Nuestra respuesta no ha cambiado desde los trimestres anteriores: "Google se comprometió con la CMA a diseñar e implementar las propuestas de Privacy Sandbox de una manera que no distorsione la competencia dando preferencia a su propio negocio, y a tener en cuenta el impacto en la competencia en la publicidad digital y en los publicadores y anunciantes, independientemente de su tamaño. Seguimos trabajando en estrecha colaboración con la CMA para garantizar que nuestro trabajo cumpla con estos compromisos. A medida que avanzan las pruebas de Privacy Sandbox, una de las preguntas clave que evaluaremos es el rendimiento de las nuevas tecnologías para los diferentes tipos de partes interesadas. Los comentarios son fundamentales en este sentido, en especial los comentarios específicos y prácticos que pueden ayudarnos a mejorar aún más los diseños técnicos. Trabajamos con la CMA para desarrollar nuestro enfoque de pruebas cuantitativas y apoyamos que la CMA publique una nota sobre el diseño de experimentos para proporcionar más información a los participantes del mercado y una oportunidad para comentar sobre los enfoques propuestos". |
| Temas secundarios | Si los criterios de selección de temas son la frecuencia de las visitas del navegador, ¿la fragmentación del segmento hará que los temas secundarios nunca lleguen a la parte superior? | Actualmente, Chrome está evaluando otras metodologías de clasificación y explorando otros indicadores que podrían mejorar la clasificación. Comunicaremos nuestros planes revisados al ecosistema a su debido tiempo. |
| Sensibilidad | El objetivo de la API de Topics debe ser garantizar que la información del usuario obtenida o derivada de la API de Topics sea menos sensible a nivel personal que la que se podría obtener con los métodos de seguimiento actuales. | Creemos que la API de Topics es mucho más privada que las tecnologías actuales, limita significativamente la nueva identificación de los usuarios y está diseñada para excluir temas sensibles. Reconocemos que los temas se pueden correlacionar o combinar con datos de origen para crear categorías sensibles, pero creemos que la API de Topics es un paso adelante para la privacidad del usuario y nos comprometemos a seguir mejorando la API. |
| Estructura de la taxonomía | Agrega el ID, el control de versiones y otra estructura de metadatos a la taxonomía de temas | Actualmente, en la respuesta de la API, incluimos el ID de la taxonomía. A medida que avanzamos hacia una administración a largo plazo, tiene sentido revisar el objeto Topics y, si es necesario, incluir metadatos adicionales en el control de versiones. |
| Control del publicador | Los publicadores deben tener voz en los temas en los que se deben clasificar sus sitios. | La clasificación incorrecta de los sitios puede hacer que el indicador de Topics sea un poco menos útil en general, pero los sitios específicos que se clasifican de forma incorrecta no se ven afectados más ni menos que cualquier otro sitio. Esto se debe a que la información contextual de un sitio siempre estará disponible para las subastas en su sitio, lo que proporcionaría información comparable al tema correcto, incluso en el caso de una clasificación incorrecta. Envíanos tus comentarios sobre este tema aquí. Permitir que los publicadores controlen su clasificación conlleva riesgos. Los sitios pueden clasificar sus sitios de forma incorrecta de forma intencional, lo que reduce la utilidad para todos, o codificar significados sensibles en temas menos comunes, lo que perjudica la privacidad del usuario. |
| Extensiones de Chrome | Permite que las extensiones de Chrome administren y filtren temas, de manera similar a las extensiones de administración de cookies actuales. | Esto ya debería ser posible, como se explica en GitHub, pero recibimos con gusto comentarios adicionales del ecosistema. |
| Transición a la disponibilidad general | ¿Habrá algún impacto en la API de Topics cuando se realice la transición de la Prueba de origen a la disponibilidad general? | No se perderán datos para los usuarios que realicen la transición de la Versión de prueba de Origin a la Versión general. |
| Privacidad | Los nombres de host pueden contener información privada que la API de Topics puede revelar. | Tenemos varias mitigaciones para garantizar la privacidad, como se describe aquí. |
| Fraude y abuso | Cómo evitar la manipulación de temas por parte de visitas fraudulentas | Aquí se explican las mitigaciones. |
| Clasificador de temas | ¿Los sitios web pueden solicitar alterar su clasificación de temas? | Nos interesa conocer la opinión del ecosistema sobre este tema y los comentarios son bienvenidos aquí. |
| Sitios de proveedores de Topics | Designa ciertos sitios web que alojan contenido de muchos temas como "Sitios de proveedores de temas especiales" y entrena clasificadores en función de las etiquetas proporcionadas en las páginas web. | Estamos analizando la propuesta aquí y recibimos con gusto más comentarios. |
API de Protected Audience (antes conocida como FLEDGE)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Determinación por tráfico | Impacto en el rendimiento del filtrado impulsado por la SSP para optimizar la carga de consultas por segundo (QPS) | Pasamos mucho tiempo pensando en la conformación del tráfico y nuestra recomendación es que las SSP aprovechen el almacenamiento en caché. |
| Volumen de pruebas | Es difícil probar Protected Audience, ya que las SSP y las DSP tienen dificultades para obtener grandes volúmenes de tráfico. | Trabajamos constantemente con socios de SSP y DSP para que adopten y prueben Protected Audiences. Comenzó la disponibilidad general y estamos seguros de que el porcentaje de tráfico con PA habilitado hará que sea más atractivo para los socios realizar pruebas. |
| Complejidad | La implementación de soluciones de Protected Audience requiere un esfuerzo y costos considerables. | Reconocemos que es difícil adoptar nuevas tecnologías, incluida Privacy Sandbox. El equipo de Privacy Sandbox trabaja en estrecha colaboración con una amplia variedad de partes interesadas para educarlas y apoyar sus iniciativas, y evalúa constantemente otros aceleradores para respaldar la adopción del ecosistema. |
| Entornos de ejecución confiables | Compatibilidad con entornos de ejecución confiables (TEE) en entornos de nube no públicos | Si bien estamos explorando opciones de compatibilidad más allá de las soluciones basadas en la nube, actualmente no es posible admitir TEEs en las instalaciones debido a las limitaciones de seguridad que requerirían una evaluación que consume mucho tiempo para Privacy Sandbox. Teniendo en cuenta los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que lo más beneficioso para el ecosistema es seguir expandiendo y mejorando las implementaciones basadas en la nube (p.ej., admitir GCP además de AWS). Sin embargo, agradecemos los comentarios adicionales sobre por qué es necesario este requisito. |
| Estructura de costos | La propuesta de servicios de ofertas y subastas aumentará el costo y la complejidad de las tecnologías publicitarias en comparación con los modelos del cliente. | Actualmente, estamos desarrollando una guía para estimar los costos de admitir flujos de trabajo de ofertas y subastas en el servidor de ofertas y subastas, que se correlacionarán con el uso de la tecnología publicitaria, lo que cumplirá uno de los objetivos de nuestros diseños. |
| Cronogramas de K-Anon | ¿Cuándo se aplicarán las restricciones de k-anonimato planificadas en "renderUrl"? | Estamos trabajando en una explicación del cronograma de aplicación que lanzaremos pronto. |
| Restricciones de runAdAuction | ¿Puede Chrome restringir runAdAuction para que solo se pueda llamar desde la página principal? |
Si bien nuestro diseño admite que se pueda llamar a runAdAuction desde la página principal, creemos que sería más perjudicial para los publicadores restringirlo para que solo se pueda llamar desde el dominio principal.El ecosistema nos indicó específicamente que Privacy Sandbox debe minimizar la carga para los publicadores y anunciantes. Esos comentarios se alinean con el principio general del desarrollo web que indica que los propietarios de sitios pueden usar herramientas de terceros para ejecutar sus sitios. El objetivo de Privacy Sandbox es fomentar un ecosistema saludable sin necesidad de prescribir cómo funcionan los publicadores y las tecnologías publicitarias. Creemos que, al permitir que el publicador elija cómo y quién llama a runAdAuction en su sitio, les ofrecemos flexibilidad para que encuentren la mejor ruta para sus requisitos. |
| Asistencia para la implementación | ¿Puede Chrome compilar o contribuir a una implementación de código abierto de una subasta de múltiples vendedores? | El objetivo de Privacy Sandbox es desarrollar tecnologías que preserven la privacidad y que no dependan de cookies de terceros ni de otros identificadores entre sitios. Queremos fomentar un ecosistema saludable sin necesidad de prescribir cómo deben funcionar las tecnologías publicitarias. Publicamos una guía sobre el funcionamiento de las APIs en nuestro repositorio de GitHub y estamos dispuestos a explorar soluciones con la industria. No planeamos crear ninguna implementación específica, ya que nuestro mandato principal es crear tecnologías de plataforma, no dictar estrategias para usarlas. Nuestras tecnologías permitirán que las empresas de tecnología publicitaria brinden un mejor servicio a sus clientes con los controles de privacidad adecuados para los consumidores. |
| Subastas de varios vendedores | ¿Chrome forzará el uso compartido de un ganador "contextual" con subastas de componentes? | La API de Protected Audience está diseñada para ofrecer a las partes que inician la subasta de varios vendedores la capacidad de pasar información a la subasta de componentes (nota: solo antes de iniciar la subasta). Dicho esto, no vemos la manera en que el navegador pueda distinguir si un dato es un ganador contextual o no, por lo que no podríamos aplicar el bloqueo ni exigir cierta información. |
| Preferencia del usuario para el seguimiento del consentimiento | Adtech le pregunta a PA cómo implementar correctamente el seguimiento del consentimiento del usuario | Nuestra respuesta incluye lo que dijimos en la pregunta 1: "En el caso de los anuncios específicos, la tecnología publicitaria relevante es la parte mejor posicionada para ofrecer controles sobre qué creatividades se muestran o cómo se seleccionan". Analizamos varias situaciones relacionadas con este problema durante la reunión de Protected Audience de WICG de mayo y recibimos con gusto comentarios y debates adicionales sobre este tema. |
| Públicos personalizados | ¿La API de Protected Audience admitirá los casos de uso de SSP relacionados con la creación de públicos personalizados? | La API de Protected Audience permite que las SSP y otros proveedores de tecnología publicitaria sean propietarios de los públicos personalizados y los administren. Se está desarrollando más orientación sobre cómo una SSP puede integrarse con la API de PA y se pondrá a disposición de las SSP y otros proveedores de tecnología publicitaria para respaldar sus esfuerzos de integración. |
| Formatos | ¿La API de Protected Audience admite videos? | Los anuncios de video se publican de una de las siguientes maneras: como XML de VAST o HTML (un anuncio out-stream que, en última instancia, también puede cargar XML de VAST en un reproductor de video). Los compradores pueden mostrar cualquiera de los formatos a través de una renderURL. La especificación de VAST se actualizó recientemente para admitir la API de Attribution Reporting. Los sitios que publican anuncios de video deberán prepararse para la forma en que se publican los anuncios a través de la API de Protected Audience. Esto significa que debes asegurarte de que las etiquetas de posición puedan pasar la URL de un iframe de Protected Audience a un reproductor de video. En el caso de los fotogramas con límites, trabajaremos para abordar las necesidades de los videos antes de que se exija su uso, que será antes de 2026. |
| Ritmo | ¿Cómo funciona el caso de uso de Pacing con la API de Protected Audience? | Agradecemos tus comentarios. Nos interesaría ver más instancias de esta solicitud con más detalles de más socios de SSP, ya que, hasta la fecha, esta ha sido una preocupación principalmente de las DSP. |
| Frecuencia de actualización | Es posible que la frecuencia de las llamadas de dailyUpdate (hasta 1 por grupo de interés por día) no sea suficiente para ciertos casos de uso, como la actualización de la información de los productos. |
Agradecemos tus comentarios. Existen otras soluciones disponibles para permitir que las tecnologías publicitarias usen indicadores que se actualizan en diferentes cadencias, como las búsquedas de K/V. |
| Control de calidad de anuncios | ¿Cómo implementan los publicadores el control de calidad de los anuncios? | Actualmente, la API de Protected Audience ofrece una funcionalidad para que los publicadores informen a sus SSP sobre ciertos controles que pueden establecer como parte de la configuración de la subasta, antes de la oferta (es decir, listas de entidades rechazadas basadas en etiquetas asociadas con los anuncios). Agradecemos los comentarios sobre cualquier funcionalidad adicional que pueda requerir el ecosistema. |
| Depuración | ¿Cuándo se quitará la funcionalidad de forDebuggingOnly? |
Planeamos retirar forDebuggingOnly para los eventos de pérdida debido a la baja de las cookies de terceros. Planeamos retirar forDebuggingOnly para los eventos de ganancia a partir de 2026 como mínimo. |
| Grupos de interés multidispositivo | Propuesta para habilitar grupos de intereses multidispositivos para agentes de usuario autenticados | Estamos evaluando esta propuesta, pero la alta especificidad de la segmentación multidispositivo plantea importantes inquietudes sobre la privacidad, como se explica en este problema de GitHub. |
| (También se informó en el 1ᵉʳ trim.) Remarketing dinámico | ¿Se podrá seguir utilizando el remarketing dinámico con la API de Protected Audience después de que se den de baja las cookies de terceros? | Creemos que este caso de uso es posible con Protected Audience, como se explica aquí. |
| Haz clic en los datos relacionados. | Agrega datos relacionados con los clics a browserSignals. |
Actualmente, estamos solicitando una aclaración sobre cuándo ocurrió el clic para darte una posición preliminar. |
| (También se informó en el cuarto trimestre de 2022) Funciones definidas por el usuario en Protected Audience | ¿Cómo se admitirán las funciones definidas por el usuario (UDF) en la API de Protected Audience? Estas son funciones que los usuarios finales pueden programar para extender la funcionalidad de la API. | El equipo de tecnología publicitaria que planteó este problema también mencionó que aún están evaluando lo que podrían hacer con las UDF, por lo que aún no hay comentarios prácticos a los que reaccionar, al menos hasta que se lance la disponibilidad general. |
| Moneda | Los importes de moneda no deben representarse con puntos flotantes. | Aquí abordamos este problema en detalle. |
| Funciones de selección de anuncios que no son de DSP | ¿Qué función desempeñan los servidores de anuncios en las subastas de la API de Protected Audience? | Sabemos que los servidores de anuncios siguen ofreciendo servicios de selección de anuncios posteriores a la oferta o de optimización de creatividades dinámicas. Actualmente, estamos evaluando el análisis de brechas detallado que existe entre la API actual de Protected Audience y estas solicitudes. |
| GenerateBid | Se agregó compatibilidad con la propuesta de Google Ads para mostrar más de un anuncio candidato por grupo de intereses de anuncios de generateBid y asignarles una puntuación en "scoreAd". |
Actualmente, se está evaluando esta opción. Envía tus comentarios adicionales aquí. |
| Orden de subasta | ¿Las subastas de la API de Protected Audience deben ser las últimas en ejecutarse para que puedan recibir entradas del resultado de todas las demás subastas? | No hay ningún requisito técnico para que la API de Protected Audience se ejecute por último. |
| Navegación que no inicia el usuario | Cómo exponer la navegación que no inicia el usuario | Estamos revisando esta solicitud y analizándola aquí . Agradecemos los comentarios adicionales. |
| Almacenamiento en caché | La SSP no debe compilar los perBuyerSignals de una DSP determinada desde una caché si cambia el estado del usuario. | Entendemos que el almacenamiento en caché no funciona para todos los casos de uso de los indicadores perBuyer y estamos evaluando otras opciones. Agradecemos cualquier comentario adicional del ecosistema sobre si la caché funcionaría para sus casos de uso. |
| Informes de atribución y Protected Audience | ¿Cómo pueden trabajar juntas la API de Attribution Reporting y la API de Protected Audience? | Actualmente, las integraciones están disponibles para la API de Protected Audience en ambos modos de la API de Attribution Reporting (informes a nivel del evento y de resumen). El 1 de junio, compartimos más información sobre la integración mejorada de la API de Protected Audience y Attribution Reporting. Puedes leer sobre ellos aquí. |
| Extremo del servidor | ¿El extremo del servidor será el servidor de agregación de confianza en el diseño final? | El extremo del servidor es un extremo mantenido por la tecnología publicitaria que es independiente de los servidores de agregación de confianza que se usan para procesar los informes recopilados y transformados. Por el momento, no tenemos planeados cambios para el extremo de informes. El objetivo del diseño actual es garantizar que los informes agregables (con cargas útiles encriptadas) no filtren datos entre sitios, por lo que no debería ser necesario un extremo de confianza. Una complicación adicional es que es probable que las diferentes tecnologías publicitarias tengan diferentes estrategias de lotes deseadas. Envía tus comentarios adicionales aquí. |
| WebIDL | La especificación actual de la API de Protected Audience no es compatible con la especificación de WebIDL. | Estamos evaluando estos comentarios y analizando el problema aquí. |
| Administración de consentimientos | ¿Cómo se controlará el envío de indicadores de consentimiento en la API de Protected Audience? | La información contextual no está dentro del alcance de la API de Protected Audience. Estamos analizando este problema y agradecemos tus comentarios adicionales. |
| Marketing basado en las cuentas | ¿Serían posibles los casos de uso de marketing basado en cuentas? | La API de Protected Audience admite una variedad de casos de uso de marketing basados en el público. Seguimos analizando cómo la API de Protected Audience puede admitir mejor este caso de uso en particular y agradecemos los comentarios adicionales sobre este problema que nos envíen desde el ecosistema. |
| Subasta de componentes | ¿Qué puntuación obtienen los participantes de la subasta de componentes? | Las subastas de componentes no califican directamente los grupos de intereses, sino que califican los anuncios y las ofertas que una DSP envía desde la función generateBid. La función generateBid() se ejecuta por grupo de interés, y la DSP muestra lo siguiente cuando ejecuta generateBid: return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Contribuciones externas | Solicitud para admitir contribuciones externas en la base de código de GitHub del servidor de par clave-valor. | Estamos buscando actualizar nuestros procesos relevantes para admitir contribuciones externas al código de GitHub. |
| Tamaño del grupo de interés | ¿Cuál es la cantidad máxima de claves que puede admitir IG? | El límite actual es de 50 KB para el tamaño de un IG, y las claves se cuentan como parte de ese límite. Nos complace hablar más sobre el límite de tamaño. |
| Agrupación en lotes | ¿Cómo se puede reducir la cantidad de llamadas al servidor K/V? | Puedes usar los encabezados de control de caché de HTTP para reducir la cantidad de llamadas K/V. Por ejemplo, se podría almacenar en caché en las subastas de componentes y también en los espacios publicitarios de una sola página. |
| Control de versiones | Compatibilidad con varias versiones del código de tecnología publicitaria | Los servicios de ofertas y subastas admitirán varias versiones del código de tecnología publicitaria. En la API de ofertas y subastas, la solicitud SelectAd puede especificar la versión del código que se usa para la solicitud de subasta (es decir, para las ofertas o subastas, y también para los informes). |
| Almacenamiento compartido | Se admite la escritura en el almacenamiento compartido en el servicio de ofertas y subastas. | Actualmente, los servicios de ofertas y subastas no admiten el almacenamiento compartido, pero recibimos con gusto comentarios adicionales sobre por qué estos casos de uso son importantes para el ecosistema. |
| De la Web a la app | Compatibilidad con el uso compartido de grupos de interés de la Web a la app | Actualmente, la implementación de la API de Protected Audience en Chrome y Android no abarca la transición de la Web a la aplicación, pero nos interesa saber qué opina el ecosistema sobre la importancia de este caso de uso. |
| K-anonimato | Cómo manejar las opciones de resguardo de k-anonimato | Estamos analizando el problema y recibimos con gusto más comentarios. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Parámetros de configuración alternativos de los informes a nivel del evento de VTC | Comentarios sobre las configuraciones alternativas de informes a nivel del evento de VTC | Recibimos algunos comentarios que indican que las configuraciones actuales a nivel del evento no son óptimas, por lo que solicitamos comentarios sobre las configuraciones globales óptimas. Estamos abiertos a recibir más comentarios sobre este tema y creemos que nuestra explicación flexible a nivel del evento también ayuda a abordarlo. |
| Parámetros de configuración flexibles a nivel del evento | ¿Cuál es el estado de la función de configuración flexible a nivel del evento? | Compartimos documentación sobre la configuración flexible a nivel del evento. La función aún se encuentra en la etapa de propuesta y estamos buscando más comentarios sobre si será valiosa para el ecosistema. |
| Parámetros de configuración flexibles a nivel del evento | ¿Cómo se pueden conciliar los informes contradictorios de diferentes partes? | La mayoría de las situaciones de informes se abordan mediante el uso de informes agregados, mientras que la propuesta de configuración flexible a nivel del evento es específicamente para brindar flexibilidad adicional a los informes a nivel del evento, que se usan con mayor frecuencia para casos de uso de optimización. Agradecemos cualquier comentario o sugerencia adicionales del ecosistema sobre esta situación. |
| Registro de origen | ¿Qué sucede si el registro de la fuente se produce después del registro del activador? | Actualmente, si se produce un registro de fuente después del registro del activador, la fuente y el activador no se podrán atribuir entre sí. Parece que se trata de un caso extremo. Agradecemos cualquier comentario adicional sobre este problema y buscaremos solucionarlo si parece ser una situación que enfrentan muchas tecnologías publicitarias. |
| Cómo trabajar con varias agencias de publicidad | ¿Cómo pueden las DSP usar la API de Attribution Reporting cuando un anunciante trabaja con varias agencias publicitarias? | La API admite redireccionamientos y, por lo tanto, se puede usar incluso cuando un anunciante trabaja con varias agencias de publicidad. Además, existen algunas limitaciones con respecto a los redireccionamientos para garantizar que la API mejore la privacidad. También identificamos una posible solución alternativa con la API de Shared Storage para la situación específica que planteó la tecnología publicitaria. Agradecemos cualquier comentario adicional sobre esta situación y seguiremos iterando en función de ellos. |
| Límites de destino | Es posible que el caso de uso de los anuncios con actualización automática se vea afectado por los límites de destino. | Analizamos este problema en la reunión del WICG del 1 de mayo y estamos buscando comentarios sobre cuál sería un límite razonable. Agregamos a la explicación de Attribution Reporting con informes a nivel del evento que el navegador puede limitar la cantidad de eTLD+1 de "destino" representados por sitios de origen. (consulta solicitud de extracción). |
| Informes de atribución y Protected Audience | ¿Cómo pueden trabajar juntas la API de Attribution Reporting y la API de Protected Audience? | Actualmente, las integraciones están disponibles para la API de Protected Audience en ambos modos de la API de Attribution Reporting (informes a nivel del evento y de resumen). El 1 de junio, compartimos más información sobre la integración mejorada de la API de Protected Audience y Attribution Reporting. Puedes leer sobre ellos aquí. |
| Parámetros de configuración flexibles a nivel del evento | Comparte las prácticas recomendadas para la simulación de ruido ahora que los parámetros son configurables. | Compartimos código en GitHub que cualquier persona puede usar para evaluar la ganancia de información y el impacto del ruido en cualquier configuración flexible a nivel del evento que desee probar. Nos gustaría recibir comentarios de quienes prueben el código. |
| Medición de atribución web y de aplicación cruzada | ¿Cuándo estará disponible la medición de atribución web y entre aplicaciones? | El 9 de mayo, anunciamos un experimento para la medición de atribución web y de aplicación cruzada a través de la API de Attribution Reporting. Si bien se planifica la disponibilidad general para las APIs de relevancia y medición en Chrome 115, actualmente no se planea que la medición de atribución entre aplicaciones y la Web alcance la disponibilidad general con Chrome 115. |
| Cómo anular las conversiones duplicadas | ¿Cómo se pueden conciliar las soluciones de medición independientes con la ARA? | Al igual que con la práctica estándar actual, los anunciantes trabajarían con un proveedor de medición independiente externo para anular los informes de conversiones duplicados. Ofrecimos recursos para desduplicar las conversiones en los informes a nivel del evento. |
| Pérdida de datos durante las actualizaciones de la base de datos de Attribution Reporting | ¿Se perderán datos cuando Chrome actualice la base de datos de informes de atribución como se anunció? | A partir de la versión estable 115 de Chrome, comenzaremos a habilitar las APIs de Relevance y Measurement para una parte de los usuarios de Chrome de forma predeterminada. Esta disponibilidad general aumentará a medida que supervisemos los posibles problemas. El objetivo será alcanzar el 100% de disponibilidad en un período de semanas, a más tardar en el tercer trimestre de 2023. Esto coincidirá con el final de la prueba de origen de relevancia y medición. A partir de julio, los verificadores podrán inscribirse para obtener acceso a estas APIs en la fase de disponibilidad general. Esto proporcionará una superposición entre la disponibilidad de la prueba de origen y la disponibilidad general a través de la inscripción. Tu token de prueba de origen será válido hasta el 19 de septiembre, pero te recomendamos que te inscribas en las APIs antes de que venza para realizar la transición sin problemas de la prueba de origen sin interrumpir las pruebas en curso. Como se menciona en este anuncio, los datos registrados de versiones anteriores (M113 y anteriores) no se migrarán después de la actualización, por lo que es posible que se pierdan. Esta pérdida de datos no aparecerá en los informes de depuración, y trataremos de evitar la pérdida de datos del 114 al 115. |
| Facturación | Cómo usar los informes de atribución para la facturación del costo por conversión | Como se indica en este artículo, es posible que la API de Attribution Reporting no sea adecuada para las necesidades de facturación del costo por conversión debido al ruido que se agrega a los informes a nivel del evento y de resumen. Invitamos a los participantes del ecosistema a compartir sus comentarios sobre el impacto de la API de Attribution Reporting en varios modelos de facturación en GitHub. |
Servicio de agregación
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cambio en la demora de los informes agregables | Reacciones positivas a la propuesta de cambiar la demora del informe agregable de [10-60 min] a [0-10 min] después de los comentarios del ecosistema | Nos complace ver una reacción positiva al cambio propuesto y animamos al ecosistema a que siga enviando comentarios sobre nuestras propuestas. |
| Solución local | ¿Se puede implementar el servicio de agregación en centros de datos locales? | Si bien estamos explorando opciones de compatibilidad más allá de las soluciones basadas en la nube, actualmente no es posible admitir TEEs en las instalaciones debido a las limitaciones de seguridad que requerirían una evaluación que consume mucho tiempo para Privacy Sandbox. Teniendo en cuenta los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que lo más beneficioso para el ecosistema es seguir expandiendo y mejorando las implementaciones basadas en la nube (p.ej., admitir GCP además de AWS). Sin embargo, agradecemos los comentarios adicionales sobre por qué es necesario este requisito. |
| Cómo volver a procesar informes de diferentes períodos | Capacidad de volver a procesar informes para diferentes períodos | Recibimos solicitudes similares para poder dividir lotes en diferentes períodos. Una propuesta es permitir la posibilidad de extender el ID compartido con una etiqueta definida por la tecnología publicitaria para que los informes se puedan dividir en diferentes lotes. Estamos en la etapa inicial de la evaluación de este proceso y mantendremos al ecosistema al tanto a medida que evolucione esta propuesta. |
| Implicaciones de privacidad del entorno de ejecución confiable | Sentimiento positivo hacia las implicaciones de privacidad de los entornos de ejecución confiables | Nos complace recibir reacciones positivas del ecosistema en relación con nuestras propuestas y agradecemos los comentarios adicionales mientras seguimos iterando y desarrollando. |
| Condiciones del Servicio | ¿Cuál es la fecha límite para aceptar las Condiciones del Servicio del Servicio de Agregación? | Si bien aún no especificamos una fecha límite para aceptar los Términos y Condiciones, recomendamos a las empresas del ecosistema que los acepten lo antes posible para evitar retrasos en la inscripción. Recomendamos a las empresas que se comuniquen con nosotros si tienen alguna pregunta. |
| Descubrimiento de claves | La función de descubrimiento de claves permitirá a los verificadores consultar informes agregados sin necesidad de la lista explícita de posibles combinaciones de claves para procesar informes de resumen de atribución entre redes y mejorar el rendimiento y la precisión. | Actualmente, estamos explorando posibles soluciones y alternativas, y recibimos con gusto más comentarios del ecosistema. |
API de Private Aggregation
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Origen de los informes | ¿Cómo se define el origen de los informes? | El origen de los informes siempre es el origen de la secuencia de comandos del llamador de agregación privada. |
| Espacio de claves de 128 bits | Claridad sobre la limitación del espacio de claves de 128 bits | Haremos que esta limitación del espacio de claves sea más clara y resolveremos las inconsistencias entre las páginas. Te recomendamos que uses estrategias de hash para permanecer dentro de este espacio de claves. |
| Contribución máxima por informe | El límite actual de 20 contribuciones por informe es demasiado bajo. | En lugar de aumentar la cantidad máxima de contribuciones, estamos dispuestos a considerar dividir los informes en lugar de truncarlos en el límite. Involucraremos al ecosistema a medida que esta propuesta evolucione. |
| Informes de alcance | Solicita informes de alcance multiplataforma o de varios dispositivos. El alcance es una métrica fundamental de la publicidad de marca. Los anunciantes dependen de las aproximaciones multiplataforma y multidispositivo para los informes de alcance y frecuencia para analizar sus campañas y asignar la inversión. Los modelos de alcance utilizan cookies de terceros como indicador para medir los anuncios que se muestran en entornos de terceros, por lo que las tecnologías publicitarias solicitaron una solución alternativa una vez que las cookies de terceros dejen de estar disponibles. |
El equipo de Privacy Sandbox está explorando funciones para admitir metodologías de alcance entre dominios después de que dejen de estar disponibles las cookies de terceros. Los comentarios adicionales del ecosistema son bienvenidos. |
Limita el seguimiento encubierto
Reducción del usuario-agente o sugerencias de cliente de usuario-agente
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Sugerencias para factores de forma adicionales (también se informará en el 1ᵉʳ trimestre de 2023) | Solicitud de sugerencias del cliente del usuario-agente (UA-CH) para proporcionar factores de forma adicionales, como TV y VR | Seguimos trabajando en algunas decisiones de diseño clave (si proporcionar un valor único, como “TV”, o una lista de capacidades de factor de forma), pero seguimos interesados en crear un prototipo de esta idea. |
| Privacy Budget | Las restricciones del presupuesto de privacidad podrían hacer que las solicitudes de UA-CH dejen de ser deterministas cuando se envían demasiadas solicitudes. | Por el momento, no tenemos novedades sobre la propuesta de Privacy Budget, pero nos comprometimos a no restringir las solicitudes de sugerencias de clientes de UA antes de que dejen de estar disponibles las cookies de terceros. |
| Compatibilidad del sitio | Los sitios web usan la marca UA-CH para restringir el acceso de ciertos navegadores a los sitios. | Existen casos de uso válidos para tener una lista de marcas, y uno de ellos es precisamente la compatibilidad. Un UA puede tener varias marcas para solucionar estos problemas. |
IP Protection (antes Gnatcatcher)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Fraude y abuso | ¿Cómo pueden las empresas configurar medidas contra el fraude con IP Protection? | Comprendemos la importancia de los casos de uso contra el fraude y el posible impacto en ellos. Planeamos publicar más detalles sobre la compatibilidad con la prevención de fraudes más adelante este verano. Estamos buscando comentarios del ecosistema sobre cómo podemos admitir mejor los casos de uso de prevención de fraudes. |
| GeoIP | Más información sobre el cronograma de pruebas y la implementación de GeoIP | Recientemente, Chrome publicó información nueva en la que se detallan nuestros planes de GeoIP. Planeamos publicar más información sobre los cronogramas de implementación en el tercer trimestre. Esperamos lanzar la Protección de IP como una función que los usuarios puedan habilitar en un pequeño porcentaje del tráfico inicialmente. El motivo es que reconocemos que esta propuesta puede implicar algunos cambios significativos para las empresas y queremos darle tiempo al ecosistema para que se adapte y envíe comentarios antes de que la función se lance de forma más amplia. |
| Autenticación de cuenta | ¿Cómo funcionará exactamente la autenticación de la cuenta con el servidor proxy? | Planeamos publicar más detalles sobre la autenticación de cuentas más adelante este verano, aunque ya compartimos algunas consideraciones iniciales. |
Mitigación del seguimiento por rebote
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Orientación para pruebas | Información para probar la mitigación del seguimiento por rebote | En mayo, publicamos una entrada de blog con más información para probar la mitigación del seguimiento por rebote. |
| Documentación | Claridad en la propuesta de seguimiento por rebote | La propuesta actual aún está en desarrollo, y Chrome seguirá actualizándola para brindarle claridad y más información al ecosistema. Estamos trabajando para proporcionar más detalles y agradecemos cualquier comentario adicional. |
| Eliminación de cookies | ¿La mitigación del seguimiento de rebotes borrará todas las cookies de un dominio? | La mitigación del seguimiento de rebotes (BTM) borrará todo el almacenamiento y la caché, como se explica aquí. |
| Cómo eludir la mitigación del seguimiento por rebote | Se puede eludir la clasificación del servicio de seguimiento de rebotes realizando redireccionamientos con ventanas emergentes o pestañas nuevas. | La especificación de mitigación del seguimiento por rebote aún está en desarrollo. Hasta ahora, nos hemos enfocado principalmente en los redireccionamientos en la misma pestaña, pero planeamos trabajar en los flujos de ventanas emergentes en el futuro. Envía tus comentarios adicionales aquí. |
Privacy Budget
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Orientación por proximidad | El presupuesto de privacidad puede afectar los casos de uso de segmentación por proximidad. | Recibimos comentarios sobre este problema y nos gustaría saber más sobre los posibles impactos del ecosistema. |
Fortalecimiento de los límites de la privacidad entre sitios
Conjuntos propios
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Límite de dominios (también se informa en trimestres anteriores) | Solicitud para expandir la cantidad de dominios asociados | Chrome está evaluando el límite numérico adecuado para el subconjunto asociado que equilibrará la privacidad y la utilidad para los casos de uso que se identificaron. Desde el inicio, Chrome compartió que aún no se había finalizado la cantidad exacta del subconjunto asociado. |
| Caso de uso incorporado | Compatibilidad con casos de uso incorporados que requieren conjuntos propios, CHIPs y almacenamiento compartido | Chrome recibió los comentarios sobre este caso de uso. El equipo está investigando y acepta comentarios adicionales. |
| Administración de repositorios | Información sobre las políticas para quitar los conjuntos propios del repositorio de GitHub si hay discrepancias o negligencias | Chrome recibió los comentarios sobre este caso de uso. El equipo está investigando el caso y acepta comentarios adicionales. |
| Educación del usuario | Chrome debe aumentar el conocimiento y la comprensión de los usuarios sobre los conjuntos propios para impulsar la adopción. | Chrome se compromete a educar a los usuarios sobre los conjuntos propios y publicó un artículo del Centro de ayuda (vinculado desde la IU de Chrome) a tal efecto. Chrome también invierte en seguir aprendiendo cómo educar mejor a los usuarios en los contextos adecuados. |
| Publicación posterior a la 3PCD | Las cookies de terceros seguirán existiendo en un conjunto propio después de que se den de baja. | Si bien requestStorageAccess y requestStorageAccessFor vuelven a hacer que las cookies de terceros estén disponibles para casos de uso específicos y claramente definidos, ahora requieren que el sitio las invoque de forma activa, en lugar de que estén disponibles de forma predeterminada, como ocurre con el estado actual de las cookies de terceros (en Chrome).Si bien esta invocación dentro de un solo conjunto no requerirá la aprobación del usuario, los usuarios pueden inhabilitar este comportamiento en Configuración para evitarlo. Los usuarios pueden obtener más información en el artículo del Centro de ayuda (vinculado desde la IU de Chrome). Planeamos ampliar la guía para desarrolladores existente a medida que los FPS aumenten hasta el 100%. |
| Envío de conjuntos propios | Cambia el nombre del .well-known/first-party-set requerido para incluir una extensión .json. |
Realizamos este cambio para garantizar que se admitan ciertos planes de hosting web. |
| Registro de la IANA | first_party_sets.JSON debe estar registrado en la IANA. |
Estamos considerando la propuesta y te invitamos a que nos envíes tus comentarios adicionales aquí. |
API de Fenced Frames
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Bloqueo de anuncios | Los marcos delimitados pueden facilitar que los bloqueadores de anuncios bloqueen los anuncios. | Las extensiones pueden interactuar con marcos vallados de manera similar a como lo harían con iframes. Las extensiones también podrán ver la URL real a la que se navegará en el marco protegido y, por lo tanto, podrán aplicar cualquier regla de coincidencia de URL para el bloqueo, como lo harían en los iframes. Simplemente bloquear todos los fotogramas de zona sin condiciones podría interrumpir los casos de uso de fotogramas de zona que no son de anuncios. |
API de Shared Storage
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Mayor adopción | El almacenamiento compartido debe ser un estándar de la industria disponible en todos los navegadores. | Agradecemos y tomamos nota de estos comentarios. Chrome continúa participando activamente en los foros del W3C para promover la propuesta, buscar comentarios y fomentar la adopción. |
| Puertas de salida | Las puertas de salida de almacenamiento compartido son demasiado limitadas. | Estamos considerando estos comentarios y agradecemos los comentarios adicionales del ecosistema sobre por qué las puertas de salida son demasiado limitadas. |
| Cumplimiento de las normativas | ¿Cómo manejará el almacenamiento compartido el cumplimiento normativo, como las políticas de retención de datos? | El almacenamiento compartido proporciona la flexibilidad para implementar y personalizar la lógica para controlar la vida útil y el vencimiento de los datos almacenados. Las tecnologías publicitarias pueden actualizar o borrar datos del almacenamiento compartido en función de las marcas de tiempo de escritura. |
| Prueba A/B | ¿Cómo se pueden realizar pruebas A/B para la API de Shared Storage y Protected Audience? | Estamos trabajando para publicar más orientación sobre este tema y esperamos compartir más detalles en el futuro. |
| Límite de almacenamiento compartido | ¿Qué sucederá cuando se alcance el límite de almacenamiento compartido? | Si se alcanza el límite, no se almacenarán más entradas. |
| Acceso múltiple en la misma carga de página | ¿Qué sucede cuando se accede al almacenamiento compartido varias veces en la misma carga de página? | La mejor manera de controlar esto es a través de la función window.sharedStorage.append(key, value). En lugar de actualizar el valor de cada anuncio, lo que podría causar colisiones si hay varios anuncios. La función de adición solo agregará el valor nuevo al final del valor preexistente. |
| Funcionalidad de iframe | ¿Shared Storage admitirá ciertas funciones de iframe una vez que ya no funcionen después de que se den de baja las cookies de terceros? | Después de la baja de las cookies de terceros, el almacenamiento local en iframes se particionará por el sitio de nivel superior, pero los iframes en sí no se bloquearán. Los datos del almacenamiento local de un iframe no se pueden replicar en varios sitios de nivel superior, pero el almacenamiento local se puede usar dentro del iframe. |
CHIPs
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Límite de particiones | 10 KiB por sitio particionado sigue siendo un valor considerable y nos gustaría que se redujera. | Firefox ya indicó una posición positiva en CHIPS. Para obtener asistencia de Webkit, recomendamos a los desarrolladores que envíen sus comentarios directamente a Apple en este problema de GitHub sobre sus casos de uso en los que se prefieren las cookies particionadas en lugar del almacenamiento particionado. |
| Incorporaciones autenticadas | Los CHIP pueden afectar el flujo de acceso de SSO actual debido a la partición diferente que afecta a las incorporaciones autenticadas. | Tenemos la intención de aprovechar la API de Storage Access (con indicaciones para el usuario) para admitir el caso de uso de incorporaciones autenticadas y, recientemente, enviamos un intención de crear un prototipo. |
| Políticas de por vida | ¿Las posibles políticas de por vida se aplicarán a las cookies propias? | Actualmente, no tenemos planes de imponer límites de duración a las cookies propias. |
FedCM
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Compatibilidad con la autorización de OAuth | Alineación para autorizar permisos de OAuth que no sean de perfil | Estamos buscando activamente aportes de la comunidad de Web Identity a través del CG de FedID del W3C sobre las mejores formas de admitir la autorización más allá de la autenticación básica después de la baja de las cookies de terceros. |
| Compatibilidad con SAML | Alineación con los requisitos de compatibilidad con SAML | El equipo busca activamente aportes de las comunidades de investigación y educación sobre las necesidades de compatibilidad con SAML (además de la compatibilidad con OpenID Connect) después de la baja de las cookies de terceros. |
Cómo combatir el spam y el fraude
API de Private State Tokens (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Exploración de indicadores nuevos | Varios socios expresaron una opinión positiva sobre la exploración de indicadores de integridad del dispositivo o confianza del usuario facilitados por el navegador. Por lo general, también son cautelosos con respecto a si los nuevos indicadores diseñados a tal efecto son suficientes para mantener los niveles actuales de detección de fraude. | Nos entusiasma explorar nuevas propuestas junto con la comunidad de prevención de fraudes y seguridad web, y también reconocer y compartir sus inquietudes. Esta es exactamente la razón por la que "luchar contra el spam y el fraude" ha sido un flujo de trabajo principal de Privacy Sandbox y por la que seguimos priorizando la inversión en la preservación de la seguridad web a medida que mejoramos la privacidad del usuario. |
| Comentarios positivos sobre PST | Varios socios expresaron interés en probar o utilizar los PST para varios casos de uso de prevención de fraudes o seguridad web. | Nos complace saber que te interesa explorar nuevas soluciones que utilizan PST. Tenemos recursos y código de muestra disponibles en el sitio para desarrolladores de Chrome. Además, recibimos con gusto más comentarios. |
| Fraude y abuso | Orientación para la prevención o detección de fraudes publicitarios en la medición después de la baja de las cookies de terceros cuando los identificadores ya no estén disponibles. | Presentamos herramientas como los tokens de estado privados, que ayudan a recuperar algunos de los indicadores que pierden las cookies de terceros con fines antifraude, pero con nuevos controles de privacidad implementados. Estamos invirtiendo de forma activa en nuevas propuestas contra el fraude y el abuso para preservar las funciones con otros cambios en Privacy Sandbox. |
| Tasa de información del emisor al origen | La tasa de información del emisor al origen es lo suficientemente alta como para identificar a los usuarios únicos. | Actualizamos la especificación para que sea más clara sobre qué datos del usuario se pueden transmitir con los tokens de estado privado. De forma predeterminada, se pueden usar hasta seis claves públicas a la vez, lo que puede representar un "estado" para un usuario en particular. Estos conjuntos de claves solo se pueden actualizar cada 60 días (excepto en casos excepcionales en los que es necesaria una rotación de claves de emergencia), lo que ralentiza la posibilidad de unir datos de usuarios adicionales con el tiempo. Con cualquier API web nueva, existe un equilibrio entre la utilidad proporcionada y la información nueva del usuario que proporciona. Estimamos que los PST logran el equilibrio adecuado para proteger la privacidad del usuario y, al mismo tiempo, habilitar casos de uso clave de prevención de fraudes afectados por la baja de las cookies de terceros. |
| Integración de recuperación de datos | La integración de fetch es complicada y innecesaria. |
El uso de fetch tiene ventajas y desventajas, y nos gustaría seguir estandarizando el ecosistema web, pero creemos que sería demasiado pronto para realizar este cambio hasta que tengamos una idea más clara de cómo será el estándar. Si surge un estándar, también nos comprometemos a realizar una transición responsable de los desarrolladores web a ese estándar. |
| Ubicación del almacenamiento | La configuración de claves de los tokens de estado privado debe almacenarse en la misma ubicación que el protocolo PrivacyPass. | Durante las pruebas de la Prueba de origen, los desarrolladores indicaron que preferían la flexibilidad de almacenar sus claves en URLs generales en lugar de en un directorio .well-known. El formato de compromiso de claves en PrivacyPass no es particularmente adecuado para una versión en la que los conjuntos de claves están diseñados para permitir un valor implícito de "metadatos públicos". Si una variante de PrivacyPass termina estandarizándose con metadatos públicos (ya sea como un POPRF, un ofuscamiento parcial de RSA o conjuntos de claves), es posible que cambiemos a una versión futura de PST para admitirlo. |
| Implementación del encabezado de la API | Preguntas sobre la implementación del encabezado de la API | A medida que la API se estandarice y el uso del ecosistema de esta API madure, esperamos poder admitir la versión estándar sin encabezado de esta API y, posiblemente, dar de baja la versión con encabezado si el uso es lo suficientemente bajo o si hay suficiente asistencia o herramientas para desarrolladores para las formas estándar de correlacionar las solicitudes de emisión o canje con otros datos. Estamos analizando el problema aquí. |
| Registro | ¿Es práctico que los emisores se registren con los proveedores de navegadores? | Actualizamos la especificación para describir el proceso de registro del emisor de tokens de estado privado. Si bien usa su propio proceso, es similar a los planes de inscripción para el resto del trabajo de Privacy Sandbox, en los que les pedimos a los emisores que hagan una declaración pública sobre cómo pretenden usar los PST y que reconozcan las restricciones técnicas que protegen la privacidad del usuario. |